3.3 Configuration

This section describes how to configure all parts of the Condor
system. General information about the configuration
files and their syntax is followed by a description of
settings that affect all
Condor daemons and tools.
The
settings that control the policy under which Condor will start,
suspend, resume, vacate or kill jobs
are described in
section 3.5 on Startd Policy Configuration.

3.3.1 Introduction to
Configuration Files

The Condor configuration files are used to customize how Condor
operates at a given site. The basic configuration as shipped with
Condor works well for most sites, with few exceptions.

See section 3.2 on
page
for details on where
Condor's configuration files are found.

Each Condor program will, as part of its initialization process,
configure itself by calling a library routine which parses the
various configuration files that might be used including pool-wide,
platform-specific, machine-specific, and root-owned configuration files.

The order in which attributes are defined is important, since later
definitions will override existing definitions.
This is particularly important if configuration files are broken up
using the LOCAL_CONFIG_FILE setting described in
sections 3.3.3
and 3.13.2 below.

The result of configuration is a list of key/value pairs.
Each key is a configuration variable name,
and each value is a string literal
that may utilize macro substitution (as defined below).
Note that the string literal value portion of a pair is not an expression,
and therefore it is not evaluated.
Those configuration variables that express the policy for
starting and stopping of jobs appear as expressions in the
configuration file.
However, these expressions (for configuration) are string literals.
Other portions of Condor use these strings as expressions,
parsing them in order to do evaluation.

3.3.1.1 Configuration File Macros

Macro definitions are of the form:

<macro_name> = <macro_definition>

NOTE: There must be white space between the macro name, the
``='' sign, and the macro definition.

Macro invocations are of the form:

$(macro_name)

Macro definitions may contain references to other macros, even ones
that are not yet defined (as long as they are eventually defined in
the configuration files).
All macro expansion is done after all configuration files have been parsed
(with the exception of macros that reference themselves, described
below).

A = xxx
C = $(A)

is a legal set of macro definitions, and the resulting value of
C is
xxx.
Note that
C is actually bound to
$(A), not its value.

As a further example,

A = xxx
C = $(A)
A = yyy

is also a legal set of macro definitions, and the resulting value of
C is yyy.

A macro may be incrementally defined by invoking itself in its
definition. For example,

A = xxx
B = $(A)
A = $(A)yyy
A = $(A)zzz

is a legal set of macro definitions, and the resulting value of
A
is xxxyyyzzz.
Note that invocations of a macro in
its own definition are immediately
expanded.
$(A) is immediately expanded in line 3 of the example.
If it were not, then the definition would be impossible to
evaluate.

Recursively defined macros such as

A = $(B)
B = $(A)

are not allowed.
They create definitions that Condor refuses to parse.

NOTE: Macros should not be incrementally defined in the
LOCAL_ROOT_CONFIG_FILE for security reasons.

All entries in a configuration file must have an operator,
which will be an equals sign (=).
Identifiers are alphanumerics combined with the underscore character,
optionally with a subsystem name and a period as a prefix.
As a special case,
a line without an operator that begins with a left square bracket
will be ignored.
The following two-line example treats the first line as a comment,
and correctly handles the second line.

[Condor Settings]
my_classad = [ foo=bar ]

To simplify pool administration,
any configuration variable name may be prefixed by
a subsystem
(see the $(SUBSYSTEM) macro in
section 3.3.1
for the list of subsystems)
and the period (.) character.
For configuration variables defined this way,
the value is applied to the specific subsystem.
For example,
the ports that Condor may use can be restricted to a range
using the HIGHPORT and LOWPORT configuration
variables.
If the range of intended ports is different for specific
daemons, this syntax may be used.

Note that all configuration variables may utilize this syntax,
but nonsense configuration variables may result.
For example, it makes no sense to define

NEGOTIATOR.MASTER_UPDATE_INTERVAL = 60

since the condor_ negotiator daemon does not use the
MASTER_UPDATE_INTERVAL variable.

It makes little sense to do so, but Condor will configure
correctly with a definition such as

MASTER.MASTER_UPDATE_INTERVAL = 60

The condor_ master uses this configuration variable,
and the prefix of MASTER. causes this configuration
to be specific to the condor_ master daemon.

3.3.1.2 Comments and Line Continuations

A Condor configuration file may contain comments and
line continuations.
A comment is any line beginning with a ``#'' character.
A continuation is any entry that continues across multiples lines.
Line continuation is accomplished by placing the ``''
character at the end of any line to be continued onto another.
Valid examples of line continuation are

Note that a line continuation character may currently be used within
a comment, so the following example does not set the
configuration variable FOO:

# This comment includes the following line, so FOO is NOT set \
FOO = BAR

It is a poor idea to use this functionality, as it is likely to
stop working in future Condor releases.

3.3.1.3 Executing a Program to Produce Configuration Macros

Instead of reading from a file,
Condor may run a program to obtain configuration macros.
The vertical bar character (| ) as the last character defining
a file name provides the syntax necessary to tell
Condor to run a program.
This syntax may only be used in the definition of
the CONDOR_CONFIG environment variable,
the LOCAL_CONFIG_FILE configuration variable,
or the LOCAL_ROOT_CONFIG_FILE configuration variable.

The command line for the program
is formed by the characters preceding the vertical bar character.
The standard output of the program is parsed as a configuration
file would be.

An example:

LOCAL\_CONFIG\_FILE = /bin/make_the_config|

Program /bin/make_the_config is executed, and its output
is the set of configuration macros.

Note that either a program is executed to generate the
configuration macros or the configuration is read from
one or more files.
The syntax uses space characters to separate command line elements,
if an executed program produces the configuration macros.
Space characters would otherwise separate the list of files.
This syntax does not permit distinguishing one from the other,
so only one may be specified.

3.3.1.4 Pre-Defined Macros

This first set are entries whose values are determined at
run time and cannot be overwritten. These are inserted automatically by
the library routine which parses the configuration files.

$(FULL_HOSTNAME)

The
fully qualified hostname of the local machine (hostname plus domain
name).

$(HOSTNAME)

The hostname of the local machine (no domain name).

$(IP_ADDRESS)

The ASCII string version of the local machine's IP address.

$(TILDE)

The full path to the
home directory of the Unix user condor, if such a user exists on the
local machine.

$(SUBSYSTEM)

The subsystem
name of the daemon or tool that is evaluating the macro.
This is a unique string which identifies a given daemon within the
Condor system. The possible subsystem names are:

STARTD

SCHEDD

MASTER

COLLECTOR

NEGOTIATOR

KBDD

SHADOW

STARTER

CKPT_SERVER

SUBMIT

GRIDMANAGER

TOOL

HAD

REPLICATION

QUILL

This second set of macros are entries whose default values are
determined automatically at runtime but which can be overwritten.

$(ARCH)

Defines the string
used to identify the architecture of the local machine to Condor.
The condor_ startd will advertise itself with this attribute so
that users can submit binaries compiled for a given platform and
force them to run on the correct machines. condor_ submit will
append a requirement to the job ClassAd that it must
run on the same ARCH and OPSYS of the machine where
it was submitted, unless the user specifies ARCH and/or
OPSYS explicitly in their submit file. See the
the condor_ submit manual page
on page for details.

$(OPSYS)

Defines the string used to identify the operating system
of the local machine to Condor.
If it is not defined in the configuration file, Condor will
automatically insert the operating system of this machine as
determined by uname.

$(UNAME_ARCH)

The architecture as reported by uname(2)'s machine field.
Always the same as ARCH on Windows.

$(UNAME_OPSYS)

The operating system as reported by uname(2)'s sysname field.
Always the same as OPSYS on Windows.

$(PID)

The process ID for the daemon or tool.

$(PPID)

The process ID of the parent process for the daemon or tool.

$(USERNAME)

The user name of the UID of the daemon or tool.
It is useful for setting GRIDMANAGER_LOG,
as that needs to be done on a per-user basis.
For daemons started as root, but running under another UID
(typically the user condor), this will be the other UID.

$(FILESYSTEM_DOMAIN)

Defaults to the fully
qualified hostname of the machine it is evaluated on. See
section 3.3.7, Shared
File System Configuration File Entries for the full description of
its use and under what conditions you would want to change it.

$(UID_DOMAIN)

Defaults to the fully
qualified hostname of the machine it is evaluated on. See
section 3.3.7
for the full description of this configuration variable.

Since $(ARCH) and $(OPSYS) will automatically be set to the
correct values, we recommend that you do not overwrite them.
Only do so if you know what you are doing.

3.3.2 The Special Configuration Macros
$ENV(), $RANDOM_CHOICE(), and $RANDOM_INTEGER()

References to the Condor process's environment are allowed in the
configuration files.
Environment references use the ENV macro and are of the form:

$ENV(environment_variable_name)

For example,

A = $ENV(HOME)

binds A to the value of the HOME environment variable.
Environment references are not currently used in standard Condor
configurations.
However, they can sometimes be useful in custom configurations.

This same syntax is used in the RANDOM_CHOICE() macro to
allow a random choice of a parameter
within a configuration file.
These references are of the form:

$RANDOM_CHOICE(list of parameters)

This allows a random choice within the parameter list to be made
at configuration time. Of the list of parameters, one is
chosen when encountered during configuration. For example,
if one of the integers 0-8 (inclusive) should be randomly
chosen, the macro usage is

$RANDOM_CHOICE(0,1,2,3,4,5,6,7,8)

The RANDOM_INTEGER() macro is similar to the RANDOM_CHOICE()
macro, and is used to select a random integer within a configuration file.
References are of the form:

$RANDOM_INTEGER(min, max [, step])

A random integer within the range min and max, inclusive,
is selected at configuration time.
The optional step parameter
controls the stride within the range, and it defaults to the value 1.
For example, to randomly chose an even integer in the range 0-8 (inclusive),
the macro usage is

3.3.3 Condor-wide Configuration File Entries

This section describes settings which affect all parts of the Condor
system.
Other system-wide settings can be found in
section 3.3.6 on
``Network-Related Configuration File Entries'', and
section 3.3.7 on ``Shared
File System Configuration File Entries''.

CONDOR_HOST

This macro may be
used to define the $(NEGOTIATOR_HOST) and is used to define the
$(COLLECTOR_HOST) macro. Normally the condor_ collector
and condor_ negotiator would run on the same machine. If for some
reason they were not run on the same machine,
$(CONDOR_HOST) would not be needed. Some
of the host-based security macros use $(CONDOR_HOST) by
default. See section 3.6.8, on Setting up
IP/host-based security in Condor for details.

COLLECTOR_HOST

The
hostname of the machine where the condor_ collector is running for
your pool. Normally, it is defined relative to
the $(CONDOR_HOST)
macro. There is no default value for this macro;
COLLECTOR_HOST must be defined for the pool to work
properly.

In addition to defining the hostname, this setting can optionally be
used to specify the network port of the condor_ collector.
The port is separated from the hostname by a colon (':').
For example,

COLLECTOR_HOST = $(CONDOR_HOST):1234

If no port is specified, the default port of 9618 is used.
Using the default port is recommended for most sites.
It is only changed if there is a conflict with another
service listening on the same network port.
For more information about specifying a non-standard port for the
condor_ collector daemon,
see section 3.7.1 on
page .

NEGOTIATOR_HOST

This configuration variable is no longer used.
The port where the condor_ negotiator is listening is normally
dynamically allocated since version 6.7.4.

For pools running 6.7.3 and older versions: The
host name of the machine where the condor_ negotiator is running for
the pool.
Normally, it is defined relative to the $(CONDOR_HOST)
macro. There is no default value for this macro;
NEGOTIATOR_HOST must be defined for the pool to work
properly.
This variable may also be used to optionally define a network port for
the condor_ negotiator daemon, as explained for the
COLLECTOR_HOST variable.

CONDOR_VIEW_HOST

The
hostname of the machine where the CondorView server is running.
This service is optional, and requires additional configuration if
you want to enable it. There is no default value for
CONDOR_VIEW_HOST. If CONDOR_VIEW_HOST is not
defined, no CondorView server is used.
See section 3.13.5 on
page for more details.

SCHEDD_HOST

The
hostname of the machine where the condor_ schedd is running for
your pool. This is the host that queues submitted jobs. Note that,
in most condor installations, there is a condor_ schedd running on
each host from which jobs are submitted. The default value of
SCHEDD_HOST is the current host. For most pools, this
macro is not defined.

RELEASE_DIR

The full path to
the Condor release directory, which holds the bin,
etc, lib, and sbin directories. Other macros
are defined relative to this one. There is no default value for
RELEASE_DIR.

BIN

This directory points to the
Condor directory where user-level programs are installed. It is
usually defined relative to the $(RELEASE_DIR) macro.
There is no default value for BIN.

LIB

This directory points to the
Condor directory where libraries used to link jobs for Condor's
standard universe are stored. The condor_ compile program uses
this macro to find these libraries, so it must be defined for
condor_ compile to function. $(LIB) is usually defined
relative to the $(RELEASE_DIR) macro, and has no default
value.

LIBEXEC

This directory points
to the Condor directory where support commands that Condor
needs will be placed.
Do not add this directory to a user or system-wide path.

INCLUDE

This directory points
to the Condor directory where header files reside.
$(INCLUDE) would usually be defined relative to
the $(RELEASE_DIR) configuration macro.
There is no default value, but
if defined, it can make inclusion of necessary header files
for compilation of programs (such as those programs
that use libcondorapi.a)
easier through the use of condor_ config_val.

SBIN

This directory points to the
Condor directory where Condor's system binaries (such as the
binaries for the Condor daemons) and administrative tools are
installed. Whatever directory $(SBIN) points to ought
to be in the PATH of users acting as Condor
administrators. SBIN has no default value.

LOCAL_DIR

The location of the
local Condor directory on each machine in your pool. One common
option is to use the condor user's home directory which may be
specified with $(TILDE). There is no default value for
LOCAL_DIR. For example:

LOCAL_DIR = $(tilde)

On machines with a shared file system, where either the
$(TILDE) directory or another directory you want to use is
shared among all machines in your pool, you might use the
$(HOSTNAME) macro and have a directory with many
subdirectories, one for each machine in your pool, each named by
host names. For example:

LOCAL_DIR = $(tilde)/hosts/$(hostname)

or:

LOCAL_DIR = $(release_dir)/hosts/$(hostname)

LOG

Used to specify the
directory where each Condor daemon writes its log files. The names
of the log files themselves are defined with other macros, which use
the $(LOG) macro by default. The log directory also acts as
the current working directory of the Condor daemons as the run, so
if one of them should produce a core file for any reason, it would
be placed in the directory defined by this macro. LOG is
required to be defined. Normally, $(LOG) is defined in
terms of $(LOCAL_DIR).

SPOOL

The spool directory is where
certain files used by the condor_ schedd are stored, such as the
job queue file and the initial executables of any jobs that have
been submitted. In addition, for systems not using a checkpoint
server, all the checkpoint files from jobs that have been submitted
from a given machine will be store in that machine's spool
directory. Therefore, you will want to ensure that the spool
directory is located on a partition with enough disk space. If a
given machine is only set up to execute Condor jobs and not submit
them, it would not need a spool directory (or this macro defined).
There is no default value for SPOOL, and the condor_ schedd
will not function without it SPOOL defined. Normally,
$(SPOOL) is defined in terms of $(LOCAL_DIR).

EXECUTE

This directory acts as
the current working directory of any Condor job that is executing on
the local machine. If a given machine is only set up to only submit
jobs and not execute them, it would not need an execute directory
(or this macro defined). There is no default value for
EXECUTE, and the condor_ startd will not function if
EXECUTE is not defined. Normally, $(EXECUTE) is
defined in terms of $(LOCAL_DIR).

LOCAL_CONFIG_FILE

Identifies the
location of the local, machine-specific configuration
file for each machine
in the pool. The two most common choices would be putting this
file in the $(LOCAL_DIR), or putting all
local configuration files for the pool in a shared directory, each one
named by host name. For example,

LOCAL_CONFIG_FILE = $(LOCAL_DIR)/condor_config.local

or,

LOCAL_CONFIG_FILE = $(release_dir)/etc/$(hostname).local

or, not using the release directory

LOCAL_CONFIG_FILE = /full/path/to/configs/$(hostname).local

The value of $(LOCAL_CONFIG_FILE) is treated as a list of files,
not a
single file. The items in the list are delimited by either commas
or space characters.
This allows the specification of multiple files as
the local configuration file, each one processed in the
order given (with parameters set in later files overriding values
from previous files). This allows the use of one global
configuration file for multiple platforms in the pool, defines a
platform-specific configuration file for each platform, and uses a
local configuration file for each machine.
If the list of files is changed in one of the later read files, the new list
replaces the old list, but any files that have already been processed
remain processed, and are removed from the new list if they are present
to prevent cycles.
See section 3.3.1 on
page for directions on
using a program to generate the configuration macros that would
otherwise reside in one or more files as described here.
If LOCAL_CONFIG_FILE is not defined, no local configuration
files are processed. For more information on this, see
section 3.13.2 about Configuring Condor for
Multiple Platforms on page .

REQUIRE_LOCAL_CONFIG_FILE

Beginning in Condor 6.5.5, it is permissible for files listed
in LOCAL_CONFIG_FILE
to be missing. This is most useful for sites that have
large numbers of machines in the pool, and a local configuration file
that uses
the $(HOSTNAME) macro in its definition.
Instead of having an empty file for every host
in the pool, files can simply be omitted.
The default value is True,
causing Condor to exit with an error, if a file listed as the local
configuration file cannot be read.
A value of False allows local configuration files to be missing.

LOCAL_CONFIG_DIR

Beginning in Condor 6.7.18, a directory may be used as a container for
local configuration files.
The files found in the directory are sorted into lexigraphical order, and
then each file is treated as though it was listed in
LOCAL_CONFIG_FILE.
LOCAL_CONFIG_DIR is processed before any files listed in
LOCAL_CONFIG_FILE, and is checked again after processing
the LOCAL_CONFIG_FILE list.
It is a list of directories, and each directory is processed in the order
it appears in the list.
The process is not recursive, so any directories found inside the directory
being processed are ignored.

The User ID (UID) and Group ID (GID) pair that the Condor daemons
should run as, if the daemons are spawned as root.
This value can also be specified in the CONDOR_IDS
environment variable.
If the Condor daemons are not started as root, then neither this
CONDOR_IDS configuration macro nor the CONDOR_IDS
environment variable are used.
The value is given by two integers, separated by a period. For
example, CONDOR_IDS = 1234.1234.
If this pair is not specified in either the configuration file or in the
environment, and the Condor daemons are spawned as root,
then Condor will
search for a condor user on the system, and run as that user's
UID and GID.
See section 3.6.10 on UIDs in Condor for more details.

CONDOR_ADMIN

The email
address that Condor will send mail to if something goes wrong in
your pool. For example, if a daemon crashes, the condor_ master
can send an obituary to this address with the last few lines
of that daemon's log file and a brief message that describes what
signal or exit status that daemon exited with. There is no default
value for CONDOR_ADMIN.

CONDOR_SUPPORT_EMAIL

The email address to be included at the bottom of all email Condor
sends out under the label ``Email address of the local Condor
administrator:''.
This is the address where Condor users at your site should send
their questions about Condor and get technical support.
If this setting is not defined, Condor will use the address
specified in CONDOR_ADMIN (described above).

MAIL

The full path to a mail
sending program that uses -s to specify a subject for the
message. On all platforms, the default shipped with Condor should
work. Only if you installed things in a non-standard location on
your system would you need to change this setting. There is no
default value for MAIL, and the condor_ schedd will not
function unless MAIL is defined.

RESERVED_SWAP

Determines
how much swap space you want to reserve for your own machine.
Condor will not start up more condor_ shadow processes if the
amount of free swap space on your machine falls below this level.
RESERVED_SWAP is specified in megabytes. The default value
of RESERVED_SWAP is 5 megabytes.

RESERVED_DISK

Determines
how much disk space you want to reserve for your own machine. When
Condor is reporting the amount of free disk space in a given
partition on your machine, it will always subtract this amount. An
example is the condor_ startd, which advertises the amount of free
space in the $(EXECUTE) directory. The default value of
RESERVED_DISK is zero.

LOCK

Condor needs to create
lock files to synchronize access to various log files. Because of
problems with network file systems and file locking over
the years, we highly recommend that you put these lock
files on a local partition on each machine. If you do not have your
$(LOCAL_DIR) on a local partition, be sure to change this
entry.

Whatever user or group Condor is running as needs to have
write access to this directory. If you are not running as root, this
is whatever user you started up the condor_ master as. If you are
running as root, and there is a condor account, it is most
likely condor.
Otherwise, it is whatever you set in the CONDOR_IDS
environment variable, or whatever you define in the
CONDOR_IDS setting in the Condor config files.
See section 3.6.10 on UIDs in Condor for details.

If no value for LOCK is provided, the value of LOG
is used.

HISTORY

Defines the
location of the Condor history file, which stores information about
all Condor jobs that have completed on a given machine. This macro
is used by both the condor_ schedd which appends the information
and condor_ history, the user-level program used to view
the history file.
This configuration macro is given the default value of
$(SPOOL)/history in the default configuration.
If not defined,
no history file is kept.

ENABLE_HISTORY_ROTATION

If this is defined to be true, then the
history file will be rotated. If it is false, then it will not be
rotated, and it will grow indefinitely, to the limits allowed by the
operating system. If this is not defined, it is assumed to be
true. The rotated files wil be stored in the same directory as the
history file.

MAX_HISTORY_LOG

Defines the maximum size for the history file, in bytes. It defaults
to 20MB. This parameter is only used if history file rotation is
enabled.

MAX_HISTORY_ROTATIONS

When history file rotation is turned on, this controls how many
backup files there are. It default to 2, which means that there may
be up to three history files (two backups, plus the history file
that is being currently written to). When the history file is
rotated, and this rotation would cause the number of backups to be
too large, the oldest file is removed.

MAX_JOB_QUEUE_LOG_ROTATIONS

The schedd periodically rotates the job queue database file in order
to save disk space. This option controls how many rotated files are
saved. It defaults to 1, which means there may be up to two history
files (the previous one, which was rotated out of use, and the current one
that is being written to). When the job queue file is rotated,
and this rotation would cause the number of backups to be larger
the the maximum specified, the oldest file is removed. The primary
reason to save one or more rotated job queue files is if you are
using Quill, and you want to ensure that Quill keeps an accurate history
of all events logged in the job queue file. Quill keeps track of where
it last left off when reading logged events, so when the file is rotated,
Quill will resume reading from where it last left off, provided that
the rotated file still exists. If Quill finds that it needs to read
events from a rotated file that has been deleted, it will be forced to
skip the missing events and resume reading in the next chronological job
queue file that can be found. Such an event should not lead to
an inconsistency in Quill's view of the current queue contents, but it
would create a inconsistency in Quill's record of the history of the
job queue.

DEFAULT_DOMAIN_NAME

If you do not use a fully qualified name in file /etc/hosts
(or NIS, etc.) for either your official hostname or as an
alias, Condor would not normally be able to use fully qualified names
in places that it wants to. You can set this macro to the
domain to be appended to your hostname, if changing your host
information is not a good option. This macro must be set in the
global configuration file (not the $(LOCAL_CONFIG_FILE).
The reason for this is that the special $(FULL_HOSTNAME)
macro is used by the configuration file code in Condor needs
to know the full hostname. So, for $(DEFAULT_DOMAIN_NAME) to
take effect, Condor must already have read in its value. However,
Condor must set the $(FULL_HOSTNAME) special macro since you
might use that to define where your local configuration file is. After
reading the global configuration file, Condor figures out the right values
for $(HOSTNAME) and $(FULL_HOSTNAME) and inserts them
into its configuration table.

CM_IP_ADDR

If neither COLLECTOR_HOST nor
COLLECTOR_IP_ADDR macros are defined, then this
macro will be used to determine the IP address of the central
manager (collector daemon).
This macro is defined by an IP address.

EMAIL_DOMAIN

By default, if a user does not specify notify_user in the
submit description file, any email Condor sends about that job will
go to "username@UID_DOMAIN".
If your machines all share a common UID domain (so that you would
set UID_DOMAIN to be the same across all machines in your
pool), but email to user@UID_DOMAIN is not the right place for
Condor to send email for your site, you can define the default
domain to use for email.
A common example would be to set EMAIL_DOMAIN to the fully
qualified hostname of each machine in your pool, so users submitting
jobs from a specific machine would get email sent to
user@machine.your.domain, instead of user@your.domain.
You would do this by setting EMAIL_DOMAIN to
$(FULL_HOSTNAME).
In general, you should leave this setting commented out unless two
things are true: 1) UID_DOMAIN is set to your domain, not
$(FULL_HOSTNAME), and 2) email to user@UID_DOMAIN will not
work.

CREATE_CORE_FILES

Defines whether or not Condor daemons are to
create a core file in the LOG directory
if something really bad happens. It is
used to set
the resource limit for the size of a core file. If not defined,
it leaves in place whatever limit was in effect
when the Condor daemons (normally the condor_ master) were started.
This allows Condor to inherit the default system core file generation
behavior at startup. For Unix operating systems, this behavior can
be inherited from the parent shell, or specified in a shell script
that starts Condor.
If this parameter is set and True, the limit is increased to
the maximum. If it is set to False, the limit is set at 0
(which means that no core files are created). Core files
greatly help the Condor developers debug any problems you might be
having. By using the parameter, you do not have to worry about
tracking down where in your boot scripts you need to set the core
limit before starting Condor. You set the parameter
to whatever behavior you want Condor to enforce. This parameter
defaults to undefined to allow the initial operating system default
value to take precedence,
and is commented out in the default configuration file.

Q_QUERY_TIMEOUT

Defines the timeout (in seconds) that condor_ q uses when trying to
connect to the condor_ schedd. Defaults to 20 seconds.

PASSWD_CACHE_REFRESH

Condor can cause NIS servers to become overwhelmed by queries for uid
and group information in large pools. In order to avoid this problem,
Condor caches UID and group information internally. This setting allows
pool administrators to specify (in seconds) how long Condor should wait
until refreshes a cache entry. The default is set to 300 seconds, or
5 minutes. This means that if a pool administrator updates the user
or group database (for example, /etc/passwd or /etc/group),
it can take up
to 5 minutes before Condor will have the updated information. This
caching feature can be disabled by setting the refresh interval to
0. In addition, the cache can also be flushed explicitly by running
the command

condor_reconfig -full

This configuration variable has no effect on Windows.

SYSAPI_GET_LOADAVG

If set to False, then Condor will not attempt to compute the load average
on the system, and instead will always report the system load average
to be 0.0. Defaults to True.

NETWORK_MAX_PENDING_CONNECTS

This specifies a limit to the maximum number of simultaneous network
connection attempts. This is primarily relevant to condor_ schedd,
which may try to connect to large numbers of startds when claiming
them. The negotiator may also connect to large numbers of startds
when initiating security sessions used for sending MATCH messages. On
Unix, the default for this parameter is eighty percent of the process file
descriptor limit. On windows, the default is 1600.

3.3.4 Daemon Logging Configuration File Entries

These entries control how and where the Condor daemons write their log
files. Each of the entries in this section represents multiple
macros. There is one for each subsystem (listed
in section 3.3.1).
The macro name for each substitutes <SUBSYS> with the name
of the subsystem corresponding to the daemon.

<SUBSYS>_LOG

The name of
the log file for a given subsystem. For example,
$(STARTD_LOG) gives the location of the log file for
condor_ startd.

The actual names of the files
are also used in the $(VALID_LOG_FILES) entry used by
condor_ preen. A change to one of the
file names with this setting requires a change to the
$(VALID_LOG_FILES) entry as well, or condor_ preen will
delete your newly named log files.

MAX_<SUBSYS>_LOG

Controls
the maximum length in bytes to which a
log will be allowed to grow. Each log file will grow to the
specified length, then be saved to a file with the suffix
.old. The .old
files are overwritten each time the log is saved, thus the maximum
space devoted to logging for any one program will be twice the
maximum length of its log file. A value of 0 specifies that the
file may grow without bounds. The default is 1 Mbyte.

TRUNC_<SUBSYS>_LOG_ON_OPEN

If this macro is defined and set
to True, the affected log will be truncated and started from an
empty file with each invocation of the program. Otherwise, new
invocations of the program will append to the previous log
file. By default this setting is False for all daemons.

<SUBSYS>_LOCK

This macro
specifies the lock file used to synchronize append operations to the
log file for this subsystem. It must be a separate file from the
$(<SUBSYS>_LOG) file, since the $(<SUBSYS>_LOG) file may be
rotated and you want to be able to synchronize access across log
file rotations. A lock file is only required for log files which
are accessed by more than one process. Currently, this includes
only the SHADOW subsystem. This macro is defined relative
to the $(LOCK) macro. If, for some strange
reason, you decide to change this setting, be sure to change the
$(VALID_LOG_FILES) entry that condor_ preen uses as well.

FILE_LOCK_VIA_MUTEX

This macro setting only works on Win32 - it is ignored on Unix. If set
to be True, then log locking is implemented via a kernel mutex
instead of via file locking. On Win32, mutex access is FIFO, while
obtaining a file lock is non-deterministic. Thus setting to True
fixes problems on Win32 where processes (usually shadows) could starve
waiting for a lock on a log file. Defaults to True on Win32, and is
always False on Unix.

ENABLE_USERLOG_LOCKING

When True (the default value),
a user's job log (as specified in a submit description file)
will be locked before being written to.
If False, Condor will not lock the file before writing.

<SUBSYS>_DEBUG

All of the
Condor daemons can produce different levels of output depending on
how much information is desired. The various levels of
verbosity for a given daemon are determined by this macro. All
daemons have the default level D_ ALWAYS, and log messages for
that level will be printed to the daemon's log, regardless of this
macro's setting. Settings are a comma- or space-separated list
of the following values:

D_ ALL

This flag turns on all debugging output by enabling all of the debug
levels at once. There is no need to list any other debug levels in addition
to D_ ALL; doing so would be redundant. Be warned: this will
generate
about a HUGE amount of output.
To obtain a higher
level of output than the default, consider using D_ FULLDEBUG before
using this option.

D_ FULLDEBUG

This level
provides verbose output of a general nature into the log files.
Frequent log messages for very specific debugging
purposes would be excluded. In those cases, the messages would
be viewed by having that another flag and D_ FULLDEBUG both
listed in the configuration file.

D_ DAEMONCORE

Provides log
file entries specific to DaemonCore, such as
timers the daemons have set and the commands that are registered.
If both D_ FULLDEBUG and D_ DAEMONCORE are set,
expect very verbose output.

D_ PRIV

This flag provides log
messages about the privilege state switching that the daemons
do. See section 3.6.10 on UIDs in Condor for details.

D_ COMMAND

With this flag set, any
daemon that uses DaemonCore will print out a log message
whenever a command comes in. The name and integer of the command,
whether the command was sent via UDP or TCP, and where
the command was sent from are all logged.
Because the messages about the command used by condor_ kbdd to
communicate with the condor_ startd whenever there is activity on
the X server, and the command used for keep-alives are both only
printed with D_ FULLDEBUG enabled, it is best if this setting
is used for all daemons.

D_ LOAD

The condor_ startd keeps track
of the load average on the machine where it is running. Both the
general system load average, and the load average being generated by
Condor's activity there are determined.
With this flag set, the condor_ startd
will log a message with the current state of both of these
load averages whenever it computes them. This flag only affects the
condor_ startd.

D_ KEYBOARD

With this flag set, the condor_ startd will print out a log message
with the current values for remote and local keyboard idle time.
This flag affects only the condor_ startd.

D_ JOB

When this flag is set, the
condor_ startd will send to its log file the contents of any
job ClassAd that the condor_ schedd sends to claim the
condor_ startd for its use. This flag affects only the
condor_ startd.

D_ MACHINE

When this flag is set,
the condor_ startd will send to its log file the contents of
its resource ClassAd when the condor_ schedd tries to claim the
condor_ startd for its use. This flag affects only the
condor_ startd.

D_ SYSCALLS

This flag is used to
make the condor_ shadow log remote syscall requests and return
values. This can help track down problems a user is having with a
particular job by providing the system calls the job is
performing. If any are failing, the reason for the
failure is given. The condor_ schedd also uses this flag for the server
portion of the queue management code. With D_ SYSCALLS
defined in SCHEDD_DEBUG there will be verbose logging of all
queue management operations the condor_ schedd performs.

D_ MATCH

When this flag is
set, the condor_ negotiator logs a message for every match.

D_ NETWORK

When this flag is set,
all Condor daemons will log a message on every TCP accept, connect,
and close, and on every UDP send and receive. This flag is not
yet fully supported in the condor_ shadow.

D_ HOSTNAME

When this flag is set, the Condor daemons and/or tools will print
verbose messages explaining how they resolve host names, domain
names, and IP addresses.
This is useful for sites that are having trouble getting Condor to
work because of problems with DNS, NIS or other host name resolving
systems in use.

D_ CKPT

When this flag is set,
the Condor process checkpoint support code, which is linked into a STANDARD
universe user job, will output some low-level details about the checkpoint
procedure into the $(SHADOW_LOG).

D_ SECURITY

This flag will enable debug messages pertaining to the setup of
secure network communication,
including messages for the negotiation of a socket
authentication mechanism, the management of a session key cache.
and messages about the authentication process itself. See
section 3.6.1 for more information about
secure communication configuration.

D_ PROCFAMILY

Condor often times needs to manage an entire family of processes, (that
is, a
process and all descendants of that process). This debug flag will
turn on debugging output for the management of families of processes.

D_ ACCOUNTANT

When this flag is set,
the condor_ negotiator will output debug messages relating to the computation
of user priorities (see section 3.4).

This flag is different from the other flags, because it is
used to change the formatting of all log messages that are printed,
as opposed to specifying what kinds of messages should be printed.
If D_ PID is set, Condor will always print out the process
identifier (PID) of the process writing each line to the log file.
This is especially helpful for Condor daemons that can fork
multiple helper-processes (such as the condor_ schedd or
condor_ collector) so the log file will clearly show which thread
of execution is generating each log message.

D_ FDS

This flag is different from the other flags, because it is
used to change the formatting of all log messages that are printed,
as opposed to specifying what kinds of messages should be printed.
If D_ FDS is set, Condor will always print out the file descriptor
that the open of the log file was allocated by the operating system.
This can be helpful in debugging Condor's use of system file
descriptors as it will generally track the number of file descriptors
that Condor has open.

ALL_DEBUG

Used to make all subsystems
share a debug flag. Set the parameter ALL_DEBUG
instead of changing all of the individual parameters. For example,
to turn on all debugging in all subsystems, set
ALL_DEBUG = D_ALL.

TOOL_DEBUG

Uses the same
values (debugging levels) as <SUBSYS>_DEBUG to
describe the amount of debugging information sent to stderr
for Condor tools.

SUBMIT_DEBUG

Uses the same
values (debugging levels) as <SUBSYS>_DEBUG to
describe the amount of debugging information sent to stderr
for condor_ submit.

Log files may optionally be specified per debug level as follows:

<SUBSYS>_<LEVEL>_LOG

This is
the name of a log file for messages at a specific debug level for a
specific subsystem. If the debug level is included in
$(<SUBSYS>_DEBUG), then all messages of this debug level will be
written both to the $(<SUBSYS>_LOG) file and the
$(<SUBSYS>_<LEVEL>_LOG) file. For example,
$(SHADOW_SYSCALLS_LOG) specifies a log file for all remote
system call debug messages.

MAX_<SUBSYS>_<LEVEL>_LOG

Similar to MAX_<SUBSYS>_LOG.

TRUNC_<SUBSYS>_<LEVEL>_LOG_ON_OPEN

Similar to
TRUNC_<SUBSYS>_LOG_ON_OPEN.

3.3.5 DaemonCore Configuration File Entries

Please read section 3.9 for details
on DaemonCore. There are certain configuration file settings that
DaemonCore uses which affect all Condor daemons (except the checkpoint
server, shadow, and starter, none of which use DaemonCore yet).

HOSTALLOW...

All
macros that begin with either HOSTALLOW or
HOSTDENY are settings for Condor's host-based security.
See section 3.6.8 on Setting up
IP/host-based security in Condor for details on these
macros and how to configure them.

ENABLE_RUNTIME_CONFIG

The condor_ config_val tool has an option -rset for
dynamically setting runtime configuration values (which only effect
the in-memory configuration variables).
Because of the potential security implications of this feature, by
default, Condor daemons will not honor these requests.
To use this functionality, Condor administrators must specifically
enable it by setting ENABLE_RUNTIME_CONFIG to True, and
specify what configuration variables can be changed using the
SETTABLE_ATTRS... family of configuration options
(described below).
Defaults to False.

ENABLE_PERSISTENT_CONFIG

The condor_ config_val tool has a -set option for
dynamically setting persistent configuration values.
These values override options in the normal Condor configuration
files.
Because of the potential security implications of this feature, by
default, Condor daemons will not honor these requests.
To use this functionality, Condor administrators must specifically
enable it by setting ENABLE_PERSISTENT_CONFIG to True,
creating a directory where the Condor daemons will hold these
dynamically-generated persistent configuration files (declared using
PERSISTENT_CONFIG_DIR, described below) and specify what
configuration variables can be changed using the
SETTABLE_ATTRS... family of configuration options
(described below).
Defaults to False.

PERSISTENT_CONFIG_DIR

Directory where daemons should store dynamically-generated
persistent configuration files (used to support
condor_ config_val-set)
This directory should only be writable by root, or the user
the Condor daemons are running as (if non-root).
There is no default, administrators that wish to use this
functionality must create this directory and define this setting.
This directory must not be shared by multiple Condor installations,
though it can be shared by all Condor daemons on the same host.
Keep in mind that this directory should not be placed on an NFS
mount where ``root-squashing'' is in effect, or else Condor daemons
running as root will not be able to write to them.
A directory (only writable by root) on the local filesystem is
usually the best location for this directory.

SETTABLE_ATTRS...

All
macros that begin with SETTABLE_ATTRS or
<SUBSYS>_SETTABLE_ATTRS are settings used to restrict the
configuration values that can be changed using the condor_ config_val
command.
Section 3.6.8 on Setting up
IP/Host-Based Security in Condor for details on these
macros and how to configure them.
In particular, section 3.6.8
on page contains details specific to
these macros.

SHUTDOWN_GRACEFUL_TIMEOUT

Determines how long
Condor will allow daemons try their graceful shutdown methods
before they do a hard shutdown. It is defined in terms of seconds.
The default is 1800 (30 minutes).

<SUBSYS>_ADDRESS_FILE

A complete path to a file that is to contain an
IP address and port number for a daemon.
Every Condor daemon that uses
DaemonCore has a command port where commands are sent.
The IP/port of the daemon is put in that daemon's ClassAd,
so that other machines in the pool can query the
condor_ collector (which listens on a well-known port)
to find the address of a given daemon on a given machine.
When tools and daemons are all executing on the same
single machine, communications do not require a query of the
condor_ collector daemon.
Instead, they look in a file on the local disk
to find the IP/port.
This macro causes daemons to write the
IP/port of their command socket to a specified file.
In this way,
local tools will continue to operate,
even if the machine running the condor_ collector crashes.
Using this file will also generate
slightly less network traffic in the pool,
since tools including condor_ q and
condor_ rm do not need to send any messages over the network to
locate the condor_ schedd daemon.
This macro is not necessary for the condor_ collector
daemon, since its command socket is at a well-known port.

The macro is named by substituting <SUBSYS>
with the appropriate subsystem string as defined in
section 3.3.1.

<SUBSYS>_ATTRS or <SUBSYS>_EXPRS

Allows any DaemonCore daemon to advertise arbitrary
expressions from the configuration file in its ClassAd. Give the
comma-separated list of entries from the configuration file you want in the
given daemon's ClassAd.
Frequently used to add attributes to machines so that the
machines can discriminate between other machines in a job's
rank and requirements.

The macro is named by substituting <SUBSYS>
with the appropriate subsystem string as defined in
section 3.3.1.

<SUBSYS>_EXPRS is a historic setting that functions identically to
<SUBSYS>_ATTRS. Use <SUBSYS>_ATTRS.

NOTE: The condor_ kbdd does not send
ClassAds now, so this entry does not affect it. The
condor_ startd, condor_ schedd, condor_ master, and
condor_ collector do send ClassAds, so those would be valid
subsystems to set this entry for.

SUBMIT_EXPRS not part of the <SUBSYS>_EXPRS, it is
documented in section 3.3.15

Because of the different syntax of the configuration
file and ClassAds, a little extra work is required to get a
given entry into a ClassAd. In particular, ClassAds require quote
marks (") around strings. Numeric values and boolean expressions
can go in directly.
For example, if the condor_ startd is to advertise a string macro, a numeric
macro, and a boolean expression, do something similar to:

3.3.6 Network-Related Configuration File Entries

More information about networking in Condor can be found in
section 3.7 on page .

BIND_ALL_INTERFACES

For systems with multiple network interfaces, if this configuration
setting is not defined, Condor binds all network sockets to first
interface found, or the IP address specified with
NETWORK_INTERFACE (described below).
Starting with version 6.7.13, BIND_ALL_INTERFACES can be
set to True to cause Condor to bind to all interfaces on the
machine.
However, currently Condor is still only able to advertise a single
IP address, even if it is listening on multiple interfaces. By
default, it will advertise the IP address of the network interface
used to contact the collector, since this is the most likely to be
accessible to other processes which query information from the same
collector.
More information about using this setting can be found in
section 3.7.2 on
page .

NETWORK_INTERFACE

For systems with multiple network interfaces, if this configuration
setting is not defined, Condor binds all network sockets to first
interface found.
To bind to a specific network interface other than the
first one, this NETWORK_INTERFACE should be set to
the IP address to use.
When BIND_ALL_INTERFACES is set to True, this
setting simply controls what IP address a given Condor host will
advertise.
More information about configuring Condor on machines with multiple
network interfaces can be found in
section 3.7.2 on
page .

HIGHPORT

Specifies an upper limit of given port numbers for Condor to use,
such that Condor is restricted to a range of port numbers.
If this macro is not explicitly specified, then Condor will
not restrict the port numbers that it uses. Condor will use
system-assigned port numbers.
For this macro to work, both HIGHPORT and
LOWPORT (given below) must be defined.

LOWPORT

Specifies a lower limit of given port numbers for Condor to use,
such that Condor is restricted to a range of port numbers.
If this macro is not explicitly specified, then Condor will
not restrict the port numbers that it uses. Condor will use
system-assigned port numbers.
For this macro to work, both HIGHPORT (given above) and
LOWPORT must be defined.

IN_LOWPORT

An integer value that specifies a lower limit of given port numbers
for Condor to use on incoming connections (ports for listening),
such that Condor is restricted to a range of port numbers.
This range implies the use of both IN_LOWPORT and
IN_HIGHPORT.
A range of port numbers less than 1024 may be used for daemons
running as root.
Do not specify IN_LOWPORT in combination with
IN_HIGHPORT such that the range crosses the port 1024
boundary.
Applies only to Unix machine configuration.
Use of IN_LOWPORT and IN_HIGHPORT overrides
any definition of LOWPORT and HIGHPORT.

IN_HIGHPORT

An integer value that specifies an upper limit of given port numbers
for Condor to use on incoming connections (ports for listening),
such that Condor is restricted to a range of port numbers.
This range implies the use of both IN_LOWPORT and
IN_HIGHPORT.
A range of port numbers less than 1024 may be used for daemons
running as root.
Do not specify IN_LOWPORT in combination with
IN_HIGHPORT such that the range crosses the port 1024
boundary.
Applies only to Unix machine configuration.
Use of IN_LOWPORT and IN_HIGHPORT overrides
any definition of LOWPORT and HIGHPORT.

OUT_LOWPORT

An integer value that specifies a lower limit of given port numbers
for Condor to use on outgoing connections,
such that Condor is restricted to a range of port numbers.
This range implies the use of both OUT_LOWPORT and
OUT_HIGHPORT.
A range of port numbers less than 1024 is inappropriate, as
not all daemons and tools will be run as root.
Applies only to Unix machine configuration.
Use of OUT_LOWPORT and OUT_HIGHPORT overrides
any definition of LOWPORT and HIGHPORT.

OUT_HIGHPORT

An integer value that specifies an upper limit of given port numbers
for Condor to use on outgoing connections,
such that Condor is restricted to a range of port numbers.
This range implies the use of both OUT_LOWPORT and
OUT_HIGHPORT.
A range of port numbers less than 1024 is inappropriate, as
not all daemons and tools will be run as root.
Applies only to Unix machine configuration.
Use of OUT_LOWPORT and OUT_HIGHPORT overrides
any definition of LOWPORT and HIGHPORT.

UPDATE_COLLECTOR_WITH_TCP

If your site needs to use TCP connections to send ClassAd updates to
your collector (which it almost certainly does NOT), set to True
to enable this feature.
Please read section 3.7.4 on ``Using TCP to
Send Collector Updates'' on page
for more details and a discussion of when this
functionality is needed.
At this time, this setting only affects the main condor_ collector
for the site, not any sites that a condor_ schedd might flock to.
If enabled, also define
COLLECTOR_SOCKET_CACHE_SIZE at the central manager, so
that the collector will accept TCP connections for updates, and will
keep them open for reuse.
Defaults to False.

TCP_UPDATE_COLLECTORS

The list of collectors which will be updated with TCP instead of UDP.
Please read section 3.7.4 on ``Using TCP to
Send Collector Updates'' on page
for more details and a discussion of when a site needs this
functionality.
If not defined, no collectors use TCP instead of UDP.

<SUBSYS>_TIMEOUT_MULTIPLIER

An integer value that defaults to 1.
This value multiplies configured timeout values
for all targeted subsystem communications,
thereby increasing the time until a timeout occurs.
This configuration variable is intended for use by developers for
debugging purposes, where communication timeouts interfere.

The following settings are specific to enabling Generic Connection
Brokering or GCB in your Condor pool.
More information about GCB and how to configure it can be found in
section 3.7.3 on page .

NET_REMAP_ENABLE

If defined to True, this setting will enable a network
remapping service for Condor.
The service to use is controlled by NET_REMAP_SERVICE,
described below.
This boolean value defaults to False.

NET_REMAP_SERVICE

If NET_REMAP_ENABLE is
defined to True, this setting controls what network remapping
service should be used.
Currently, the only value supported is GCB.
The default is undefined.

NET_REMAP_INAGENT

Hosts with the GCB network remapping service enabled that require a
GCB broker (see the section on GCB referenced above for more
details) specify the IP address of their broker with this setting.
The default is undefined.

NET_REMAP_ROUTE

Hosts with the GCB network remapping service enabled that would like
to use a GCB routing table
GCB broker (again, see the section on GCB for more details) specify
The full path to their routing table with this setting.
The default is undefined.

3.3.7 Shared File System Configuration File Macros

These macros control how Condor interacts with various shared and
network file systems. If you are using AFS as your shared filesystem,
be sure to read section 3.13.1 on Using Condor with
AFS.
For information on submitting jobs under shared file systems,
see
section 2.5.3.

UID_DOMAIN

The UID_DOMAIN macro
is used to decide under which user to run jobs.
If the $(UID_DOMAIN)
on the submitting machine is different than
the $(UID_DOMAIN)
on the machine that runs a job, then Condor runs
the job as the user nobody.
For example, if the submit machine has
a $(UID_DOMAIN) of
flippy.cs.wisc.edu, and the machine where the job will execute
has a $(UID_DOMAIN) of
cs.wisc.edu, the job will run as user nobody, because
the two $(UID_DOMAIN)s are not the same.
If the $(UID_DOMAIN)
is the same on both the submit and execute machines,
then Condor will run the job as the user that submitted the job.

A further check attempts to assure that the submitting
machine can not lie about its UID_DOMAIN.
Condor compares the
submit machine's claimed value for UID_DOMAIN
to its fully qualified name.
If the two do not end the same, then the submit machine
is presumed to be lying about its UID_DOMAIN.
In this case, Condor will run the job as user nobody.
For example, a job submission to the Condor pool at the UW Madison
from flippy.example.com, claiming a UID_DOMAIN of
of cs.wisc.edu,
will run the job as the user nobody.

Because of this verification,
$(UID_DOMAIN) must be a real domain name.
At the Computer Sciences department
at the UW Madison, we set the $(UID_DOMAIN)
to be cs.wisc.edu to
indicate that whenever someone submits from a department machine, we
will run the job as the user who submits it.

Also see SOFT_UID_DOMAIN
below for information about one more check
that Condor performs before running a job as a given user.

A few details:

An administrator could set UID_DOMAIN
to *. This will match all domains,
but it is a gaping security hole. It is not recommended.

An administrator can also leave UID_DOMAIN undefined.
This will force Condor to always run jobs as user nobody.
Running standard universe jobs as user nobody enhances
security and should cause no problems, because the jobs use remote
I/O to access all of their files.
However, if vanilla jobs are run as
user nobody, then files that need to be accessed by the job will need
to be marked as world readable/writable so the user nobody can access
them.

When Condor sends e-mail about a job, Condor sends the e-mail to
user@$(UID_DOMAIN).
If UID_DOMAIN
is undefined, the e-mail is sent to user@submitmachinename.

TRUST_UID_DOMAIN

As an added security precaution when Condor is about to spawn a job,
it ensures that the UID_DOMAIN of a given
submit machine is a substring of that machine's fully-qualified
host name.
However, at some sites, there may be multiple UID spaces that do
not clearly correspond to Internet domain names.
In these cases, administrators may wish to use names to describe the
UID domains which are not substrings of the hostnames of the
machines.
For this to work, Condor must not do this regular security check.
If the TRUST_UID_DOMAIN setting is defined to True,
Condor will not perform this test, and will trust whatever
UID_DOMAIN is presented by the submit machine when trying
to spawn a job, instead of making sure the submit machine's host name
matches the UID_DOMAIN.
When not defined, the default is False,
since it is more secure to perform this test.

SOFT_UID_DOMAIN

A boolean variable that defaults to False when not defined.
When Condor is about to run a job as a particular user
(instead of as user nobody),
it verifies that the UID given for the user is in the
password file and actually matches the given user name.
However, under installations that do not have every user
in every machine's password file,
this check will fail and the execution attempt will be aborted.
To cause Condor not to do
this check, set this configuration variable to True.
Condor will then run the job under the user's UID.

VMx_USER

The name of a user for Condor to use instead of
user nobody,
as part of a solution that plugs a security hole whereby
a lurker process can prey on a subsequent job run as user name nobody.
x is an integer associated with virtual machines.
On Windows, VMx_USER
will only work if the credential of the specified
user is stored on the execute machine using condor_ store_cred.
See Section 3.6.10 for more information.

EXECUTE_LOGIN_IS_DEDICATED

A boolean value that defaults to False.
When True,
Condor knows that users given by the VMx_USER
configuration variable exist exclusively to be the owner of
Condor jobs.
When a Condor job belonging to one of these users completes,
Condor may use kill all jobs belonging to this user.
This avoids lurker jobs that the Condor job may have started.

FILESYSTEM_DOMAIN

The FILESYSTEM_DOMAIN
macro is an arbitrary string that is used to decide if
two machines (a submitting machine and an execute machine) share a
file system.
Although the macro name contains the word ``DOMAIN'',
the macro is not required to be a domain name.
It often is a domain name.

Note that this implementation is not ideal: machines may share some
file systems but not others. Condor currently has no way to express
this automatically. You can express the need to use a
particular file system by adding additional attributes to your machines
and submit files, similar to the example given in
Frequently Asked Questions,
section 7 on
how to run jobs only on machines that have
certain software packages.

Note that if you do not set
$(FILESYSTEM_DOMAIN), Condor defaults
to setting the macro's value to be the fully qualified hostname
of the local machine.
Since each machine will have a different
$(FILESYSTEM_DOMAIN),
they will not be considered to have shared file systems.

RESERVE_AFS_CACHE

If
your machine is running AFS and the AFS cache lives on the same
partition as the other Condor directories, and you want Condor to
reserve the space that your AFS cache is configured to use, set this
macro to True. It defaults to False.

USE_NFS

This macro influences
how Condor jobs running in the standard universe access their
files. Condor will redirect the file I/O requests
of standard universe jobs to be executed on the machine which
submitted the job. Because of this, as a Condor job migrates around
the network, the file system always appears to be identical to the
file system where the job was submitted. However, consider the case
where a user's data files are sitting on an NFS server. The machine
running the user's program will send all I/O over the network to the
machine which submitted the job, which in turn sends all the I/O
over the network a second time back to the NFS file server. Thus,
all of the program's I/O is being sent over the network twice.

If this macro to True, then Condor will attempt to
read/write files without redirecting I/O back to the submitting
machine if both the submitting machine and the machine running the job
are both accessing the same NFS servers (if they are both in the
same $(FILESYSTEM_DOMAIN) and in the same $(UID_DOMAIN),
as described above). The result is I/O performed by Condor standard
universe jobs is only sent over the network once.
While sending all file operations over the network twice might sound
really bad, unless you are operating over networks where bandwidth
as at a very high premium, practical experience reveals that this
scheme offers very little real performance gain. There are also
some (fairly rare) situations where this scheme can break down.

Setting $(USE_NFS) to False is always safe. It may result
in slightly more network traffic, but Condor jobs are most often heavy
on CPU and light on I/O. It also ensures that a remote
standard universe Condor job will always use Condor's remote system
calls mechanism to reroute I/O and therefore see the exact same
file system that the user sees on the machine where she/he submitted
the job.

Some gritty details for folks who want to know: If the you set
$(USE_NFS) to True, and the $(FILESYSTEM_DOMAIN) of
both the submitting machine and the remote machine about to execute
the job match, and the $(FILESYSTEM_DOMAIN) claimed by the
submit machine is indeed found to be a subset of what an inverse
lookup to a DNS (domain name server) reports as the fully qualified
domain name for the submit machine's IP address (this security
measure safeguards against the submit machine from lying),
then the job will access files using a local system call,
without redirecting them to the submitting machine (with
NFS). Otherwise, the system call will get routed back to the
submitting machine using Condor's remote system call mechanism.
NOTE: When submitting a vanilla job, condor_ submit will, by default,
append requirements to the Job ClassAd that specify the machine to run
the job must be in the same $(FILESYSTEM_DOMAIN) and the same
$(UID_DOMAIN).

IGNORE_NFS_LOCK_ERRORS

When set to True, all errors related to file locking errors from
NFS are ignored.
Defaults to False, not ignoring errors.

USE_AFS

If your machines have AFS,
this
macro determines whether Condor will use remote system calls for
standard universe jobs to send I/O requests to the submit machine,
or if it should use local file access on the execute machine (which
will then use AFS to get to the submitter's files). Read the
setting above on $(USE_NFS) for a discussion of why you might
want to use AFS access instead of remote system calls.

One important difference between $(USE_NFS) and
$(USE_AFS) is the AFS cache. With $(USE_AFS) set to
True, the remote Condor job executing on some machine will start
modifying the AFS cache, possibly evicting the machine owner's
files from the cache to make room for its own. Generally speaking,
since we try to minimize the impact of having a Condor job run on a
given machine, we do not recommend using this setting.

While sending all file operations over the network twice might sound
really bad, unless you are operating over networks where bandwidth
as at a very high premium, practical experience reveals that this
scheme offers very little real performance gain. There are also
some (fairly rare) situations where this scheme can break down.

Setting $(USE_AFS) to False is always safe. It may result
in slightly more network traffic, but Condor jobs are usually heavy
on CPU and light on I/O. False ensures that a remote
standard universe Condor job will always see the exact same
file system that the user on sees on the machine where he/she
submitted the job. Plus, it will ensure that the machine where the
job executes does not have its AFS cache modified as a result of
the Condor job being there.

However, things may be different at your site, which is why the
setting is there.

3.3.8 Checkpoint Server Configuration File Macros

These macros control whether or not Condor uses a checkpoint server.
If you are using a checkpoint server, this section
describes the settings that the checkpoint server itself needs
defined. A checkpoint server is installed
separately. It is not included in the main Condor binary
distribution or installation procedure. See
section 3.8 on Installing a Checkpoint Server
for details on installing and running a checkpoint server for your
pool.

NOTE: If you are setting up a machine to join the UW-Madison CS
Department Condor pool, you should configure the machine to
use a checkpoint server, and use ``condor-ckpt.cs.wisc.edu'' as the
checkpoint server host (see below).

CKPT_SERVER_HOST

The
hostname of a checkpoint server.

STARTER_CHOOSES_CKPT_SERVER

If this parameter is True
or undefined on
the submit machine, the checkpoint server specified by
$(CKPT_SERVER_HOST) on the execute machine is used. If it is
False on the submit machine, the checkpoint server
specified by $(CKPT_SERVER_HOST) on the submit machine is
used.

CKPT_SERVER_DIR

The
checkpoint server needs this macro defined to the full path of the
directory the server should use to store checkpoint files.
Depending on the size of your pool and the size of the jobs your
users are submitting, this directory (and its subdirectories) might
need to store many Mbytes of data.

USE_CKPT_SERVER

A boolean
which determines if you want a given submit machine to use a
checkpoint server if one is available. If a
checkpoint server isn't available or USE_CKPT_SERVER is set to
False, checkpoints will be written to the local $(SPOOL) directory on
the submission machine.

MAX_DISCARDED_RUN_TIME

If the shadow is unable to read a
checkpoint file from the checkpoint server, it keeps trying only if
the job has accumulated more than this many seconds of CPU usage.
Otherwise, the job is started from scratch. Defaults to 3600 (1
hour). This setting is only used if $(USE_CKPT_SERVER) is
True.

3.3.9 condor_ master Configuration File Macros

These macros control the condor_ master.

DAEMON_LIST

This macro
determines what daemons the condor_ master will start and keep its
watchful eyes on. The list is a comma or space separated list of
subsystem names (listed in
section 3.3.1). For example,

DAEMON_LIST = MASTER, STARTD, SCHEDD

NOTE: This configuration variable cannot be changed
by using condor_ reconfig or
by sending a SIGHUP.
To change this configuration variable, restart the
condor_ master daemon
by using condor_ restart.
Only then will the change take effect.

NOTE: On your central manager, your $(DAEMON_LIST)
will be different from your regular pool, since it will include
entries for the condor_ collector and condor_ negotiator.

NOTE: On machines running Digital Unix, your
$(DAEMON_LIST) will also include KBDD, for the
condor_ kbdd, which is a special daemon that runs to monitor
keyboard and mouse activity on the console. It is only with this
special daemon that we can acquire this information on those
platforms.

DC_DAEMON_LIST

This macro
lists the daemons in DAEMON_LIST which use the Condor
DaemonCore library. The condor_ master must differentiate between
daemons that use DaemonCore and those that don't so it uses the
appropriate inter-process communication mechanisms. This list
currently includes all Condor daemons except the checkpoint server
by default.

<SUBSYS>

Once you have defined which
subsystems you want the condor_ master to start, you must provide
it with the full path to each of these binaries. For example:

The macro is named by substituting <SUBSYS>
with the appropriate subsystem string as defined in
section 3.3.1.

DAEMONNAME_ENVIRONMENT

For each subsystem defined in DAEMON_LIST, you may specify
changes to the environment that daemon is started with by setting
DAEMONNAME_ENVIRONMENT, where DAEMONNAME is the name of
a daemon listed in DAEMON_LIST. It should use the same syntax
for specifying the environment as the environment specification in
a condor_ submit file (see page ).
For example, if you wish to redefine the
TMP and CONDOR_CONFIG environment variables seen by the
condor_ schedd, you could place the following in the config file:

SCHEDD_ENVIRONMENT = "TMP=/new/value CONDOR_CONFIG=/special/config"

When the condor_ schedd was started by the condor_ master, it would
see the specified values of TMP and CONDOR_CONFIG.

<SUBSYS>_ARGS

This macro allows
the specification of additional command line arguments for any
process spawned by the condor_ master. List the desired arguments
using the same syntax as the arguments specification in a
condor_ submit submit file (see
page ), with one exception: do
not escape double-quotes when using the old-style syntax (this is
for backward compatibility). Set the arguments for a specific
daemon with this macro, and the macro will affect only that
daemon. Define one of these for each daemon the condor_ master is
controlling. For example, set $(STARTD_ARGS) to specify
any extra command line arguments to the condor_ startd.

The macro is named by substituting <SUBSYS>
with the appropriate subsystem string as defined in
section 3.3.1.

PREEN

In addition to the daemons
defined in $(DAEMON_LIST), the condor_ master also starts up
a special process, condor_ preen to clean out junk files that have
been left laying around by Condor. This macro determines where the
condor_ master finds the condor_ preen binary.
Comment out this macro, and condor_ preen will not run.

PREEN_ARGS

Controls how condor_ preen behaves by allowing the specification
of command-line arguments.
This macro works as $(<SUBSYS>_ARGS) does.
The difference is that you must specify this macro for
condor_ preen if you want it to do anything.
condor_ preen takes action only
because of command line arguments.
-m means you want e-mail about files condor_ preen finds that it
thinks it should remove.
-r means you want condor_ preen to actually remove these files.

PREEN_INTERVAL

This macro
determines how often condor_ preen should be started. It is
defined in terms of seconds and defaults to 86400 (once a day).

PUBLISH_OBITUARIES

When a daemon crashes, the condor_ master can send e-mail to the
address specified by $(CONDOR_ADMIN) with an obituary letting
the administrator know that the daemon died, the cause of
death (which signal or exit status it exited with), and
(optionally) the last few entries from that daemon's log file. If
you want obituaries, set this macro to True.

OBITUARY_LOG_LENGTH

This macro controls how many lines
of the log file are part of obituaries. This macro has a default
value of 20 lines.

START_MASTER

If this setting
is defined and set to False when the condor_ master starts up, the first
thing it will do is exit. This appears strange, but perhaps you
do not want Condor to run on certain machines in your pool, yet
the boot scripts for your entire pool are handled by a centralized
This is
an entry you would most likely find in a local configuration file,
not a global configuration file.

START_DAEMONS

This macro
is similar to the $(START_MASTER) macro described above.
However, the condor_ master does not exit; it does not start any
of the daemons listed in the $(DAEMON_LIST).
The daemons may be started at a later time with a condor_ on
command.

MASTER_UPDATE_INTERVAL

This macro determines how often
the condor_ master sends a ClassAd update to the
condor_ collector. It is defined in seconds and defaults to 300
(every 5 minutes).

MASTER_CHECK_NEW_EXEC_INTERVAL

This
macro controls how often the condor_ master checks the timestamps
of the running daemons. If any daemons have been modified, the
master restarts them. It is defined in seconds and defaults to 300
(every 5 minutes).

MASTER_NEW_BINARY_DELAY

Once the condor_ master has
discovered a new binary, this macro controls how long it waits
before attempting to execute the new binary. This delay exists
because the condor_ master might notice a new binary while it
is in the process of being copied,
in which case trying to execute it yields
unpredictable results. The entry is defined in seconds and
defaults to 120 (2 minutes).

SHUTDOWN_FAST_TIMEOUT

This macro determines the maximum
amount of time daemons are given to perform their
fast shutdown procedure before the condor_ master kills them
outright. It is defined in seconds and defaults to 300 (5 minutes).

MASTER_BACKOFF_CONSTANT and
MASTER_<name>_BACKOFF_CONSTANT

When a daemon crashs, condor_ master uses an exponential back off
delay before restarting it; see the discussion at the end of this
section for a detailed discussion on how these parameters work together.
These settings define the constant value of the expression used to
determine how long to wait before starting the daemon again (and,
effectively becomes the initial backoff time). It is an integer in
units of seconds, and defaults to 9 seconds.

$(MASTER_<name>_BACKOFF_CONSTANT) is the daemon-specific
form of MASTER_BACKOFF_CONSTANT; if this daemon-specific
macro is not defined for a specific daemon, the non-daemon-specific
value will used.

MASTER_BACKOFF_FACTOR and
MASTER_<name>_BACKOFF_FACTOR

When a daemon crashs, condor_ master uses an exponential back off
delay before restarting it; see the discussion at the end of this
section for a detailed discussion on how these parameters work together.
This setting is the base of the
exponent used to determine how long to wait before starting the
daemon again. It defaults to 2 seconds.

$(MASTER_<name>_BACKOFF_FACTOR) is the daemon-specific
form of MASTER_BACKOFF_FACTOR; if this daemon-specific
macro is not defined for a specific daemon, the non-daemon-specific
value will used.

MASTER_BACKOFF_CEILING and
MASTER_<name>_BACKOFF_CEILING

When a daemon crashs, condor_ master uses an exponential back off
delay before restarting it; see the discussion at the end of this
section for a detailed discussion on how these parameters work together.
This entry determines the maximum amount of time you want the master
to wait between attempts to start a given daemon.
(With 2.0 as the $(MASTER_BACKOFF_FACTOR),
1 hour is obtained in 12 restarts). It is defined in terms of
seconds and defaults to 3600 (1 hour).

$(MASTER_<name>_BACKOFF_CEILING) is the daemon-specific
form of MASTER_BACKOFF_CEILING; if this daemon-specific
macro is not defined for a specific daemon, the non-daemon-specific
value will used.

MASTER_RECOVER_FACTOR and
MASTER_<name>_RECOVER_FACTOR

A macro to set how long a daemon
needs to run without crashing before it is considered recovered.
Once a
daemon has recovered, the number of restarts is reset, so the
exponential back off returns to its initial state.
The macro is defined in
terms of seconds and defaults to 300 (5 minutes).

$(MASTER_<name>_RECOVER_FACTOR) is the daemon-specific
form of MASTER_RECOVER_FACTOR; if this daemon-specific
macro is not defined for a specific daemon, the non-daemon-specific
value will used.

When a daemon crashes, condor_ master will restart the daemon after a
delay (a back off).
The length of this delay is based on how many times it has been
restarted, and gets larger after each crashes.
The equation for calculating this backoff time is
given by:

t = c + kn

where t is the calculated time, c is
the constant defined by $(MASTER_BACKOFF_CONSTANT), k is
the ``factor'' defined by $(MASTER_BACKOFF_FACTOR), and n
is the number of restarts already attempted (0 for the first restart,
1 for the next, etc.).

With default values, after the first crash, the delay would be t = 9
+ 2.00, giving 10 seconds (remember, n = 0). If the daemon keeps
crashing, the delay increases.

For example, take the $(MASTER_BACKOFF_FACTOR) (which defaults
to 2.0) to the power the number of times the daemon has restarted, and add
$(MASTER_BACKOFF_CONSTANT) (which defaults to 9).
Thus:

1st crash: n = 0, so:

2nd crash: n = 1, so:

3rd crash: n = 2, so:

...

6th crash: n = 5, so:

...

9th crash: n = 8, so:

And, after the 13 crashes, it would be:

13th crash: n = 12, so:

This is bigger than the $(MASTER_BACKOFF_CEILING), which
defaults to 3600, so the daemon would really be restarted after only
3600 seconds, not 4105.
The condor_ master tries again every hour (since the numbers would
get larger and would always be capped by the ceiling).
Eventually, imagine that daemon finally started and did not crash.
This might happen if, for example, an administrator reinstalled
an accidentally deleted binary after receiving e-mail about
the daemon crashing.
If it stayed alive for
$(MASTER_RECOVER_FACTOR) seconds (defaults to 5 minutes),
the count of how many restarts this daemon has performed is reset to
0.

The moral of the example is that
the defaults work quite well, and you probably
will not want to change them for any reason.

MASTER_NAME

Defines a unique name given for a condor_ master daemon on a machine.
Defaults to the fully qualified host name.
If more than one condor_ master is running on the same host (for
example, because of multiple Personal Condor installations running
as different users) the MASTER_NAME for each
condor_ master should be defined to uniquely identify the separate
daemons.

If the MASTER_NAME contains more than a host name,
it must
have the form identifying-string@full.host.name.
If the string specified with MASTER_NAME already includes
an @ sign, Condor will replace whatever follows the @
sign with the fully qualified host name of the local machine.
If the string does not include an @ sign,
Condor will append one, followed by the host name.
The identifying-string portion can contain any
alphanumeric ASCII characters or punctuation marks except @
(which is used to delimit the name from the host name).
We recommend that the string does not contain the :
character, since that might cause problems with certain tools.
In the example of many Personal Condor installations on the same
host, the user name that each condor_ master is executing as
is, by convention,
the identifying-string.
This is easily accomplished by setting
MASTER_NAME = $(USERNAME) in the
configuration file.

If the MASTER_NAME setting is used, and the
condor_ master is configured to spawn a condor_ schedd,
the name
defined with MASTER_NAME takes precedence over the
SCHEDD_NAME setting (see section 3.3.11 on
page ).
Since Condor makes the assumption that there is only one
instance of the condor_ startd running on a machine,
the MASTER_NAME is not automatically propagated to the
condor_ startd.
However, in situations where multiple condor_ startd daemons are
running on the same host (for example, when using condor_ glidein),
the STARTD_NAME should be set to uniquely identify
the condor_ startd daemons
(this is done automatically in the case of condor_ glidein).

If a Condor daemon (master, schedd or startd) has been given a
unique name, all Condor tools that need to contact that daemon can
be told what name to use via the -name command-line option.

This macro lists the host names
of secondary collectors. A secondary collector is a machine
running a condor_ collector daemon that is not the central manager.
A secondary collector makes it possible to execute administrative
commands in the pool when the central manager is down by using the
-pool argument to specify the name of a secondary collector to
use to locate the condor_ master daemon.

ALLOW_ADMIN_COMMANDS

If set to NO for a given host, this
macro disables administrative commands, such as
condor_ restart, condor_ on, and condor_ off, to that host.

MASTER_INSTANCE_LOCK

Defines the name of a file for the condor_ master daemon
to lock in order to prevent multiple condor_ masters
from starting.
This is useful when using shared file systems like NFS which do
not technically support locking in the case where the lock files
reside on a local disk.
If this macro is not defined, the default file name will be
$(LOCK)/InstanceLock.
$(LOCK) can instead be defined to
specify the location of all lock files, not just the
condor_ master's InstanceLock.
If $(LOCK) is undefined, then the master log itself is locked.

ADD_WINDOWS_FIREWALL_EXCEPTION

When set to False, the
condor_ master will not automatically add Condor to the Windows
Firewall list of trusted applications. Such trusted applications can
accept incoming connections without interference from the firewall. This
only affects machines running Windows XP SP2 or higher. The default
is True.

WINDOWS_FIREWALL_FAILURE_RETRY

An integer value (default value is 60) that represents
the number of times the condor_ master will retry to add
firewall exceptions.
When a Windows machine boots
up, Condor starts up by default as well. Under certain conditions, the
condor_ master may have difficulty adding exceptions to the Windows
Firewall because of a delay in other services starting up.
Examples of services that may possibly be slow are the
SharedAccess service, the Netman service, or the Workstation service.
This configuration variable allows administrators to set the number of
times (once every 10 seconds) that the condor_ master will retry
to add firewall exceptions. A value of 0 means that Condor will
retry indefinitely.

3.3.10 condor_ startd
Configuration File Macros

NOTE: If you are running Condor on a multi-CPU machine, be sure
to also read section 3.13.7 on
page which describes how to set up and
configure Condor on SMP machines.

These settings control general operation of the condor_ startd.
Examples using these configuration macros,
as well as further explanation is found in
section 3.5 on
Configuring The Startd Policy.

START

A boolean expression
that, when True, indicates that the machine is willing
to start running a Condor job.
START is considered when the condor_ negotiator daemon
is considering evicting the job to replace it with one that will
generate a better rank for the condor_ startd daemon,
or a user with a higher priority.

SUSPEND

A boolean expression
that, when True, causes Condor to suspend running
a Condor job.
The machine may still be claimed, but the job makes no further
progress, and Condor does not generate a load on the machine.

PREEMPT

A boolean expression
that, when True, causes Condor to stop a currently
running job.

CONTINUE

A boolean expression
that, when True, causes Condor to continue the execution
of a suspended job.

KILL

A boolean expression
that, when True, causes Condor to immediately stop the
execution of a currently running job, without delay, and
without taking the time to produce a checkpoint (for a standard
universe job).

RANK

A floating point value
that Condor uses to compare potential jobs.
A larger value for a specific job ranks that job above
others with lower values for RANK.

IS_VALID_CHECKPOINT_PLATFORM

A boolean expression that is logically anded with the
with the START expression to limit which machines a
standard universe job may continue execution on once they have
produced a checkpoint.
The default expression is

A boolean expression
that, when True, tells Condor to evaluate the SUSPEND expression.

WANT_VACATE

A boolean expression
that, when True, defines that a preempted
Condor job is to be vacated, instead of killed.

IS_OWNER

A boolean expression that
defaults to being defined as

IS_OWNER = (START =?= FALSE)

Used to describe the state of the machine with respect to its use
by its owner.
Job ClassAd attributes are not used in defining IS_OWNER,
as they would be Undefined.

STARTER

This macro holds the
full path to the condor_ starter binary that the condor_ startd should
spawn.
It is normally defined relative to $(SBIN).

ALTERNATE_STARTER_1

This macro holds the full path to the condor_ starter.pvm
binary that the condor_ startd spawns to service PVM jobs. It is normally
defined relative to $(SBIN), since by default,
condor_ starter.pvm is installed in the regular Condor release
directory.

POLLING_INTERVAL

When a
condor_ startd enters the claimed state, this macro determines how often
the state of the machine is polled to check the need to suspend, resume,
vacate or kill the job. It is defined in terms of seconds and defaults to
5.

UPDATE_INTERVAL

Determines how often the condor_ startd should send a ClassAd update
to the condor_ collector. The condor_ startd also sends update on any
state or activity change, or if the value of its START expression
changes. See section 3.5.6 on condor_ startd
states, section 3.5.7 on condor_ startd
Activities, and section 3.5.3 on condor_ startdSTART expression for details on states, activities, and the
START expression. This macro is defined in
terms of seconds and defaults to 300 (5 minutes).

MAXJOBRETIREMENTTIME

An integer value representing the number of seconds allotted as
a retirement. The default value of 0 (when the configuration
variable is not present) implements the expected policy that
there is no retirement time.
See MAXJOBRETIREMENTTIME in
section 3.5.9 for further explanation.

CLAIM_WORKLIFE

If provided, this expression specifies
the number of seconds during which a claim will continue accepting new
jobs. Once this time expires, any existing job may continue to run as
usual, but once it finishes or is preempted, the claim is closed.
This may be useful if you want to force periodic renegotiation of
resources without preemption having to occur. For example, if you
have some low-priority jobs which should never be interrupted with
kill signals, you could prevent them from being killed with
MaxJobRetirementTime, but now high-priority jobs may have to
wait in line when they match to a machine that is busy running one of
these uninterruptible jobs. You can prevent the high-priority jobs
from ever matching to such a machine by using a rank expression in the
job or in the negotiator's rank expressions, but then the low-priority
claim will never be interrupted; it can keep running more jobs. The
solution is to use CLAIM_WORKLIFE to force the claim to stop
running additional jobs after a certain amount of time.
The default value for CLAIM_WORKLIFE is -1, which is treated
as an infinite claim worklife, so claims may be held indefinitely
(as long as they are not preempted and the schedd does not
relinquish them, of course).

MAX_CLAIM_ALIVES_MISSED

The condor_ schedd sends periodic updates
to each condor_ startd as a keep alive (see the description of
ALIVE_INTERVAL on page ).
If the condor_ startd does not receive any keep alive messages, it assumes
that something has gone wrong with the condor_ schedd and that the resource
is not being effectively used.
Once this happens, the condor_ startd considers the claim to have timed out,
it releases the claim, and starts advertising itself as available
for other jobs.
Because these keep alive messages are sent via UDP, they are
sometimes dropped by the network.
Therefore, the condor_ startd has some tolerance for missed keep alive
messages, so that in case a few keep alives are lost, the condor_ startd
will not immediately release the claim.
This setting controls how many keep alive messages can be missed
before the condor_ startd considers the claim no longer valid.
The default is 6.

STARTD_HAS_BAD_UTMP

When the condor_ startd is computing the idle time of all the
users of the machine (both local and remote), it checks the
utmp file to find all the currently active ttys, and only
checks access time of the devices associated with active logins.
Unfortunately, on some systems, utmp is unreliable, and the
condor_ startd might miss keyboard activity by doing this. So, if your
utmp is unreliable, set this macro to True and the
condor_ startd will check the access time on all tty and pty devices.

CONSOLE_DEVICES

This
macro allows the condor_ startd to monitor console (keyboard and mouse)
activity by checking the access times on special files in
/dev. Activity on these files shows up as
ConsoleIdle
time in the condor_ startd's ClassAd. Give a comma-separated list of
the names of devices considered the console, without the
/dev/ portion of the pathname. The defaults vary from
platform to platform, and are usually correct.

One possible exception to this is on Linux, where
we use ``mouse'' as
one of the entries. Most Linux installations put in a
soft link from /dev/mouse that points to the appropriate
device (for example, /dev/psaux for a PS/2 bus mouse, or
/dev/tty00 for a serial mouse connected to com1). However,
if your installation does not have this soft link, you will either
need to put it in (you will be glad you did), or change this
macro to point to the right device.

Unfortunately, there are no such devices on Digital Unix
(don't be fooled by /dev/keyboard0; the kernel does not
update the access times on these devices), so this macro is not
useful in these cases, and we must use the condor_ kbdd to get this
information by connecting to the X server.

STARTD_JOB_EXPRS

When
the machine is claimed by a remote user, the condor_ startd can also advertise
arbitrary attributes from the job ClassAd in the machine
ClassAd.
List the attribute names to be advertised. NOTE: Since
these are already ClassAd expressions, do not do anything
unusual with strings.
This setting defaults to ``JobUniverse''.

Starting with version 6.7.10, the condor_ startd can be configured
to write out the ClaimId for the next available claim on all
virtual machines to separate files.
This boolean attribute controls whether the condor_ startd should
write these files.
The default value is true.

STARTD_CLAIM_ID_FILE

This macro controls what file names are used if the above
STARTD_SHOULD_WRITE_CLAIM_ID_FILE is true. By
default, Condor will write the ClaimId into a file in the
$(LOG) directory called .startd_claim_id.vmX, where
X is the value of VirtualMachineID, the integer that
identifies a given virtual machine on the system, or 1 on a
single-VM machine.
If you define your own value for this setting, you should provide a
full path, and Condor will automatically append the .vmX
portion of the file name.

NUM_CPUS

This macro can be used to ``lie'' to the condor_ startd about how many CPUs
your machine has.
If you set this, it will override Condor's automatic computation of
the number of CPUs in your machine, and Condor will use whatever
integer you specify here.
In this way, you can allow multiple Condor jobs to run on a
single-CPU machine by having that machine treated like an SMP
machine with multiple CPUs, which could have different Condor jobs
running on each one.
Or, you can have an SMP machine advertise more virtual machines than
it has CPUs.
However, using this parameter will hurt the performance of the jobs,
since you would now have multiple jobs running on the same CPU,
competing with each other.
The option is only meant for people who specifically want this
behavior and know what they are doing.
It is disabled by default.

NOTE: This setting cannot be changed with a simple reconfig (either
by sending a SIGHUP or using condor_ reconfig.
If you change this, you must restart the condor_ startd for the
change to take effect (by using ``condor_ restart -startd'').

NOTE: If you use this setting on a given machine, you should
probably advertise that fact in the machine's ClassAd by using the
STARTD_ATTRS setting (described above).
This way, jobs submitted in your pool could specify that they did or
did not want to be matched with machines that were only really
offering ``fractional CPUs''.

MAX_NUM_CPUS

This macro will cap the number of CPUs detected by Condor on a machine.
If you set NUM_CPUS this cap is ignored.
If it is set to zero, there is no cap.
If it is not defined in the config file, it defaults to zero and there is
no cap.

NOTE: This setting cannot be changed with a simple reconfig (either
by sending a SIGHUP or using condor_ reconfig.
If you change this, you must restart the condor_ startd for the
change to take effect (by using ``condor_ restart -startd'').

COUNT_HYPERTHREAD_CPUS

This macro controls how Condor sees hyperthreaded
processors. When set to True (the default), it includes virtual CPUs in
the default value of NUM_CPUS. On dedicated cluster nodes,
counting virtual CPUs can sometimes improve total throughput at the expense
of individual job speed. However, counting them on desktop workstations can
interfere with interactive job performance.

How much memory would you like reserved from Condor? By default,
Condor considers all the physical memory of your machine as
available to be used by Condor jobs. If RESERVED_MEMORY is
defined, Condor subtracts it from the amount of memory it advertises
as available.

STARTD_NAME

Used to give an alternative name in the condor_ startd's
class ad.
This esoteric configuration macro might be used in the situation
where there are two condor_ startd daemons running on one machine,
and each reports to the same condor_ collector.
Different names will distinguish the two daemons.
See the description of MASTER_NAME in
section 3.3.9 on page
for a description of valid Condor daemon names.

RUNBENCHMARKS

Specifies when to run benchmarks.
When the machine is in the Unclaimed state and this expression
evaluates to True, benchmarks will be run.
If RunBenchmarks is specified and set to anything other than False,
additional benchmarks will be run when the condor_ startd initially starts.
To disable startup benchmarks, set RunBenchmarks to False,
or comment it out of the configuration file.

DedicatedScheduler

A string that identifies the dedicated scheduler.
See section 3.13.8
on page for details.

These macros control if the condor_ startd daemon should perform
backfill computations whenever resources would otherwise be idle.
See section 3.13.9 on page on
Configuring Condor for Running Backfill Jobs for details.

ENABLE_BACKFILL

A boolean
value that, when True, indicates that the machine is willing
to perform backfill computations when it would otherwise be idle.
This is not a policy expression that is evaluated, it is a simple
True or False.
This setting controls if any of the other backfill-related
expressions should be evaluated.
The default is False.

BACKFILL_SYSTEM

A string
that defines what backfill system to use for spawning and managing
backfill computations.
Currently, the only supported value for this is "BOINC", which
stands for the Berkeley Open Infrastructure for Network
Computing.
See http://boinc.berkeley.edu
for more information about
BOINC.
There is no default value, administrators must define this.

START_BACKFILL

A boolean
expression that is evaluated whenever a Condor resource is in the
Unclaimed/Idle state and the ENABLE_BACKFILL expression
is True.
If START_BACKFILL evaluates to True, the machine
will enter the Backfill state and attempt to spawn a backfill
computation.
This expression is analogous to the START expression that
controls when a Condor resource is available to run normal Condor
jobs.
The default value is False (which means do not spawn a
backfill job even if the machine is idle and
ENABLE_BACKFILL expression is True).
For more information about policy expressions and the Backfill
state, see section 3.5 beginning on
page , especially
sections 3.5.6, 3.5.7, and
3.5.8.

EVICT_BACKFILL

A boolean
expression that is evaluated whenever a Condor resource is in the
Backfill state which, when True, indicates the machine should
immediately kill the currently running backfill computation and
return to the Owner state.
This expression is a way for administrators to define a policy where
interactive users on a machine will cause backfill jobs to be
removed.
The default value is False.
For more information about policy expressions and the Backfill
state, see section 3.5 beginning on
page , especially
sections 3.5.6, 3.5.7, and
3.5.8.

These macros only apply to the condor_ startd daemon when it is running on an
SMP machine.
See section 3.13.7 on
page on Configuring The Startd for
SMP Machines for details.

STARTD_RESOURCE_PREFIX

A string which specifies what prefix to give the unique Condor
resources that are advertised on SMP machines.
Currently, Condor uses the term virtual machine to describe
these resources, so the default value for this setting is ``vm''.
However, to avoid confusion with other kinds of virtual machines
(the ones created using tools like VMware or Xen), in a future
version of Condor, the current virtual machine terminology
will change.
To aid in the transition to the new terms (and to provide a means
for sites that want to keep using ``vm'' even after the default has
changed), this setting enables sites to define what string the
condor_ startd will use to name the individual resources on an SMP
machine.

VIRTUAL_MACHINES_CONNECTED_TO_CONSOLE

An integer which indicates how many of the virtual
machines the condor_ startd is representing should be "connected" to the
console (in other words, notice when there's console activity).
This defaults to all virtual machines (N in a machine with N CPUs).

VIRTUAL_MACHINES_CONNECTED_TO_KEYBOARD

An integer which indicates how many of the virtual
machines the condor_ startd is representing should be "connected" to the
keyboard (for remote tty activity, as well as console activity).
Defaults to 1.

DISCONNECTED_KEYBOARD_IDLE_BOOST

If there are virtual machines not connected to either the keyboard
or the console, the corresponding idle time reported will be the
time since the condor_ startd was spawned, plus the value of this macro.
It defaults to 1200 seconds (20 minutes).
We do this because if the virtual machine is configured not to care
about keyboard activity, we want it to be available to Condor jobs
as soon as the condor_ startd starts up, instead of having to wait for 15
minutes or more (which is the default time a machine must be idle
before Condor will start a job).
If you do not want this boost, set the value to 0.
If you change your START expression to require more than 15 minutes
before a job starts, but you still want jobs to start right away on
some of your SMP nodes, increase this macro's value.

STARTD_VM_EXPRS

The list of ClassAd attribute names that should be shared across all
virtual machines on the same machine.
For each attribute in the list, the attribute's value is taken from
each virtual machine's machine ClassAd and placed into the machine
ClassAd of all the other virtual machines within the machine.
For example, if the configuration file for a 2-VM machine
contains

STARTD_VM_EXPRS = State, Activity, EnteredCurrentActivity

then the machine ClassAd for both virtual machines will contain
attributes that will be of the form:

The following settings control the number of virtual machines reported
for a given SMP host, and what attributes each one has.
They are only needed if you do not want to have an SMP machine report
to Condor with a separate virtual machine for each CPU, with all
shared system resources evenly divided among them.
Please read section 3.13.7 on
page for details on how to properly configure
these settings to suit your needs.

NOTE: You can only change the number of each type of virtual machine
the condor_ startd is reporting with a simple reconfig (such as
sending a SIGHUP signal, or using the condor_ reconfig command).
You cannot change the definition of the different virtual machine
types with a reconfig.
If you change them, you must restart the condor_ startd for the
change to take effect (for example, using
condor_restart -startd).

MAX_VIRTUAL_MACHINE_TYPES

The maximum number of different virtual machine types.
Note: this is the maximum number of different types, not of
actual virtual machines.
Defaults to 10.
(You should only need to change this setting if you define more than
10 separate virtual machine types, which would be pretty rare.)

VIRTUAL_MACHINE_TYPE_<N>

This setting defines a given virtual machine type, by specifying
what part of each shared system resource (like RAM, swap space, etc)
this kind of virtual machine gets.
N can be any integer from 1 to the value of
$(MAX_VIRTUAL_MACHINE_TYPES), such as
VIRTUAL_MACHINE_TYPE_1.
The format of this entry can be somewhat complex, so please refer to
section 3.13.7 on page for
details on the different possibilities.

NUM_VIRTUAL_MACHINES_TYPE_<N>

This macro controls how many of a given virtual machine type
are actually reported to Condor.
There is no default.

NUM_VIRTUAL_MACHINES

If your SMP machine is being evenly divided, and the virtual
machine type settings described above are not being used, this
macro controls how many virtual machines will be reported.
The default is one virtual machine for each CPU.
This setting can be used to reserve some CPUs on an SMP which would
not be reported to the Condor pool.

The following macros describe the cron capabilities of Condor.
The cron mechanism is used to run executables (called
modules) directly from the condor_ startd daemon.
The output from modules
is incorporated into the machine ClassAd generated by the
condor_ startd. These capabilities are used in Hawkeye, but can be
used in other situations as well.

These configuration macros are divided into three sets.
The three sets occurred as the functionality and usage of
Condor's cron capabilities evolved.
The first set applies to both new and older macros and syntax.
The second set applies to the new macros and syntax.
The third set applies only to the older (and outdated) macros and syntax.

This first set of configuration macros applies to both new
and older macros and syntax.

STARTD_CRON_NAME

Defines a logical name to be used in the formation of related
configuration macro names. While
not required, this macro makes other macros
more readable and maintainable. A common example is

STARTD_CRON_NAME = HAWKEYE

This example allows the naming of other related macros
to contain the string "HAWKEYE" in their name.

STARTD_CRON_CONFIG_VAL

This configuration variable can be used to specify the
condor_ config_val program which the modules (jobs) should use to
get configuration information from the daemon. If this is provided,
a environment variable by the same name with the same value will be
passed to all modules.

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_CONFIG_VAL to
$(STARTD_CRON_NAME)_CONFIG_VAL. Exmaple:

HAWKEYE_CONFIG_VAL = /usr/local/condor/bin/condor_config_val

STARTD_CRON_AUTOPUBLISH

Optional setting that determines if the condor_ startd should
automatically publish a new update to the condor_ collector after
any of the cron modules produce output.
Beware that enabling this setting can greatly increase the network
traffic in a Condor pool, especially when many modules are
executed, or if the period in which they run is short.
There are three possible (case insensitive) values for this
setting:

Never

This default value causes the
condor_ startd to not automatically publish updates based on
any cron modules. Instead, updates rely on the usual behavior for sending
updates, which is periodic, based on the UPDATE_INTERVAL
configuration setting, or whenever a given virtual machine
changes state.

Always

Causes the condor_ startd to always send a new
update to the condor_ collector whenever any module exits.

If_Changed

Causes the condor_ startd to only send a
new update to the condor_ collector if the output produced by a
given module is different than the previous output of the
same module.
The only exception is the LastUpdate attribute
(automatically set for all cron modules to be the timestamp when
the module last ran), which is ignored when
STARTD_CRON_AUTOPUBLISH is set to If_Changed.

Beware that STARTD_CRON_AUTOPUBLISH does not honor the
STARTD_CRON_NAME setting described above.
Even if STARTD_CRON_NAME is defined,
STARTD_CRON_AUTOPUBLISH will have the same name.

The following
second set of configuration macros applies only to the new
macros and syntax.
This set is to be used for all new applications.

STARTD_CRON_JOBLIST

This configuration variable is defined by a whitespace separated
list of job names (called modules) to run.
Each of these is the logical name of the module. This name
must be unique (no two modules may have the same name).

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_JOBLIST to
$(STARTD_CRON_NAME)_JOBLIST.

STARTD_CRON_<ModuleName>_PREFIX

Specifies a string which is prepended by
Condor to all attribute names that the module generates. For
example, if a prefix is ``xyz_'', and an individual attribute is
named ``abc'', the resulting attribute would be ``xyz_abc''.
Although it can be quoted, the prefix can contain only
alpha-numeric characters.

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_PREFIX to
$(STARTD_CRON_NAME)_<ModuleName>_PREFIX.

STARTD_CRON_<ModuleName>_EXECUTABLE

Used to specify the full path to the
executable to run for this module. Note that multiple modules may
specify the same executable (although they need to have different
names).

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_EXECUTABLE to
$(STARTD_CRON_NAME)_<ModuleName>_EXECUTABLE.

STARTD_CRON_<ModuleName>_PERIOD

The period specifies time intervals at
which the module should be run.
For periodic modules, this
is the time interval that passes between starting the execution
of the module.
The value may be specified in seconds (append value with the
character 's'), in minutes (append value with the character 'm'),
or in hours (append value with the character 'h').
As an example, 5m starts the execution of the module every five minutes.
If no character is appended to the value, seconds are used as a default.
For ``Wait For Exit'' mode, the value has a different meaning; in
this case
the period specifies the length of time after the module ceases execution
before it is restarted.
The minimum valid value of the period is 1 second.

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_PERIOD to
$(STARTD_CRON_NAME)_<ModuleName>_PERIOD.

STARTD_CRON_<ModuleName>_MODE

Used to specify the ``Mode'' in which the module operates.
Legal values are ``WaitForExit'' and ``Periodic'' (the
default).

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_MODE to
$(STARTD_CRON_NAME)_<ModuleName>_MODE.

The default ``Periodic'' mode is used for most modules. In
this mode, the module is expected to be started by the
condor_ startd daemon, gather and publish its data, and then
exit.

The ``WaitForExit'' mode is used to specify a module
which runs in the ``Wait For Exit'' mode.
In this mode, the condor_ startd daemon
interprets the ``period'' differently. In this case, it
refers to the amount of time to wait after the module exits
before restarting it. With a value of 1, the module is kept
running nearly continuously.

In general, ``Wait For Exit'' mode is for modules that produce
a periodic stream of updated data, but it can be used for other
purposes, as well.

STARTD_CRON_<ModuleName>_RECONFIG

The ``ReConfig'' macro is used to specify whether a module
can handle HUP signals, and should be sent a HUP signal when
the condor_ startd daemon is reconfigured. The module is
expected to reread its configuration at that time. A value
of ``True'' enables this setting, and ``False'' disables it.

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_RECONFIG to
$(STARTD_CRON_NAME)_<ModuleName>_RECONFIG.

STARTD_CRON_<ModuleName>_KILL

The ``Kill'' macro is applicable on for modules running in the
``Periodic'' mode. Possible values are ``True'' and ``False'' (the
default).

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_KILL to
$(STARTD_CRON_NAME)_<ModuleName>_KILL.

This macro controls the behavior of the condor_ startd when it
detects that the module's executable is still running when it is time
to start the module for a run. If enabled, the
condor_ startd will kill and restart the process in this
condition. If not enabled, the existing process is allowed to
continue running.

STARTD_CRON_<ModuleName>_ARGS

The command line arguments to pass to the module to be executed.

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_ARGS to
$(STARTD_CRON_NAME)_<ModuleName>_ARGS.

STARTD_CRON_<ModuleName>_ENV

The environment string to pass to the module.
The syntax is the same as that of
DAEMONNAME_ENVIRONMENT in 3.3.9.

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_ENV to
$(STARTD_CRON_NAME)_<ModuleName>_ENV.

STARTD_CRON_<ModuleName>_CWD

The working directory in which to start the module.

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_CWD to
$(STARTD_CRON_NAME)_<ModuleName>_CWD.

STARTD_CRON_<ModuleName>_OPTIONS

A colon separated list of options.
Not all combinations of options make sense;
when a nonsense combination is listed,
the last one in the list is followed.

If STARTD_CRON_NAME
is defined, then this configuration macro name is changed from
STARTD_CRON_<ModuleName>_OPTIONS to
$(STARTD_CRON_NAME)_<ModuleName>_OPTIONS.

The following
third set of configuration macros applies only to older
macros and syntax.
This set is documented for completeness and backwards
compatibility.
Do not use these configuration macros for any new application.
Future releases of Condor may disable the use of this set.

STARTD_CRON_JOBS

The list of the modules to execute. In Hawkeye, this is usually
named HAWKEYE_JOBS.
This configuration variable is defined by
a whitespace or newline separated list of jobs (called modules) to run,
where each module is specified using the format

modulename:prefix:executable:period[:options]

Each of these fields can be surrounded by matching quote characters
(single quote or double quote, but they must match). This allows
colon and whitespace characters to be specified. For example, the
following specifies an executable name with a colon and a space in it:

foo:foo_:"c:/some dir/foo.exe":10m

These individual fields are described below:

modulename The logical name of the module. This
must be unique (no two modules may have the same name). See
STARTD_CRON_JOBLIST

prefix
See STARTD_CRON_<ModuleName>_PREFIX

executable
See STARTD_CRON_<ModuleName>_EXECUTABLE

period
See STARTD_CRON_<ModuleName>_PERIOD

Several options are available. Using more than one
of these options for one module does not make sense. If this happens,
the last one in the list is followed.
See STARTD_CRON_<ModuleName>_OPTIONS

The ``Continuous'' option is used to specify a module
which runs in continuous mode (as described above). See the
``WaitForExit'' and ``ReConfig'' options which replace
``Continuous''.

This option is now deprecated, and its functionality has been
replaced by the new ``WaitForExit'' and ``ReConfig'' options,
which together implement the capabilities of ``Continuous''.
This option will be removed from a future version of Condor.

The ``WaitForExit'' option

See the discussion of ``WaitForExit'' in
STARTD_CRON_<ModuleName>_OPTIONS above.

The ``ReConfig'' option

See the discussion of ``ReConfig in
STARTD_CRON_<ModuleName>_OPTIONS above.

The `NoReConfig'' option

See the discussion of ``NoReConfig in
STARTD_CRON_<ModuleName>_OPTIONS above.

The ``Kill'' option

See the discussion of ``Kill'' in
STARTD_CRON_<ModuleName>_OPTIONS above.

The ``NoKill'' option

See the discussion of ``NoKill'' in
STARTD_CRON_<ModuleName>_OPTIONS above.

NOTE: The configuration file parsing logic will strip whitespace from
the beginning and end of continuation lines. Thus, a job list like
below will be misinterpreted and will not work as expected:

The following macros control the optional computation of resource
availability statistics in the condor_ startd.

STARTD_COMPUTE_AVAIL_STATS

A boolean that determines if the condor_ startd computes resource
availability statistics. The default is False.

If STARTD_COMPUTE_AVAIL_STATS = True, the condor_ startd will
define the following ClassAd attributes for resources:

AvailTime

The proportion of the time (between 0.0 and 1.0)
that this resource has been in a state other than Owner.

LastAvailInterval

The duration (in seconds) of the last period between Owner states.

The following attributes will also be included if the resource is
not in the Owner state:

AvailSince

The time at which the resource last left the
Owner state. Measured in the number of seconds since the
epoch (00:00:00 UTC, Jan 1, 1970).

AvailTimeEstimate

Based on past history, an estimate
of how long the current period between Owner states will last.

STARTD_AVAIL_CONFIDENCE

A floating point number representing the confidence level of the
condor_ startd daemon's AvailTime estimate.
By default, the estimate is based on
the 80th percentile of past values
(that is, the value is initially set to 0.8).

STARTD_MAX_AVAIL_PERIOD_SAMPLES

An integer that limits the number of samples of past available
intervals stored by the condor_ startd to limit memory and disk consumption.
Each sample requires 4 bytes of memory and approximately 10 bytes of
disk space.

The following configuration variables support java universe jobs.

JAVA

The full path to the Java interpreter (the Java Virtual Machine).

JAVA_MAXHEAP_ARGUMENT

An incomplete command line argument to the Java interpreter
(the Java Virtual Machine)
to specify the switch name for the Maxheap Argument.
Condor uses it to construct the maximum heap size
for the Java Virtual Machine.
For example, the value for the Sun JVM is -Xmx.

JAVA_CLASSPATH_ARGUMENT

The command line argument to the Java interpreter (the Java Virtual Machine)
that specifies the Java Classpath.
Classpath is a Java-specific term that denotes the list of
locations (.jar files and/or directories)
where the Java interpreter can
look for the Java class files that a Java program requires.

JAVA_CLASSPATH_SEPARATOR

The single character used to delimit constructed entries in the
Classpath for the given operating system and Java Virtual Machine.
If not defined, the operating system is queried for its default
Classpath separator.

JAVA_CLASSPATH_DEFAULT

A list of path names to .jar files to be added to the Java Classpath
by default.
The comma and/or space character delimits list entries.

JAVA_EXTRA_ARGUMENTS

A list of additional arguments to be passed to the Java executable.

3.3.11 condor_ schedd
Configuration File Entries

These macros control the condor_ schedd.

SHADOW

This macro determines the
full path of the condor_ shadow binary that the condor_ schedd
spawns. It is normally defined in terms of $(SBIN).

SHADOW_PVM

This macro
determines the full path of the special condor_ shadow.pvm binary
used for supporting PVM jobs that the condor_ schedd spawns. It is
normally defined in terms of $(SBIN).

START_LOCAL_UNIVERSE

A boolean value that defaults to True.
The condor_ schedd uses this macro to determine whether to start
a local universe job.
At intervals determined by SCHEDD_INTERVAL,
the condor_ schedd daemon evaluates this macro
for each idle local universe job that it has.
For each job, if the START_LOCAL_UNIVERSE
macro is True, then the job's Requirements expression
is evaluated. If both conditions are met, then the job is allowed
to begin execution.

The following example only allows 10 local universe jobs to
execute concurrently. The attribute TotalLocalJobsRunning
is supplied by condor_ schedd's ClassAd:

START_LOCAL_UNIVERSE = TotalLocalJobsRunning < 10

START_SCHEDULER_UNIVERSE

A boolean value that defaults to True.
The condor_ schedd uses this macro to determine whether to start
a scheduler universe job.
At intervals determined by SCHEDD_INTERVAL,
the condor_ schedd daemon evaluates this macro
for each idle scheduler universe job that it has.
For each job, if the START_SCHEDULER_UNIVERSE
macro is True, then the job's Requirements expression
is evaluated. If both conditions are met, then the job is allowed
to begin execution.

The following example only allows 10 scheduler universe jobs to
execute concurrently. The attribute TotalSchedulerJobsRunning
is supplied by condor_ schedd's ClassAd:

START_SCHEDULER_UNIVERSE = TotalSchedulerJobsRunning < 10

MAX_JOBS_RUNNING

This
macro limits the number of processes spawned by a given
condor_ schedd, for all job universes except the
grid universe. See section 2.4.1.
This includes, but is not limited to condor_ shadow processes,
and scheduler universe processes, including condor_ dagman.
The actual
number of condor_ shadows may be less if you have reached
your $(RESERVED_SWAP) limit.
This macro has a default value of 200.

MAX_SHADOW_EXCEPTIONS

This macro controls the maximum
number of times that condor_ shadow processes can have a fatal
error (exception) before the condor_ schedd will relinquish
the match associated with the dying shadow. Defaults to 5.

SCHEDD_INTERVAL

This
macro determines both how often the condor_ schedd sends a ClassAd
update to the condor_ collector and how often the condor_ schedd
daemon evaluates jobs. It is defined in terms of seconds
and defaults to 300 (every 5 minutes).

JOB_START_COUNT

This macro works together with the JOB_START_DELAY macro
to throttle job starts.
The default and minimum values for this
integer configuration variable are both 1.
Small values for this macro are preferred and will
minimize the load upon the condor_ schedd daemon.

JOB_START_DELAY

This integer-valued macro works together with the
JOB_START_COUNT macro
to throttle job starts. The condor_ schedd daemon starts
$(JOB_START_COUNT) jobs at a time, then delays for
$(JOB_START_DELAY) seconds before starting the next set of jobs.
This delay prevents a sudden, large load on the submit
machine as it spawns many condor_ shadow daemons simultaneously,
and it prevents having to deal
with their start up activity all at once.
The resulting job start rate
averages as fast as
($(JOB_START_COUNT)/$(JOB_START_DELAY)) jobs/second.
This configuration variable is also used during the graceful shutdown of the
condor_ schedd daemon.
During graceful shutdown, this macro determines the wait time in
between requesting each condor_ shadow daemon to gracefully shut down.
It is defined in terms of seconds and defaults to 2.
Setting this macro to a lower value is not advised,
as it can overwhelm the condor_ schedd daemon.

JOB_IS_FINISHED_INTERVAL

The condor_ schedd maintains a list of jobs that are ready to permanently
leave the job queue, e.g. they have completed or been removed. This
integer-valued macro specifies a delay in seconds to place between the
taking jobs permanently out of the queue. The default value is 0, which
tells the condor_ schedd to not impose any delay.

ALIVE_INTERVAL

This
macro determines how often the condor_ schedd should send a keep
alive message to any condor_ startd it has claimed.
When the condor_ schedd claims a condor_ startd, it tells the condor_ startd how often it is
going to send these messages.
If the condor_ startd does not receive any of these keep alive messages
during a certain period of time (defined via
MAX_CLAIM_ALIVES_MISSED, described on
page )
the condor_ startd releases the claim, and the condor_ schedd no longer pays for
the resource (in terms of user priority in the system).
The macro is defined in terms of seconds and defaults to 300 (every
5 minutes).

REQUEST_CLAIM_TIMEOUT

This macro sets the time (in
seconds) that the condor_ schedd will wait for a claim to be granted by the
condor_ startd. The default is 30 minutes. This is only likely to matter
if the condor_ startd has an existing claim and it takes a long time for the
existing claim to be preempted due to MaxJobRetirementTime.
Once a request times out, the condor_ schedd will simply begin the process
of finding a machine for the job all over again.

SHADOW_SIZE_ESTIMATE

This macro sets the estimated virtual memory size of each
condor_ shadow process. Specified in kilobytes. The default
varies from platform to platform.

SHADOW_RENICE_INCREMENT

When the condor_ schedd spawns a new
condor_ shadow, it can do so with a nice-level. A
nice-level is a
Unix mechanism that allows users to assign their own processes a lower
priority so that the processes do not interfere with interactive use of the
machine. This is very handy for keeping a submit machine with lots
of shadows running still useful to the owner of the machine. The
value can be any integer between 0 and 19, with a value of 19 being
the lowest priority. It defaults to 10.

SCHED_UNIV_RENICE_INCREMENT

Analogous to
JOB_RENICE_INCREMENT and
SHADOW_RENICE_INCREMENT, scheduler universe jobs can
be given a nice-level.
See JOB_RENICE_INCREMENT in
section 3.3.14 for further explanation;
default value and range of legal values are the same.

QUEUE_CLEAN_INTERVAL

The condor_ schedd maintains the job queue on a given machine. It does so
in a persistent way such that if the condor_ schedd crashes, it can recover
a valid state of the job queue. The mechanism it uses is a
transaction-based log file (the job_queue.log file,
not the SchedLog file). This file contains an initial
state of the job queue, and a series of transactions that were
performed on the queue (such as new jobs submitted, jobs completing,
and checkpointing). Periodically, the condor_ schedd will go through
this log, truncate all the transactions and create a new file with
containing only the new initial state of the log.
This is a somewhat expensive operation,
but it speeds up when the condor_ schedd restarts since there are
fewer transactions it has to play to figure out what state the job
queue is really in. This macro determines how often the condor_ schedd
should rework this queue to cleaning it up. It is defined in terms of
seconds and defaults to 86400 (once a day).

WALL_CLOCK_CKPT_INTERVAL

The job queue contains a counter for each job's ``wall clock'' run
time, i.e., how long each job has executed so far. This counter is
displayed by condor_ q. The counter is updated when the job is
evicted or when the job completes. When the condor_ schedd crashes, the run
time for jobs that are currently running will not be added to the
counter (and so, the run time counter may become smaller than the
cpu time counter). The condor_ schedd saves run time ``checkpoints''
periodically for running jobs so if the condor_ schedd crashes, only run
time since the last checkpoint is lost. This macro controls how
often the condor_ schedd saves run time checkpoints. It is defined in terms
of seconds and defaults to 3600 (one hour). A value of 0 will
disable wall clock checkpoints.

ALLOW_REMOTE_SUBMIT

Starting with Condor Version 6.0, users can run condor_ submit on
one machine and actually submit jobs to another machine in the
pool. This is called a remote submit. Jobs submitted in
this way are entered into the job queue owned by the Unix user
nobody.
This macro determines whether this is allowed.
It defaults to False.

QUEUE_ALL_USERS_TRUSTED

. Defaults to False. If set to True, then unauthenticated users are allowed
to write to the queue, and also we always trust whatever the Owner
value is set to be by the client in the job ad. This was added so users
can continue to use the SOAP web-services interface over HTTP (w/o
authenticating) to submit jobs in a secure, controlled environment - for
instance, in a portal setting.

QUEUE_SUPER_USERS

This
macro determines what user names on a given machine have
super-user access to the job queue, meaning that they can
modify or delete the job ClassAds of other users. (Normally, you
can only modify or delete ClassAds from the job queue that you own).
Whatever user name corresponds with the UID that Condor is running as
(usually the Unix user condor) will automatically be included in this list
because that is needed for Condor's proper functioning. See
section 3.6.10 on UIDs in Condor for more details on
this. By default, we give root the ability to remove other
user's jobs, in addition to user condor.

SCHEDD_LOCK

This macro
specifies what lock file should be used for access to the
SchedLog file. It must be a separate file from the
SchedLog, since the SchedLog may be rotated and
synchronization across log file rotations
is desired.
This macro is defined relative to the $(LOCK) macro.
If you decide to change this setting (not recommended),
be sure to change the $(VALID_LOG_FILES) entry that
condor_ preen uses as well.

SCHEDD_NAME

A unique name given for a condor_ schedd daemon on a machine.
Defaults to the fully qualified hostname of the machine where the
condor_ schedd is running.
However, this configuration macro is used to uniquely identify
condor_ schedd ClassAds if more than one condor_ schedd is running
on the same host, for example, with many Personal Condor
installations running as different users on the same machine.
In that case, the recommended form for SCHEDD_NAME is
username@full.host.name, where username is the
user that a given condor_ schedd is running as.

See the description of MASTER_NAME in
section 3.3.9 on page
for a description of valid Condor daemon names.
Also, note that if the MASTER_NAME setting is defined for
the condor_ master that spawned a given condor_ schedd, that name
will take precedence over whatever is defined in
SCHEDD_NAME.

A directory to use as a temporary sandbox for local universe jobs.
Defaults to $(SPOOL)/execute.

FLOCK_NEGOTIATOR_HOSTS

This macro defines a list of negotiator host names (not including the
local $(NEGOTIATOR_HOST) machine) for pools in which the
condor_ schedd should attempt to run jobs. Hosts in the list should be in
order of preference. The condor_ schedd will only send a request to a
central manager in the list if the local pool and pools earlier in
the list are not satisfying all the job requests.
$(HOSTALLOW_NEGOTIATOR_SCHEDD) (see
section 3.3.5) must also be configured to allow
negotiators from all of the $(FLOCK_NEGOTIATOR_HOSTS) to
contact the condor_ schedd. Please make sure the
$(NEGOTIATOR_HOST) is first in the
$(HOSTALLOW_NEGOTIATOR_SCHEDD) list. Similarly, the
central managers of the remote pools must be configured to listen to
requests from this condor_ schedd.

FLOCK_COLLECTOR_HOSTS

This macro defines a list of collector host names for pools in which
the condor_ schedd should attempt to run jobs. The
collectors must be specified in order, corresponding to the
$(FLOCK_NEGOTIATOR_HOSTS) list. In the typical case, where each pool
has the collector and negotiator running on the same machine,
$(FLOCK_COLLECTOR_HOSTS) should have the same definition as
$(FLOCK_NEGOTIATOR_HOSTS).

NEGOTIATE_ALL_JOBS_IN_CLUSTER

If this macro is set to False (the default), when the condor_ schedd fails
to start an idle job, it will not try to start any other
idle jobs in the same cluster during that negotiation cycle. This
makes negotiation much more efficient for large job clusters.
However, in some cases other jobs in the cluster can be started even
though an earlier job can't. For example, the jobs' requirements
may differ, because of different disk space, memory, or
operating system requirements. Or, machines may be willing to run
only some jobs in the cluster, because their requirements reference
the jobs' virtual memory size or other attribute. Setting this
macro to True will force the condor_ schedd to try to start all idle jobs in
each negotiation cycle. This will make negotiation cycles last
longer, but it will ensure that all jobs that can be started will be
started.

PERIODIC_EXPR_INTERVAL

This macro determines the period,
in seconds, between evaluation of periodic job control expressions,
such as periodic_hold, periodic_release, and periodic_remove,
given by the user in a Condor submit file. By default, this value is
300 seconds (5 minutes). A value of 0 prevents the condor_ schedd from
performing the periodic evaluations.

SCHEDD_ASSUME_NEGOTIATOR_GONE

This macro determines the period,
in seconds, that the condor_ schedd will wait for the condor_ negotiator to
initiate a negotiation cycle before the schedd will simply try to claim
any local condor_ startd. This allows for a machine that is acting as
both a submit and execute node to run jobs locally if it cannot
communicate with the central manager. The default value, if not
specified, is 4 x $(NEGOTIATOR_INTERVAL). If
$(NEGOTIATOR_INTERVAL) is not defined, then
SCHEDD_ASSUME_NEGOTIATOR_GONE will default to 1200 (20
minutes).

SCHEDD_ROUND_ATTR_<xxxx>

An integer-valued macro that
instructs the condor_ schedd to round up
scalar job ClassAd attributes to a specific number of decimal places. This is desirable to improve job
scheduling performance, since it allows Condor's auto-clustering algorithm
to bucket attributes such as ImageSize.
Replace <xxxx> with the name of the attribute to round, and set this
macro equal to the number of decimal places to round up. For example, to
round the value of job ClassAd attribute foo up to the nearest
100, set

SCHEDD_ROUND_ATTR_foo = 2

When the schedd rounds up an attribute value, it will save the raw
(un-rounded) actual value in an attribute with the same name appended
with ``_RAW". So in the above example, the raw value will be stored
in attribute foo_RAW in the job ClassAd.
The following are set by default:

Thus, the above attributes are all rounded up from Kbytes to the nearest
10 Megabytes.

SCHEDD_BACKUP_SPOOL

This macro is used to enable the
condor_ schedd to make a backup of the job queue as it starts. If
set to ``True'', the condor_ schedd will create host specific a
backup of the current spool file to the spool directory. This
backup file will be overwritten each time the condor_ schedd
starts. SCHEDD_BACKUP_SPOOL defaults to ``False''.

MPI_CONDOR_RSH_PATH

The complete path to the
special version of rsh that is required to spawn MPI
jobs under Condor.
$(LIBEXEC) is the proper value for this
configuration variable, required when running MPI dedicated jobs.

SCHEDD_PREEMPTION_REQUIREMENTS

This boolean expression is
utilized only for machines allocated by a dedicated scheduler.
When True, a machine becomes a candidate for job preemption.
This configuration variable has no default;
when not defined, preemption will never be considered.

SCHEDD_PREEMPTION_RANK

This floating point value is
utilized only for machines allocated by a dedicated scheduler.
It is evaluated in context of a job ClassAd,
and it represents a machine's preference for running a job.
This configuration variable has no default;
when not defined, preemption will never be considered.

ParallelSchedulingGroup

For parallel jobs which must be assigned within a group
of machines (and not cross group boundaries),
this configuration variable identifies members of a group.
Each machine within a group sets this configuration variable with
a string that identifies the group.

3.3.12 condor_ shadow
Configuration File Entries

These settings affect the condor_ shadow.

SHADOW_LOCK

This macro
specifies the lock file to be used for access to the
ShadowLog file. It must be a separate file from the
ShadowLog, since the ShadowLog may be rotated
and you want to synchronize access across log file rotations.
This macro is defined relative to the $(LOCK) macro.
If you decide to change this setting (not recommended),
be sure to change the $(VALID_LOG_FILES) entry that
condor_ preen uses as well.

SHADOW_DEBUG

This macro
(and other settings related to debug logging in the shadow) is
described in section 3.3.4 as
<SUBSYS>_DEBUG.

SHADOW_QUEUE_UPDATE_INTERVAL

The amount of time (in seconds) between ClassAd updates that the
condor_ shadow daemon sends to the condor_ schedd daemon.
Defaults to 900 (15 minutes).

COMPRESS_PERIODIC_CKPT

This boolean macro specifies
whether the shadow should instruct applications to compress periodic
checkpoints (when possible). The default is False.

COMPRESS_VACATE_CKPT

This boolean macro specifies
whether the shadow should instruct applications to compress vacate
checkpoints (when possible). The default is False.

PERIODIC_MEMORY_SYNC

This boolean macro specifies whether the shadow should instruct
applications to commit dirty memory pages to swap space during a
periodic checkpoint. The default is False. This potentially
reduces the number of dirty memory pages at vacate time, thereby
reducing swapping activity on the remote machine.

SLOW_CKPT_SPEED

This
macro specifies the speed at which vacate checkpoints should be
written, in kilobytes per second. If zero (the default), vacate
checkpoints are written as fast as possible. Writing vacate
checkpoints slowly can avoid overwhelming the remote machine with
swapping activity.

3.3.13 condor_ shadow.pvm
Configuration File Entries

These macros control the condor_ shadow.pvm, the special shadow
that supports PVM jobs inside Condor. See
section on Installing PVM Support in
Condor for details. condor_ shadow macros also apply to this
special shadow. See section 3.3.12.

PVMD

This macro holds the full path
to the special condor_ pvmd, the Condor PVM daemon. This daemon is
installed in the regular Condor release directory by default, so the
macro is usually defined in terms of $(SBIN).

PVMGS

This macro holds the full
path to the special condor_ pvmgs, the Condor PVM Group Server
daemon, which is needed to support PVM groups. This daemon is
installed in the regular Condor release directory by default, so the
macro is usually defined in terms of $(SBIN).

3.3.14 condor_ starter
Configuration File Entries

These settings affect the condor_ starter.

EXEC_TRANSFER_ATTEMPTS

Sometimes due to a router misconfiguration, kernel bug, or other Act
of God network problem, the transfer of the initial checkpoint from
the submit machine to the execute machine will fail midway through.
This parameter allows a retry of the transfer a certain number of times
that must be equal to or greater than 1. If this parameter is not
specified, or specified incorrectly, then it will default to three.
If the transfer of the initial executable fails every attempt, then
the job goes back into the idle state until the next renegotiation
cycle.

NOTE: : This parameter does not exist in the NT starter.

JOB_RENICE_INCREMENT

When the condor_ starter spawns a Condor job, it can do so with a
nice-level.
A nice-level is a
Unix mechanism that allows users to assign their own processes a lower
priority, such that these processes do not interfere with interactive
use of the machine.
If you have machines with lots
of real memory and swap space, so that the only scarce resource is CPU time,
you may use this macro in conjunction with a policy that
allows Condor to always start jobs on the machines.
Condor jobs would always run,
but interactive response on your machines would never suffer.
You most likely will not notice Condor is
running jobs. See section 3.5 on
Configuring The Startd Policy for more details on setting up a
policy for starting and stopping jobs on a given machine.

The value is an arbitrary ClassAd expression,
evaluated by the condor_ starter daemon for each job just before the
job runs, and the expression can refer to any attribute in the job ClassAd.
The range of allowable values are integers in the range of 0 to 19
(inclusive),
with a value of 19 being the lowest priority.
If the expression evaluates to a value outside this range,
then on a Unix machine, a value greater than 19 is auto-decreased to 19;
a value less than 0 is treated as 0.
For values outside this range, a Windows machine ignores the value
and uses the default instead.
The default value is 10, which maps to the idle priority class on
a Windows machine.

STARTER_LOCAL_LOGGING

This macro determines whether the
starter should do local logging to its own log file, or send debug
information back to the condor_ shadow where it will end up in the
ShadowLog. It defaults to True.

STARTER_DEBUG

This setting
(and other settings related to debug logging in the starter) is
described above in section 3.3.4 as
$(<SUBSYS>_DEBUG).

STARTER_UPDATE_INTERVAL

The amount of time (in seconds) between ClassAd updates that the
condor_ starter daemon sends to the condor_ shadow daemon.
Defaults to 1200 (20 minutes).

USER_JOB_WRAPPER

The full path to an executable or script.
This macro
allows an administrator to specify a wrapper script to handle the
execution of all user jobs.
If specified, Condor never directly executes a job, but instead
invokes the program specified by this macro.
The command-line arguments passed to this program will include the
full-path to the actual user job which should be executed, followed by all
the command-line parameters to pass to the user job.
This wrapper program must ultimately replace its image with the user job;
in other words,
it must exec the user job, not fork it.
For instance, if the wrapper program is a C/Korn shell script, the
last line of execution should be:

exec $*

This can potentially lose information about the arguments.
Any argument with embedded whitespace will be split into multiple
arguments.
For example the argument "argument one" will become the two arguments
"argument" and "one".
For Bourne type shells (sh, bash, ksh),
the following preserves the arguments:

exec "$@"

For the C type shells (csh, tcsh), the following preserves the
arguments:

exec $*:q

For Windows machines, the wrapper will either be
a batch script (with a file extension of .bat or .cmd)
or an executable (with a file extension of .exe or .com).

USE_VISIBLE_DESKTOP

This setting is only meaningful on Windows machines. If True, Condor will
allow the job to create windows on the desktop of the execute machine and
interact with the job. This is particularly useful for debugging why an
application will not run under Condor. If False, Condor uses the default
behavior of creating a new, non-visible desktop to run the job on.
See section 6.2 for details on how Condor
interacts with the desktop.

STARTER_JOB_ENVIRONMENT

This macro sets the default environment inherited by jobs. The syntax is
the same as the syntax for environment settings in the job submit file
(see page ).
If the same environment variable is assigned by this macro and by the user
in the submit file, the user's setting takes precedence.

JOB_INHERITS_STARTER_ENVIRONMENT

When set to true, this
causes jobs to inherit all environment variables from
condor_ starter. This is useful for glidein jobs that need to
access environment variables from the batch system running the glidein
daemons. If the user job or STARTER_JOB_ENVIRONMENT defines
an environment variable that also happens to be in condor_ starter's
environment, the the former overrides the latter in the job's
environment. The default for this configuration setting is false.
This feature does not apply to standard and pvm universe jobs.

3.3.15 condor_ submit
Configuration File Entries

DEFAULT_UNIVERSE

The universe under which a job is executed may be specified in the submit
description file.
If it is not specified in the submit description file, then
this variable specifies the universe (when defined).
If the universe is not specified in the submit description
file, and if this variable is not defined, then
the default universe for a job will be the standard universe.

If you want condor_ submit to automatically append an expression to
the Requirements expression or Rank expression of
jobs at your site use the following macros:

APPEND_REQ_VANILLA

Expression to be appended to vanilla job requirements.

APPEND_REQ_STANDARD

Expression to be appended to standard job requirements.

APPEND_REQUIREMENTS

Expression to be appended to any type of universe jobs.
However, if APPEND_REQ_VANILLA or APPEND_REQ_STANDARD
is defined, then ignore the APPEND_REQUIREMENTS for those
universes.

APPEND_RANK

Expression to be appended to job rank. APPEND_RANK_STANDARD or
APPEND_RANK_VANILLA will override this setting if defined.

APPEND_RANK_STANDARD

Expression to be appended to standard job rank.

APPEND_RANK_VANILLA

Expression to append to vanilla job rank.

NOTE: The APPEND_RANK_STANDARD and
APPEND_RANK_VANILLA macros were called
APPEND_PREF_STANDARD and
APPEND_PREF_VANILLA in previous versions of Condor.

In addition, you may provide default Rank expressions if your users
do not specify their own with:

DEFAULT_RANK_VANILLA

Default Rank for vanilla jobs.

DEFAULT_RANK_STANDARD

Default Rank for standard jobs.

Both of these macros default to the jobs preferring machines where
there is more main memory than the image size of the job, expressed
as:

((Memory*1024) > Imagesize)

DEFAULT_IO_BUFFER_SIZE

Condor keeps a buffer of recently-used data for each file an
application opens. This macro specifies the default maximum number
of bytes to be buffered for each open file at the executing machine.
The condor_ statusbuffer_size command will override this
default. If this macro is undefined, a default size of 512 KB will
be used.

DEFAULT_IO_BUFFER_BLOCK_SIZE

When buffering is enabled,
Condor will attempt to consolidate small read and write operations
into large blocks. This macro specifies the default block size
Condor will use. The condor_ statusbuffer_block_size
command will override this default. If this macro is undefined, a
default size of 32 KB will be used.

SUBMIT_SKIP_FILECHECK

If True, condor_ submit behaves as if the -d
command-line option is used.
This tells condor_ submit to disable file permission checks when
submitting a job.
This can significantly decrease the amount of time required to submit
a large group of jobs.
The default value is False.

SUBMIT_SEND_RESCHEDULE

A boolean expression that when False, prevents condor_ submit from
automatically sending a condor_ reschedule command as it completes.
The condor_ reschedule command causes the condor_ schedd daemon
to start searching for machines with which to match the submitted
jobs. When True, this step always occurs.
In the case that the machine where the job(s) are submitted is
managing a huge number of jobs (thousands or tens of thousands),
this step would hurt performance in such a way that it became
an obstacle to scalability.
The default value is True.

SUBMIT_EXPRS

The given comma-separated, named expressions are inserted into all
the job ClassAds that condor_ submit creates. This is equivalent
to the ``+'' syntax in submit files. See the
the condor_ submit manual page
on page for details on using the ``+''
syntax to add attributes to the job ClassAd.
Attributes defined in the submit description file with ``+'' will
override attributes defined in the config file with
SUBMIT_EXPRS.

LOG_ON_NFS_IS_ERROR

A boolean value that controls whether condor_ submit prohibits
job submit files with user log files on NFS. If
LOG_ON_NFS_IS_ERROR is set to True, such
submit files will be rejected. If LOG_ON_NFS_IS_ERROR
is set to False, submitting such a file results in a
warning, but the job will be submitted. If not defined,
LOG_ON_NFS_IS_ERROR defaults to False.

3.3.16 condor_ preen
Configuration File Entries

These macros affect condor_ preen.

PREEN_ADMIN

This macro
sets the e-mail address where condor_ preen will send e-mail (if
it is configured to send email at all... see the entry for
PREEN). Defaults to $(CONDOR_ADMIN).

VALID_SPOOL_FILES

This
macro contains a (comma or space separated) list of files that
condor_ preen considers valid files to find in the $(SPOOL)
directory. Defaults to all the files that are valid. A change
to the $(HISTORY) macro requires a change to this
macro as well.

VALID_LOG_FILES

This
macro contains a (comma or space separated) list of files that
condor_ preen considers valid files to find in the $(LOG)
directory. Defaults to all the files that are valid. A change
to the names of any of the log files above requires a change to this
macro as well. In addition, the defaults for the
$(<SUBSYS>_ADDRESS_FILE) are listed here, so a change to
those requires a change this entry as well.

3.3.17 condor_ collector
Configuration File Entries

These macros affect the condor_ collector.

CLASSAD_LIFETIME

This
macro determines the default maximum age for ClassAds collected by the
condor_ collector. ClassAd older than the maximum age are
discarded by the condor_ collector as stale.

If present, the ClassAd attribute ``ClassAdLifetime'' specifies the
ad's lifetime in seconds. If ``ClassAdLifetime'' is not present in
the ad, the condor_ collector will use the value of
$(CLASSAD_LIFETIME). The macro is defined in terms of
seconds, and defaults to 900 (15 minutes).

MASTER_CHECK_INTERVAL

This macro defines how often the
collector should check for machines that have ClassAds from some
daemons, but not from the condor_ master (orphaned daemons)
and send e-mail about it. It is defined in seconds and
defaults to 10800 (3 hours).

CLIENT_TIMEOUT

Network
timeout that the condor_ collector uses when talking to any daemons
or tools that are sending it a ClassAd update.
It is defined in seconds and defaults to 30.

QUERY_TIMEOUT

Network
timeout when talking to anyone doing a query. It is defined in seconds
and defaults to 60.

CONDOR_DEVELOPERS

By default,
Condor will send e-mail once per week to this address with the output
of the condor_ status command, which lists how many machines
are in the pool and how many are running jobs. The default
value of condor-admin@cs.wisc.edu
will send this report to
the Condor Team developers at the University of Wisconsin-Madison.
The Condor Team uses
these weekly status messages in order to have some idea as to how
many Condor pools exist in the world. We appreciate
getting the reports, as this is one way we can convince funding
agencies that Condor is being used in the real world.
If you do not wish this information to be sent to the Condor Team,
explicitly set the value to NONE to disable this feature,
or replace the
address with a desired location.
If undefined (commented out) in the configuration file, Condor follows
its default behavior.

COLLECTOR_NAME

This macro is used to specify a short description of your pool.
It should be about 20 characters long. For example, the name of the
UW-Madison Computer Science Condor Pool is ``UW-Madison CS''.
While this macro might seem similar to MASTER_NAME or
SCHEDD_NAME, it is totally unrelated.
Those settings are used to unique identify (and locate) a specific
set of Condor daemons if there are more than one running on the same
machine.
The COLLECTOR_NAME setting is just used as a
human-readable string to describe the pool, which is included in the
updates set to the CONDOR_DEVELOPERS_COLLECTOR (see
below).

CONDOR_DEVELOPERS_COLLECTOR

By default, every pool sends
periodic updates to a central condor_ collector at UW-Madison with
basic information about the status of your pool. This includes only
the number of total machines, the number of jobs submitted, the
number of machines running jobs, the host name of your central
manager, and the $(COLLECTOR_NAME) specified above. These
updates help the Condor Team see how Condor is being used around the world.
By default, they will be sent to condor.cs.wisc.edu.
If you do not want
these updates to be sent from your pool,
explicitly set this macro to NONE.
If undefined (commented out) in the configuration file, Condor follows
its default behavior.

COLLECTOR_SOCKET_BUFSIZE

This specifies the buffer size, in
bytes, reserved for condor_ collector network UDP sockets. The default is
10240000, or a ten megabyte buffer. This is a healthy size, even for a large
pool. The larger this value, the less likely the condor_ collector will
have stale information about the pool due to dropping update packets. If
your pool is small or your central manager has very little RAM, considering
setting this parameter to a lower value (perhaps 256000 or 128000).

NOTE: For some Linux distributions, it may be neccessary to configure
a larger value than the default; this parameter is
/proc/sys/net/core/rmem_max . You can see the values that the
condor_ collector actually used by enabling D_FULLDEBUG for the
collector and looking at the log line that looks like this:

Reset OS socket buffer size to 2048k (UDP), 255k (TCP).

COLLECTOR_TCP_SOCKET_BUFSIZE

This specifies the TCP buffer
size, in bytes, reserved for condor_ collector network sockets. The
default is 131072, or a 128 kilobyte buffer. This is a healthy size, even
for a large pool. The larger this value, the less likely the
condor_ collector will have stale information about the pool due to
dropping update packets. If your pool is small or your central
manager has very little RAM, considering setting this parameter to a
lower value (perhaps 65536 or 32768).

NOTE: See the note for COLLECTOR_SOCKET_BUFSIZE.

COLLECTOR_SOCKET_CACHE_SIZE

If your site wants to use TCP connections to send ClassAd updates to
the collector, you must use this setting to enable a cache of TCP
sockets (in addition to enabling
UPDATE_COLLECTOR_WITH_TCP).
Please read section 3.7.4 on ``Using TCP to
Send Collector Updates'' on page
for more details and a discussion of when you would need this
functionality.
If you do not enable a socket cache, TCP updates will be refused by
the collector.
The default value for this setting is 0, with no cache enabled.
If you lower this number, you must run condor_ restart and not just
condor_ reconfig for the change to take effect.

KEEP_POOL_HISTORY

This boolean macro is used to decide if the collector will write
out statistical information about the pool to history files. The default
is False. The location, size and frequency of history logging is controlled
by the other macros.

POOL_HISTORY_DIR

This macro sets the name of the directory where the history
files reside (if history logging is enabled).
The default is the SPOOL directory.

POOL_HISTORY_MAX_STORAGE

This macro sets the maximum combined size of the history files.
When the size of the history files is close to this limit, the oldest
information will be discarded.
Thus, the larger this parameter's value is, the larger the time
range for which history will be available. The default value is
10000000 (10 Mbytes).

POOL_HISTORY_SAMPLING_INTERVAL

This macro sets the interval, in seconds, between samples for
history logging purposes.
When a sample is taken, the collector goes through the information
it holds, and summarizes it.
The information is written to the history file once for each 4
samples.
The default (and recommended) value is 60 seconds. Setting this
macro's value too low will increase the load on the collector,
while setting it to high will produce less precise statistical
information.

COLLECTOR_DAEMON_STATS

This macro controls whether or not the Collector keeps update
statistics on incoming updates. The default value is True. If
this option is enabled, the collector will insert several attributes
into ClassAds that it stores and sends. ClassAds without the
``UpdateSequenceNumber'' and ``DaemonStartTime'' attributes will not
be counted, and will not have attributes inserted (all modern Condor
daemons which publish ClassAds publish these attributes).

The attributes inserted are ``UpdatesTotal'', ``UpdatesSequenced'',
and ``UpdatesLost''. ``UpdatesTotal'' is the total number of
updates (of this ad type) the Collector has received from this host.
``UpdatesSequenced'' is the number of updates that the Collector
could have as lost. In particular, for the first update from a
daemon it is impossible to tell if any previous ones have been lost
or not. ``UpdatesLost'' is the number of updates that the Collector
has detected as being lost.

COLLECTOR_DAEMON_HISTORY_SIZE

This macro controls the
size of the published update history that the Collector inserts into
the ClassAds it stores and sends. The default value is 128, which
means that history is stored and published for the latest 128
updates. This macro is ignored if $(COLLECTOR_DAEMON_STATS)
is not enabled.

If this has a non-zero value, the Collector will insert
``UpdatesHistory'' into the ClassAd (similar to ``UpdatesTotal''
above). ``UpdatesHistory'' is a hexadecimal string which represents
a bitmap of the last COLLECTOR_DAEMON_HISTORY_SIZE
updates. The most significant bit (MSB) of the bitmap represents the
most recent update, and the least significant bit (LSB) represents
the least recent. A value of zero means that the update was not
lost, and a value of 1 indicates that the update was detected as
lost.

For example, if the last update was not lost, the previous lost, and
the previous two not, the bitmap would be 0100, and the matching hex
digit would be ``4''. Note that the MSB can never be marked as lost
because its loss can only be detected by a non-lost update (a
``gap'' is found in the sequence numbers). Thus, UpdatesHistory =
"0x40" would be the history for the last 8 updates. If the next
updates are all successful, the values published, after each update,
would be: 0x20, 0x10, 0x08, 0x04, 0x02, 0x01, 0x00.

COLLECTOR_CLASS_HISTORY_SIZE

This macro controls the
size of the published update history that the Collector inserts into
the Collector ClassAds it produces. The default value is zero.

If this has a non-zero value, the Collector will insert
``UpdatesClassHistory'' into the Collector ClassAd (similar to
``UpdatesHistory'' above). These are added ``per class'' of
ClassAd, however. The classes refer to the ``type'' of ClassAds
(i.e. ``Start''). Additionally, there is a ``Total'' class created
which represents the history of all ClassAds that this Collector
receives.

Note that the collector always publishes Lost, Total and Sequenced
counts for all ClassAd ``classes''. This is similar to the
statistics gathered if $(COLLECTOR_DAEMON_STATS) is enabled.

COLLECTOR_QUERY_WORKERS

This macro sets the maximum
number of ``worker'' processes that the Collector can have. When
receiving a query request, the UNIX Collector will ``fork'' a new
process to handle the query, freeing the main process to handle
other requests. When the number of outstanding ``worker'' processes
reaches this maximum, the request is handled by the main process.
This macro is ignored on Windows, and its default value is zero.
The default configuration, however, has this set to 16.

COLLECTOR_DEBUG

This
macro (and other macros related to debug logging in the collector)
is described in section 3.3.4 as
<SUBSYS>_DEBUG.

3.3.18 condor_ negotiator
Configuration File Entries

These macros affect the condor_ negotiator.

NEGOTIATOR_INTERVAL

Sets how often the negotiator starts a negotiation cycle. It is defined
in seconds and defaults to 300 (5 minutes).

NEGOTIATOR_CYCLE_DELAY

An integer value that represents the minimum number of seconds
that must pass before a new negotiation cycle may start.
The default value is 20.
NEGOTIATOR_CYCLE_DELAY is intended only for use by
Condor experts.

NEGOTIATOR_TIMEOUT

Sets the timeout that the negotiator uses on its network connections
to the condor_ schedd and condor_ startds. It is defined in seconds and defaults to 30.

PRIORITY_HALFLIFE

This
macro defines the half-life of the user priorities. See
section 2.7.2
on User Priorities for details. It is defined in seconds and defaults
to 86400 (1 day).

DEFAULT_PRIO_FACTOR

This macro sets the priority factor for local users. See
section 2.7.2
on User Priorities for details. Defaults to 1.

NICE_USER_PRIO_FACTOR

This macro sets the priority factor for nice users. See
section 2.7.2
on User Priorities for details. Defaults to 10000000.

REMOTE_PRIO_FACTOR

This macro defines the priority factor for remote users (users who
who do not belong to the accountant's local domain - see
below). See section 2.7.2
on User Priorities for details. Defaults to 10000.

ACCOUNTANT_LOCAL_DOMAIN

This macro is used to decide if a user is local or remote. A user
is considered to be in the local domain if the UID_DOMAIN matches
the value of this macro. Usually, this macro is set
to the local UID_DOMAIN. If it is not defined, all users are considered
local.

MAX_ACCOUNTANT_DATABASE_SIZE

This macro defines the maximum size (in bytes) that the accountant
database log file can reach before it is truncated (which re-writes
the file in a more compact format).
If, after truncating, the file is larger than one half the maximum
size specified with this macro, the maximum size will be
automatically expanded.
The default is 1 megabyte (1000000).

NEGOTIATOR_DISCOUNT_SUSPENDED_RESOURCES

This macro tells the negotiator to not count resources that are suspended
when calculating the number of resources a user is using.
Defaults to false, that is, a user is still charged for a resource even
when that resource has suspended the job.

NEGOTIATOR_SOCKET_CACHE_SIZE

This macro defines the
maximum number of sockets that the negotiator keeps in its
open socket cache. Caching open sockets makes the negotiation
protocol more efficient by eliminating the need for socket
connection establishment for each negotiation cycle. The default is
currently 16. To be effective, this parameter should be set to a
value greater than the number of condor_ schedds submitting jobs to the
negotiator at any time. If you lower this number, you must run
condor_ restart and not just condor_ reconfig for the change to
take effect.

NEGOTIATOR_PRE_JOB_RANK

Resources that match a request
are first sorted by this expression, then by the user-supplied rank
in the job ClassAd, then by NEGOTIATOR_POST_JOB_RANK, then by
PREEMPTION_RANK (if the match would cause preemption). The purpose
of the pre job rank is to allow the pool administrator to override any
other rankings, in order to optimize overall throughput. For example,
it is generally used to prevent preemption when possible, even if the job
rank prefers a machine that is busy.
The default value is undefined, which causes this rank
to have no effect on the ranking of matches.

NEGOTIATOR_POST_JOB_RANK

Resources that match a request
are first sorted by the NEGOTIATOR_PRE_JOB_RANK
expression, then by the user-supplied rank in the job ClassAd, then
by NEGOTIATOR_POST_JOB_RANK, then by
PREEMPTION_RANK (if the match would cause preemption). The
purpose of the post job rank is to allow the pool administrator to
choose between machines that the job ranks equally. For example,
you might want breadth-first instead of depth-first filling of a
cluster of multi-processor machines.
The default value is undefined, which causes this rank
to have no effect on the ranking of matches.

PREEMPTION_REQUIREMENTS

When considering user priorities, the negotiator will not preempt
a job running on a given machine unless the
PREEMPTION_REQUIREMENTS expression evaluates to True and the
owner of the idle job has a better priority than the owner of the
running job.
The PREEMPTION_REQUIREMENTS expression is evaluated within the
context of the candidate machine ClassAd and the candidate idle job
ClassAd; thus the MY scope prefix refers to the machine ClassAd,
and the TARGET scope prefix refers to the ClassAd of the idle
(candidate) job.
If not explicitly set in the Condor configuration file, the default value
for this expression is True.
Note that this setting does not
influence other potential causes of preemption, such as startd
RANK, or PREEMPT expressions. See
section 3.5.10 for a general discussion of
limiting preemption.

PREEMPTION_RANK

Resources that match a request are first sorted by the
NEGOTIATOR_POST_JOB_RANK expression, then by the
user-supplied rank in the job ClassAd, then by
NEGOTIATOR_POST_JOB_RANK, then by
PREEMPTION_RANK (if the match would cause preemption).
This expression is used to rank machines that the job and the other
negotiation expressions rank the same. For example, if the job has
no preference, it is usually preferable to preempt a job with a
small ImageSize instead of a job with a large
ImageSize. The default is to rank all preemptable matches
the same. However, the negotiator will always prefer to match the
job with an idle machine over a preemptable machine, if none of the
other ranks express a preference between them.

NEGOTIATOR_DEBUG

This macro
(and other settings related to debug logging in the negotiator) is
described in section 3.3.4 as <SUBSYS>_DEBUG.

NEGOTIATOR_MAX_TIME_PER_SUBMITTER

This macro limits the amount of time the negotiator will
spend with a submitter. It defaults to one year.

The following configuration macros affect negotiation for
group users.

GROUP_NAMES

A comma-separated list of the recognized group names, case insensitive.
If undefined (the default), group support is disabled.
Group names must not conflict with any user names.
That is, if there is a physics group, there may not be
a physics user.
Any group that is defined here must also have a quota,
or the group will be ignored. Example:

GROUP_NAMES = group_physics, group_chemistry

GROUP_QUOTA_<groupname>

A positive integer to represent a static quota specifing
the exact number of machines owned by this group.
Note that Condor does not verify or check consistency of quota values.
Example:

GROUP_QUOTA_group_physics = 20
GROUP_QUOTA_group_chemistry = 10

GROUP_PRIO_FACTOR_<groupname>

A floating point value greater than or equal to 1.0 to specify the
default user priority factor for <groupname>.
The group name must also be specified in the GROUP_NAMES list.
GROUP_PRIO_FACTOR_<groupname> is evaluated when
the negotiator first negotiates for the user as a member of the group.
All members of the group inherit the default priority factor
when no other value is present.
For example, the following setting
specifies that all members of the group named group_physics
inherit a default user priority factor of 2.0:

GROUP_PRIO_FACTOR_group_physics = 2.0

GROUP_AUTOREGROUP

A boolean value (defaults to False) that when True,
causes users who submitted to a specific group to
also negotiate a second time with the none group,
to be considered with the independent job submitters.
This allows group submitted jobs to be matched with idle machines
even if the group is over its quota.

GROUP_AUTOREGROUP_<groupname>

This is the same as GROUP_AUTOREGROUP, but it is settable
on a per-group basis. If no value is specified for a given group,
the default behavior is determined by GROUP_AUTOREGROUP,
which in turn defaults to False.

NEGOTIATOR_CONSIDER_PREEMPTION

For expert users only. A boolean value (defaults to True),
that when False,
can cause the negotiator to run
faster and also have better spinning pie accuracy.
Only set this to False if PREEMPTION_REQUIREMENTS
is False,
and if all condor_ startd rank expressions are False.

3.3.19 condor_ credd
Configuration File Macros

CREDD_HOST

The host name of the machine running the condor_ credd daemon.

CREDD_CACHE_LOCALLY

A boolean value that defaults to False.
When True, the first successful password fetch operation to the
condor_ credd daemon causes the password to be stashed in a local,
secure password store.
Subsequent uses of that password do not require
communication with the condor_ credd daemon.

3.3.20 condor_ gridmanager
Configuration File Entries

These macros affect the condor_ gridmanager.

GRIDMANAGER_LOG

Logs for the condor_ gridmanager
will be written as the user who submitted the individual jobs.
As a result GRIDMANAGER_LOG should defined to incorporate
$(USERNAME) to specify a different file for each user
in a directory that users will be able to write into.
An example definition:

GRIDMANAGER_LOG = /tmp/GridmanagerLog.$(USERNAME)

GRIDMANAGER_CHECKPROXY_INTERVAL

The number of seconds
between checks for an updated X509 proxy credential. The default
is 10 minutes (600 seconds).

GRIDMANAGER_MINIMUM_PROXY_TIME

The minimum number of
seconds before expiration of the X509 proxy credential for the
gridmanager to continue operation. If seconds until expiration is
less than this number, the gridmanager will shutdown and wait for
a refreshed proxy credential. The default is 3 minutes (180 seconds).

HOLD_JOB_IF_CREDENTIAL_EXPIRES

True or False.
Defaults to True.
If True, and for grid universe jobs only,
Condor-G will place a job on hold
GRIDMANAGER_MINIMUM_PROXY_TIME seconds
before the proxy expires.
If False,
the job will stay in the last known state,
and Condor-G will periodically check to see if the job's proxy has been
refreshed, at which point management of the job will resume.

GRIDMANAGER_CONTACT_SCHEDD_DELAY

The minimum number of
seconds between connections to the condor_ schedd. The default is 5 seconds.

GRIDMANAGER_JOB_PROBE_INTERVAL

The number of seconds between
active probes of the status of a submitted job. The default is 5
minutes (300 seconds).

CONDOR_JOB_POLL_INTERVAL

After a condor grid type job is submitted, how often (in seconds) the condor_ gridmanager
should probe the remote condor_ schedd to check the jobs status.
This defaults to 300 seconds (5 minutes).
Setting this to a lower number will decrease latency (Condor will discover
that a job has finished more quickly), but will increase network traffic.

GRIDMANAGER_RESOURCE_PROBE_INTERVAL

When a resource appears to be down, how often (in seconds) the
condor_ gridmanager
should ping it to test if it is up again.

GRIDMANAGER_RESOURCE_PROBE_DELAY

The number of seconds
between pings of a remote resource that is currently down. The default
is 5 minutes (300 seconds).

GRIDMANAGER_MAX_SUBMITTED_JOBS_PER_RESOURCE

Limits the number of jobs
that a condor_ gridmanager daemon will submit to a resource.
It is useful for controlling the number of jobmanager
processes running on the front-end node of a cluster.
This number may be exceeded if it is reduced through the use
of condor_ reconfig while the condor_ gridmanager is running
or if the condor_ gridmanager receives new
jobs from the condor_ schedd that were already submitted
(that is, their GridJobId is not undefined).
In these cases, submitted jobs will not be killed,
but no new jobs can be submitted until the number of submitted
jobs falls below the current limit.
Defaults to 100.

GRIDMANAGER_MAX_PENDING_SUBMITS_PER_RESOURCE

The maximum
number of jobs
that can be in the process of being submitted at any time (that is,
how many globus_gram_client_job_request calls are pending).
It is useful for controlling the number of new
connections/processes created at a given time.
The default value is 5.
This variable allows
you to set different limits for each resource.
After the first integer in the value
comes a list of resourcename/number pairs,
where each number is the limit for that resource.
If a resource is not in the list,
Condor uses the first integer.
An example usage:

GRIDMANAGER_MAX_PENDING_SUBMITS_PER_RESOURCE=20,nostos,5,beak,50

GRIDMANAGER_MAX_PENDING_SUBMITS

Configuration variable
still recognized, but the name has changed to be
GRIDMANAGER_MAX_PENDING_SUBMITS_PER_RESOURCE.

GRIDMANAGER_MAX_JOBMANAGERS_PER_RESOURCE

For grid jobs of type gt2, limits the number of globus-job-manager
processes that the condor_ gridmanager lets run at a time on
the remote headnode. Allowing too many globus-job-managers to run
causes severe load on the headnode, possibly making it
non-functional.
This number may be exceeded if it is reduced through the use
of condor_ reconfig while the condor_ gridmanager is running
or if some globus-job-managers take a few extra seconds to exit.
The value 0 means there is no limit. The default value is 10.

GAHP

The full path to the binary of the GAHP server.

GAHP_ARGS

Arguments to be passed to the GAHP server.

GRIDMANAGER_GAHP_CALL_TIMEOUT

The number of seconds after
which a pending GAHP command should time out. The default is 5 minutes
(300 seconds).

GRIDMANAGER_MAX_PENDING_REQUESTS

The maximum number of GAHP
commands that can be pending at any time. The default is 50.

GRIDMANAGER_CONNECT_FAILURE_RETRY_COUNT

The number of times
to retry a command that failed due to a timeout or a failed connection.
The default is 3.

GRIDMANAGER_SYNC_JOB_IO_INTERVAL

The number of seconds between
periodic syncs of streamed output to disk. The default is 5 minutes
(300 seconds).

GRIDMANAGER_GLOBUS_COMMIT_TIMEOUT

The duration, in seconds, of the
two phase commit timeout to Globus. This maps directly to the two_phase setting in the Globus RSL.

GLOBUS_GATEKEEPER_TIMEOUT

The number of seconds after
which if a grid
universe job fails to ping the gatekeeper,
the job will be put on hold.
Defaults to 5 days (in seconds).

GT3_GAHP_LOG

The complete path name to
a file where the GT3 GAHP may write information to be used in debugging
related to GT3 job submission.

3.3.21 grid_monitor
Configuration File Entries

These macros affect the grid_monitor.

ENABLE_GRID_MONITOR

When set to True enables the grid_monitor tool. The
grid_monitor tool is used to reduce load on Globus gatekeepers.
This parameter only affects
grid jobs of type gt2.
GRID_MONITOR must also be correctly configured.
Defaults to False.
See section 5.3.2 on
page
for more information.

GRID_MONITOR

The complete pathname of the grid_monitor tool used to reduce load on
Globus gatekeepers. This parameter only affects
grid jobs of type gt2.
This parameter is not referenced unless
ENABLE_GRID_MONITOR is set to True.
See section 5.3.2 on
page
for more information.

GRID_MONITOR_HEARTBEAT_TIMEOUT

If this many seconds pass without hearing from a grid_monitor, it is
assumed to be dead. Defaults to 300 (5 minutes). Increasing this number
will improve the ability of the grid_monitor to survive in the face of
transient problems but will also increase the time before Condor notices a
problem.

GRID_MONITOR_RETRY_DURATION

If something goes wrong with the grid_monitor at a particular site
(like GRID_MONITOR_HEARTBEAT_TIMEOUT expiring), Condor-G will
attempt to restart the grid_monitor for this many seconds. Defaults
to 900 (15 minutes). If this duration passes without success the
grid_monitor will be disabled for the site in question until 60
minutes have passed.

3.3.22 Configuration File
Entries for DAGMan

These macros affect the operation of DAGMan and DAGMan
jobs within Condor.

DAGMAN_MAX_SUBMITS_PER_INTERVAL

An integer that controls how many individual jobs
condor_ dagman will submit in a row
before servicing other requests (such as a condor_ rm).
The legal range of values is 1 to 1000.
If defined with a value less than 1, the value 1 will be used.
If defined with a value greater than 1000, the value 1000 will be used.
If not defined, it defaults to 5.

DAGMAN_MAX_SUBMIT_ATTEMPTS

An integer that controls how
many times in a row condor_ dagman will attempt to execute
condor_ submit for a given job before giving up.
Note that consecutive attempts use an exponential backoff,
starting with 1 second.
The legal range of values is 1 to 16.
If defined with a value less than 1, the value 1 will be used.
If defined with a value greater than 16, the value 16 will be used.
Note that a value of 16 would result in condor_ dagman trying for
approximately 36 hours before giving up.
If not defined,
it defaults to 6 (approximately two minutes before giving up).

DAGMAN_SUBMIT_DELAY

An integer that controls the number of seconds
that condor_ dagman will sleep before submitting consecutive jobs.
It can be increased to help reduce the load on the condor_ schedd daemon.
The legal range of values is 0 to 60.
If defined with a value less than 0, the value 0 will be used.
If defined with a value greater than 60, the value 60 will be used.
The default value is 0.

DAGMAN_STARTUP_CYCLE_DETECT

A boolean value that when True
causes condor_ dagman to check for cycles in the DAG before
submitting DAG node jobs,
in addition to its run time cycle detection.
If not defined, it defaults to False.

DAGMAN_RETRY_SUBMIT_FIRST

A boolean value that controls whether a failed submit is retried first
(before any other submits) or last (after all other ready jobs are
submitted). If this value is set to True, when a job submit
fails, the job is placed at the head of the queue of ready jobs, so
that it will be submitted again before any other jobs are submitted
(this has been the behavior of condor_ dagman up to this point).
If this value is set to False, when a job submit fails, the job
is placed at the tail of the queue of ready jobs.
If not defined, it defaults to True.

DAGMAN_RETRY_NODE_FIRST

A boolean value that controls whether a failed node (with retries)
is retried first (before any other ready nodes) or last (after all
other ready nodes). If this value is set to True, when a
node with retries fails (after the submit succeeded), the node is
placed at the head of the queue of ready nodes, so that it will be
tried again before any other jobs are submitted. If this value is
set to False, when a node with retries fails, the node
is placed at the tail of the queue of ready nodes (this has been the
behavior of condor_ dagman up to this point). If not defined, it
defaults to False.

DAGMAN_MAX_JOBS_IDLE

An integer value that controls the maximum number of idle node jobs
allowed within the DAG before condor_ dagman temporarily stops
submitting jobs. Once idle jobs start to run, condor_ dagman will
resume submitting jobs. If both the command-line flag and the
configuration parameter are specified, the command-line flag overrides
the configuration parameter. The default is that there is no limit
on the maximum number of idle jobs.

DAGMAN_MAX_JOBS_SUBMITTED

An integer value that controls the maximum number of node jobs within the
DAG that will be submitted to Condor at one time. Note that this
parameter is the same as the -maxjobs command-line flag
to condor_submit_dag. If both the command-line flag and the
configuration parameter are specified, the command-line flag overrides
the configuration parameter. The default is that there is no limit
on the maximum number of jobs run at one time.

DAGMAN_MUNGE_NODE_NAMES

A boolean value that controls whether condor_ dagman automatically
renames nodes when running multiple DAGs (the renaming is done to
avoid possible name conflicts). If this value is set to True,
all node names have the "DAG number" prepended to them. For example,
the first DAG specified on the condor_ submit_dag command line is
considered DAG number 0, the second is DAG number 1, etc. So if
DAG number 2 has a node B, that node will internally be renamed
to "2.B".
If not defined, DAGMAN_MUNGE_NODE_NAMES defaults to True.

DAGMAN_IGNORE_DUPLICATE_JOB_EXECUTION

This macro is no longer used. The improved functionality
of the DAGMAN_ALLOW_EVENTS macro eliminates the
need for this variable.

A boolean value that controls
whether condor_ dagman aborts or continues with a DAG
in the rare case that Condor erroneously executes
the job within a DAG node more than once.
A bug in Condor very occasionally causes a job to run twice.
Running a job twice is contrary to the semantics of a DAG.
The configuration macro DAGMAN_IGNORE_DUPLICATE_JOB_EXECUTION
determines whether condor_ dagman considers this a fatal error or not.
The default value is False; condor_ dagman considers
running the job more than once a fatal error,
logs this fact,
and aborts the DAG.
When set to True, condor_ dagman still
logs this fact,
but continues with the DAG.

This configuration macro is to remain at its default value
except in the case
where a site encounters the Condor bug in which DAG job nodes
are executed twice,
and where it is certain
that having a DAG job node run twice will not corrupt the DAG.
The logged messages within *.dagman.out files
in the case of that a node job runs twice
contain the string
"EVENT ERROR."

DAGMAN_ALLOW_EVENTS

An integer that controls which "bad" events are considered
fatal errors by condor_ dagman. This macro replaces and expands
upon the functionality of the
DAGMAN_IGNORE_DUPLICATE_JOB_EXECUTION macro.
If DAGMAN_ALLOW_EVENTS is set, it overrides the
setting of DAGMAN_IGNORE_DUPLICATE_JOB_EXECUTION.

The DAGMAN_ALLOW_EVENTS value is a bitwise-OR of the
following values:

For example, a value of 6 instructs condor_ dagman to allow both
the terminated/aborted event combination and the "job re-run
after terminated event" bug. A value of 0 means that any "bad"
event will be considered a fatal error.

A value of 5 (1 + 4) will never abort the DAG because of a "bad"
event - but you should almost never use this setting, because
the "job re-run after terminated event" bug breaks the semantics of
the DAG.

The executable that condor_ dagman will use to submit Condor jobs.
If not defined, condor_ dagman looks for condor_ submit in the PATH.

DAGMAN_STORK_SUBMIT_EXE

The executable that condor_ dagman will use to submit Stork jobs.
If not defined, condor_ dagman looks for stork_ submit in the PATH.

DAGMAN_CONDOR_RM_EXE

The executable that condor_ dagman will use to remove Condor jobs.
If not defined, condor_ dagman looks for condor_ rm in the PATH.

DAGMAN_STORK_RM_EXE

The executable that condor_ dagman will use to remove Stork jobs.
If not defined, condor_ dagman looks for stork_ rm in the PATH.

DAGMAN_PROHIBIT_MULTI_JOBS

A boolean value that controls whether condor_ dagman prohibits
node job submit files that queue multiple job procs (other than
parallel universe). If a DAG references such a submit file, the
DAG will abort during the initialization process. If not defined,
DAGMAN_PROHIBIT_MULTI_JOBS defaults to False.

DAGMAN_LOG_ON_NFS_IS_ERROR

A boolean value that controls whether condor_ dagman prohibits
node job submit files with user log files on NFS. If a DAG
references such a submit file and DAGMAN_LOG_ON_NFS_IS_ERROR
is True, the DAG will abort during the initialization process.
If DAGMAN_LOG_ON_NFS_IS_ERROR is False, a warning
will be issued but the DAG will still be submitted. It is strongly
recommended that DAGMAN_LOG_ON_NFS_IS_ERROR
remain set to the default value, because running a DAG with node job
log files on NFS will often cause errors.
If not defined, DAGMAN_LOG_ON_NFS_IS_ERROR defaults to
True.

DAGMAN_ABORT_DUPLICATES

A boolean value that controls whether to attempt to abort duplicate
instances of condor_ dagman running the same DAG on the same
machine. When condor_ dagman starts up, if no DAG lock file exists,
condor_ dagman creates the lock file and writes its PID into it. If
the lock file does exist, and DAGMAN_ABORT_DUPLICATES is
set to True, condor_ dagman checks whether a process with the
given PID exists, and if so, it assumes that there is already another
instance of condor_ dagman running on the same DAG. Note that this
test is not foolproof: it is possible that, if condor_ dagman crashes,
the same PID gets reused by another process before condor_ dagman
gets rerun on that DAG. This should be quite rare, however.
If not defined, DAGMAN_ABORT_DUPLICATES defaults to
False.

3.3.23 Configuration File Entries
Relating to Security

These macros affect the secure operation of Condor.
Many of these macros are described in
section 3.6 on Security.

SEC_*_AUTHENTICATION

SEC_*_ENCRYPTION

SEC_*_INTEGRITY

SEC_*_NEGOTIATION

SEC_*_AUTHENTICATION_METHODS

SEC_*_CRYPTO_METHODS

GSI_DAEMON_NAME

A comma separated list of the subject
name(s) of the certificate(s) that the daemons use.

GSI_DAEMON_DIRECTORY

A directory name used in the
construction of complete paths for the configuration variables
GSI_DAEMON_CERT,
GSI_DAEMON_KEY, and
GSI_DAEMON_TRUSTED_CA_DIR,
for any of these configuration variables are not explicitly set.

GSI_DAEMON_CERT

A complete path and file name to the
X.509 certificate to be used in GSI authentication.
If this configuration variable is not defined, and
GSI_DAEMON_DIRECTORY is defined, then Condor uses
GSI_DAEMON_DIRECTORY to construct the path and file name as

GSI_DAEMON_CERT = $(GSI_DAEMON_DIRECTORY)/hostcert.pem

GSI_DAEMON_KEY

A complete path and file name to the
X.509 private key to be used in GSI authentication.
If this configuration variable is not defined, and
GSI_DAEMON_DIRECTORY is defined, then Condor uses
GSI_DAEMON_DIRECTORY to construct the path and file name as

GSI_DAEMON_KEY = $(GSI_DAEMON_DIRECTORY)/hostkey.pem

GSI_DAEMON_TRUSTED_CA_DIR

The directory that contains the
list of trusted certification authorities to be used in GSI authentication.
The files in this directory are the public keys and signing policies
of the trusted certification authorities.
If this configuration variable is not defined, and
GSI_DAEMON_DIRECTORY is defined, then Condor uses
GSI_DAEMON_DIRECTORY to construct the directory path as

GSI_DAEMON_TRUSTED_CA_DIR = $(GSI_DAEMON_DIRECTORY)/certificates

GSI_DAEMON_PROXY

A complete path and file name to the
X.509 proxy to be used in GSI authentication.
When this configuration variable is defined, use of this proxy
takes precedence over use of a certificate and key.

GRIDMAP

The complete path and file name of the Globus Gridmap file.
The Gridmap file is used to map
X.509 distinguished names to Condor user ids.

SEC_DEFAULT_SESSION_DURATION

The amount of time in seconds before
a communication session expires.
Defaults to 8640000 seconds (100 days) to avoid a bug in session
renegotiation for Condor Version 6.6.0.
A session is a record of necessary information to do communication
between a client and daemon, and is protected by a shared secret key.
The session expires to reduce the window of opportunity where
the key may be compromised by attack.

FS_REMOTE_DIR

The location of a file visible to both server and client in
Remote File System authentication.
The default when not defined is the directory
/shared/scratch/tmp.

ENCRYPT_EXECUTE_DIRECTORY

The execute directory for jobs on Windows platforms may be
encrypted by setting this configuration variable to True.
Defaults to False.
The method of encryption uses the EFS (Encrypted File System)
feature of Windows NTFS v5.

SEC_TCP_SESSION_TIMEOUT

The length of time in seconds until the timeout
when establishing a UDP security session via TCP.
The default value is 20 seconds.
Scalability issues with a large pool would be the only basis
for a change from the default value.

SEC_PASSWORD_FILE

For Unix machines, the path and file name
of the file containing the pool password for password authentication.

3.3.24 Configuration File Entries
Relating to High Availability

These macros affect the high availability operation of Condor.

MASTER_HA_LIST

Similar to
DAEMON_LIST, this macro defines a list of daemons that
the condor_ master starts and keeps its watchful eyes on.
However, the MASTER_HA_LIST daemons are run in a
High Availability mode.
The list is a comma or space separated list of subsystem names
(as listed in section 3.3.1).
For example,

MASTER_HA_LIST = SCHEDD

The High Availability feature allows for several condor_ master
daemons (most likely on separate machines) to work together to
insure that a particular service stays available. These
condor_ master daemons ensure that one and only one of them will
have the listed daemons running.

To use this feature, the lock URL must be set with
HA_LOCK_URL.

Currently, only file URLs are supported
(those with file:... ).
The default value for MASTER_HA_LIST is
the empty string, which disables the feature.

HA_LOCK_URL

This macro
specifies the URL that the condor_ master processes use to
syncronize for the High Availability service.
Currently, only file URLs are supported; for example,
file:/share/spool. Note that this URL must be identical
for all condor_ master processes sharing this resource. For
condor_ schedd sharing, we recommend setting up SPOOL
on an NFS share and having all High Availabilitycondor_ schedd processes sharing it,
and setting the HA_LOCK_URL to point at this directory
as well. For example:

This macro controls the
High Availability lock URL for a specific subsystem
as specified in the configuration variable name,
and it overrides the system-wide lock URL specified by
HA_LOCK_URL. If not defined for each subsystem,
HA_<SUBSYS>_LOCK_URL is ignored, and the value of
HA_LOCK_URL is used.

HA_LOCK_HOLD_TIME

This macro
specifies the number of seconds that the condor_ master will hold the
lock for each High Availability daemon.
Upon gaining the shared lock,
the condor_ master will hold the lock for this number of seconds.
Additionally, the condor_ master will periodically renew
each lock as long as the condor_ master and the daemon are running.
When the daemon dies, or the condor_ master exists, the
condor_ master will immediately release the lock(s) it holds.

HA_LOCK_HOLD_TIME defaults to 3600 seconds (one hour).

HA_<SUBSYS>_LOCK_HOLD_TIME

This macro controls the High Availability lock
hold time for a specific subsystem
as specified in the configuration variable name,
and it overrides the system wide poll period specified by
HA_LOCK_HOLD_TIME.
If not defined for each subsystem,
HA_<SUBSYS>_LOCK_HOLD_TIME is ignored,
and the value of HA_LOCK_HOLD_TIME is used.

HA_POLL_PERIOD

This macro specifies how often the condor_ master polls the
High Availability locks to see if any locks are either stale
(meaning not updated for HA_LOCK_HOLD_TIME seconds),
or have been released by the owning condor_ master.
Additionally, the condor_ master renews any locks that it
holds during these polls.

HA_POLL_PERIOD defaults to 300 seconds (five minutes).

HA_<SUBSYS>_POLL_PERIOD

This macro controls the High Availability poll period
for a specific subsystem
as specified in the configuration variable name,
and it overrides the system wide poll period specified by
HA_POLL_PERIOD.
If not defined for each subsystem,
HA_<SUBSYS>_POLL_PERIOD is ignored,
and the value of HA_POLL_PERIOD is used.

MASTER_<SUBSYS>_CONTROLLER

Used only in HA configurations
involving the condor_ had.

The condor_ master has the concept of a controlling and controlled
daemon, typically
with the condor_ had daemon serving as the controlling process.
In this case, all condor_ on and condor_ off commands directed
at controlled daemons are given to the controlling daemon, which
then handles the command, and, when required, sends appropriate
commands to the condor_ master to do the actual work. This allows
the controlling daemon to know the state of the controlled daemon.

As of 6.7.14, this configuration variable must be specified for all
configurations using condor_ had.
To configure the condor_ negotiator controlled by condor_ had:

MASTER_NEGOTIATOR_CONTROLLER = HAD

The macro is named by substituting <SUBSYS>
with the appropriate subsystem string as defined in
section 3.3.1.

HAD_LIST

A comma-separated list of all condor_ had daemons
in the form IP:port or hostname:port.
Each central manager machine that runs the condor_ had daemon
should appear in this list.
If HAD_USE_PRIMARY is set to True,
then the first machine in this list is the primary central
manager, and all others in the list are backups.

All central manager machines must be configured with
an identical HAD_LIST.
The machine addresses are identical to the addresses defined
in COLLECTOR_HOST.

HAD_USE_PRIMARY

Boolean value to determine if the first machine in the
HAD_LIST configuration variable is
a primary central manager.
Defaults to False.

HAD_CONNECTION_TIMEOUT

The time (in seconds) that the condor_ had daemon waits before giving
up on the establishment of a TCP connection.
The failure of the communication connection
is the detection mechanism for the failure of a central
manager machine.
For a LAN, a recommended value is 2 seconds.
The use of authentication (by Condor) increases the connection
time.
The default value is 5 seconds.
If this value is set too low,
condor_ had daemons will incorrectly assume
the failure of other machines.

HAD_ARGS

Command line arguments passed by the condor_ master daemon
as it invokes the condor_ had daemon.
To make high availability work, the condor_ had daemon
requires the port number it is to use.
This argument is of the form

-p $(HAD_PORT_NUMBER)

where HAD_PORT_NUMBER is a helper configuration variable
defined with the desired port number.
Note that this port number must be the same value here as
used in HAD_LIST.
There is no default value.

HAD

The path to the condor_ had executable. Normally it is defined
relative to $(SBIN).
This configuration variable has no default value.

MAX_HAD_LOG

Controls the maximum length in bytes to which the condor_ had
daemon log will be allowed to grow. It will grow to the specified length,
then be saved to a file with the suffix .old.
The .old file is overwritten each time the log is saved,
thus the maximum space devoted to logging is twice the maximum length
of this log file.
A value of 0 specifies that this file may grow without bounds.
The default is 1 Mbyte.

HAD_DEBUG

Logging level for the condor_ had daemon.
See <SUBSYS>_DEBUG for values.

HAD_LOG

Full path and file name of the log file.
There is no default value.

REPLICATION_LIST

A comma-separated list of all condor_ replication daemons
in the form IP:port or hostname:port.
Each central manager machine that runs the condor_ had daemon
should appear in this list.
All potential central manager machines must be configured with
an identical REPLICATION_LIST.

STATE_FILE

A full path and file name of the file protected by the replication
mechanism.
When not defined, the default path and file used is

$(SPOOL)/Accountantnew.log

REPLICATION_INTERVAL

Sets how often the condor_ replication daemon initiates its tasks of
replicating the $(STATE_FILE).
It is defined in seconds and defaults to 300 (5 minutes).
This is the same as the default NEGOTIATOR_INTERVAL.

MAX_TRANSFER_LIFETIME

A timeout period within which the process that
transfers the state file must complete its transfer.
The recommended value is
2 * average size of state file / network rate.
It is defined in seconds and defaults to 300 (5 minutes).

HAD_UPDATE_INTERVAL

Like UPDATE_INTERVAL,
determines how often the condor_ had is to send a ClassAd update
to the condor_ collector.
Updates are also sent at each and every change in state.
It is defined in seconds and defaults to 300 (5 minutes).

HAD_USE_REPLICATION

A boolean value that defaults to False.
When True, the use of condor_ replication daemons is enabled.

REPLICATION_ARGS

Command line arguments passed by the condor_ master daemon
as it invokes the condor_ replication daemon.
To make high availability work, the condor_ replication daemon
requires the port number it is to use.
This argument is of the form

-p $(REPLICATION_PORT_NUMBER)

where REPLICATION_PORT_NUMBER is a helper configuration
variable defined with the desired port number.
Note that this port number must be the same value as
used in REPLICATION_LIST.
There is no default value.

REPLICATION

The full path and file name of the condor_ replication executable.
It is normally defined relative to $(SBIN).
There is no default value.

MAX_REPLICATION_LOG

Controls the maximum length in bytes to which the condor_ replication
daemon log will be allowed to grow. It will grow to the specified length,
then be saved to a file with the suffix .old.
The .old file is overwritten each time the log is saved,
thus the maximum space devoted to logging is twice the maximum length
of this log file.
A value of 0 specifies that this file may grow without bounds.
The default is 1 Mbyte.

REPLICATION_DEBUG

Logging level for the condor_ replication daemon.
See <SUBSYS>_DEBUG for values.

REPLICATION_LOG

Full path and file name to the log file.
There is no default value.

3.3.25 Configuration File
Entries Relating to Quill

These macros affect the Quill database
management and interface to its representation of the job queue.

QUILL

The full path name to the
condor_ quill daemon.

QUILL_ARGS

Arguments
to be passed to the condor_ quill daemon upon its invocation.

QUILL_LOG

Path to the Quill daemon's log file.

QUILL_ENABLED

A boolean variable that defaults to False.
When True, Quill functionality is enabled.
When False, the Quill daemon writes a message to its log and exits.
The condor_ q and condor_ history tools then do not use Quill.

QUILL_NAME

A string that uniquely identifies an instance of the condor_ quill
daemon, as there be more than condor_ quill daemon per pool.
The string must not be the same as for any condor_ schedd daemon.
A convenient definition to choose is of the form

quill-for-schedd_name@machinename.fully.qualified.address

QUILL_DB_NAME

A string that identifies a database within a database server.

QUILL_DB_IP_ADDR

An IP address of the database server.

QUILL_POLLING_PERIOD

The frequency, in number of seconds, at which the Quill daemon
polls the file job_queue.log for updates.
New information in the log file is sent to the database.
The default value is 10.

QUILL_HISTORY_CLEANING_INTERVAL

The interval, in hours, between scans of the database to identify and
delete jobs that are beyond their QUILL_HISTORY_DURATION
time. The default value is 24.

QUILL_HISTORY_DURATION

The number of days after entry into the database that a job will
remain in the database.
After QUILL_HISTORY_DURATION days, the job is deleted.

QUILL_MANAGE_VACUUM

A boolean value that defaults to False.
When True, Quill takes on the maintenance task of vacuuming
the database. As of PostgreSQL version 8.1, the database
can perform this task automatically; therefore having Quill vacuum
is not necessary.
A value of True causes warnings to be written to the log file.

QUILL_IS_REMOTELY_QUERYABLE

A boolean value that defaults to True.
When False, the remote database tables may not be remotely
queryable.

When defined, it specifies the path and file name of a local file
containing the IP address and port number of the Quill daemon.
By using the file, tools executed on the local machine do not need
to query the central manager in order to find the Quill daemon.

3.3.26 MyProxy
Configuration File Macros

The full path name to the
myproxy-get-delegation executable, installed as part of the
MyProxy software. Often, it is necessary to wrap the actual
executable with a script that sets the environment, such as the
LD_LIBRARY_PATH, correctly. If this macro is defined,
Condor-G and condor_ credd will have the capability to autonomously
refresh proxy certificates. By default, this macro is undefined.

3.3.27 Configuration File Macros Affecting APIs

ENABLE_SOAP

A boolean value that defaults to False.
When True, Condor daemons will respond to HTTP PUT commands
as if they were SOAP calls. When False,
all HTTP PUT commands are denied.

ENABLE_WEB_SERVER

A boolean value that defaults to False.
When True, Condor daemons will respond to HTTP GET commands,
and send the static files sitting in the subdirectory defined
by the configuration variable WEB_ROOT_DIR.
In addition, web commands are considered a READ command,
so the client will be checked by host-based security.

WEB_ROOT_DIR

A complete path to the directory containing all the files served
by the web server.

ENABLE_SOAP_SSL

A boolean value that defaults to False.
When True, enables SOAP over SSL for the specified
<SUBSYS>.
Any specific <SUBSYS>_ENABLE_SOAP_SSL setting overrides
the value of ENABLE_SOAP_SSL.

ENABLE_SOAP_SSL

A boolean value that defaults to False.
When True, enables SOAP over SSL for all daemons.

<SUBSYS>_SOAP_SSL_PORT

A required port number on which SOAP over SSL messages are
accepted, when SOAP over SSL is enabled.
The <SUBSYS> must be specified, because multiple daemons
running on a single machine may not share a port.
There is no default value.

The macro is named by substituting <SUBSYS>
with the appropriate subsystem string as defined in
section 3.3.1.

SOAP_SSL_SERVER_KEYFILE

A required complete path and file name to specify the daemon's
identity, as used in authentication when SOAP over SSL is enabled.
The file is to be an OpenSSL PEM file containing a certificate
and private key.
There is no default value.

SOAP_SSL_SERVER_KEYFILE_PASSWORD

An optional complete path and file name to specify
a password for unlocking the daemon's private key.
There is no default value.

SOAP_SSL_CA_FILE

A required complete path and file name to specify
a file containing certificates of trusted Certificate Authorities (CAs).
Only clients who present a certificate signed by a trusted
CA will be authenticated.
There is no default value.

SOAP_SSL_CA_DIR

A required complete path to a directory
containing certificates of trusted Certificate Authorities (CAs).
Only clients who present a certificate signed by a trusted
CA will be authenticated.
There is no default value.

SOAP_SSL_DH_FILE

An optional complete path and file name to a DH file
containing keys for a DH key exchange.
There is no default value.

3.3.28 Stork Configuration
File Macros

STORK_MAX_NUM_JOBS

An integer limit on the number of concurrent data placement jobs
handled by Stork. The default value when not defined is 10.

STORK_MAX_RETRY

An integer limit on the
number of attempts for a single data placement job. For data transfers,
this includes transfer attempts on the primary protocol, all
alternate protocols, and all retries.
The default value when not defined is 10.

STORK_MAXDELAY_INMINUTES

An integer limit (in minutes) on the run time for a data placement job,
after which the job is considered failed.
The default value when not defined is 10,
and the minimum legal value is 1.

STORK_TMP_CRED_DIR

The full path to the temporary credential storage directory used by Stork.
The default value is /tmp when not defined.

STORK_MODULE_DIR

The full path to the directory containing Stork modules.
The default value when not defined is
as defined by $(LIBEXEC). It is a fatal error for
both STORK_MODULE_DIR and LIBEXEC to be undefined.

CRED_SUPER_USERS

Access to a stored credential is
restricted to the user who submitted the credential, and any user
names specified in this macro. The format is a space or comma
separated list of user names which are valid on the stork_ credd
host.
The default value of this macro is root on Unix systems, and
Administrator on Windows systems.

CRED_STORE_DIR

Directory for storing credentials. This
directory must exist prior to starting stork_ credd. It is highly
recommended to restrict access permissions to only the
directory owner.
The default value is
$(SPOOL_DIR)/cred.

CRED_INDEX_FILE

Index file path of saved credentials.
This file will be automatically created if it does not exist.
The default value is
$(CRED_STORE_DIR)/cred-index.

DEFAULT_CRED_EXPIRE_THRESHOLD

stork_ credd will attempt
to refresh credentials when their remaining lifespan is less than this
value.
Units = seconds. Default value = 3600 seconds (1 hour).