Please see section 3.11.9 on
page
.
Condor will automatically recognize a SMP machine and advertise each
CPU of the machine separately.
For more details, see section 3.11.8 on
page
.
Restrictions on what jobs will run on a given resource can be easily specified in the resource's Requirements statement.
To specify that a given machine should only run certain users's jobs, for example, you could add the following Requirements entry to the machine's Condor configuration file:
Requirements = (RemoteUser == "userfoo@baz.edu" || RemoteUser == "userbar@baz.edu" )
To configure multiple machines to do so, simply create a common configuration file containing this requirement for them to share.
This is a two-step process. First, you need to tell the machines to report that they have special software installed, and second, you need to tell the jobs to require machines that have that software.
To tell the machines to report the presence of special software, first add a parameter to their configuration files like so:
HAS_MY_SOFTWARE = True
And then, if there are already STARTD_EXPRS defined in that file, add HAS_MY_SOFTWARE to them, or, if not, add the line:
STARTD_EXPRS = HAS_MY_SOFTWARE, $(STARTD_EXPRS)
NOTE: For these changes to take effect, each condor_startd you update needs to be reconfigured with condor_reconfig -startd.
Next, to tell your jobs to only run on machines that have this software, add a requirements statement to their submit files like so:
Requirements = (HAS_MY_SOFTWARE =?= True)
NOTE: Be sure to use =?= instead of == so that if a machine doesn't have the HAS_MY_SOFTWARE parameter defined, the job's Requirements expression will not evaluate to ``undefined'', preventing it from running anywhere!
A commonly requested policy for running batch jobs is to only allow
them to run at night, or at other pre-specified times of the day.
Condor allows you to configure this policy with the use of the
ClockMin and ClockDay condor_startd attributes.
A complete example of how to use these attributes for this kind of
policy is discussed in subsection 3.6.9 on
page
, ``A Policy for Only Running
Jobs at Certain Times of the Day'', inside
section 3.6 on ``Configuring The Startd
Policy''
If a LOCAL_CONFIG_FILE is specified in the global configuration file, but the specified file does not exist, the condor_master will not start up, and it prints a variation of the following example message.
ERROR: Can't read config file /mnt/condor/hosts/bagel/condor_config.local
This is not a bug; it is a feature! Condor has always worked this way on purpose. There is a potentially large security hole if Condor is configured to read from a file that does not exist. By creating that file, a malicious user could change all sorts of Condor settings. This is an easy way to gain root access to a machine, where the daemons are running as root.
The intent is that if you've set up your global configuration file to read from a local configuration file, and the local file is not there, then something is wrong. It is better for the condor_master to exit right away and log an error message than to start up.
If the condor_master continued with the local configuration file missing, either A) someone could breach security or B) you will have potentially important configuration information missing. Consider the example where the local configiguration file was on an NFS partition and the server was down. There would be all sorts of really important stuff in the local configuration file, and Condor might do bad things if it started without those settings.
If supplied it with an empty file, the condor_master works fine.