[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] windows environment questions
- Date: Fri, 16 Mar 2007 10:57:35 +0000
- From: "Matt Hope" <matthew.hope@xxxxxxxxx>
- Subject: Re: [Condor-users] windows environment questions
On 3/15/07, Kevin Owen <kjvowen@xxxxxxxxx> wrote:
I am running condor on a small group of Windows XP machines, with a RHEL
4 central manager/submitter. The problem is that when jobs run on the
windows machines, they don't load the system environment. So far the
only thing I can do is set the variables I need in the submit file.
I looked into how the jobs are running, and they seem to run under the
user IS\condor-reuse-vm1, a user created (I assume) by the condor msi.
This user has no profile (there is no folder for it in Documents and
Settings, nor does it show up in sysdm.cpl under user profiles).
Furthermore, it is not a member of the group NT AUTHORITY\INTERACTIVE.
Is it possible that this is causing it to load the incorrect
environment? And if so, will adding condor-reuse-vm1 to this group
cause any problems with condor?
Either by luck or by design the default uses on windows do not load
any (non atomated) system environment variables. This is probably a
good defaulot from a security point of view.
Also a common use case for many jobs (though less useful on windows I
admit) iis to submit jobs with getenv = true which runs jobs with the
environment from the submitting machine. In such cases the
merging/overwriting of the local environment is an open problem (which
are always best avoided).
DAEMONNAME_ENVIRONMENT is a config setting that allows the environment
to be explicitly set for a daemon but I do not believe this will
cascade to a job.
If you need to set the environment then it is best done through the
submit script. If you need to reference something which is local to
the machine (say where perl is located) then your best bet is to
expose the existence through a class ad. This lets jobs match against
it; then have a standard way of finding the location via a wrapper
script (or use the automated wrapper script functionality configurable
at the startd to populate this information).
Note: The condor users on windows are dynamically created as needed
(if you dropped a dual core cpu in then you'd see number 2 created, I
think on the first use of the vm).