Next: 3.10 Pool Management
Up: 3. Administrators' Manual
Previous: 3.8 The Checkpoint Server
Contents
Index
Subsections
3.9 DaemonCore
This section is a brief description of DaemonCore. DaemonCore
is a library that is shared among most of the Condor daemons which
provides common functionality. Currently, the following daemons use
DaemonCore:
- condor_ master
- condor_ startd
- condor_ schedd
- condor_ collector
- condor_ negotiator
- condor_ kbdd
Most of DaemonCore's details are not interesting for administrators.
However, DaemonCore does provide a uniform interface for the daemons
to various Unix signals, and provides a common set of command-line
options that can be used to start up each daemon.
3.9.1 DaemonCore and Unix signals
One of the most visible features DaemonCore provides for
administrators is that all daemons which use it behave the same way on
certain Unix signals. The signals and the behavior DaemonCore
provides are listed below:
- SIGHUP
- Causes the daemon to reconfigure itself.
- SIGTERM
- Causes the daemon to gracefully shutdown.
- SIGQUIT
- Causes the daemon to quickly shutdown.
Exactly what ``gracefully'' and ``quickly'' means varies from daemon
to daemon. For daemons with little or no state (the kbdd, collector and
negotiator) there's no difference and both signals result in the
daemon shutting itself down basically right away. For the master,
graceful shutdown just means it asks all of its children to perform
their own graceful shutdown methods, while fast shutdown means it asks
its children to perform their own fast shutdown methods. In both
cases, the master only exits once all its children have exited. In
the startd, if the machine is not claimed and running a job, both
result in an immediate exit. However, if the startd is running a job,
graceful shutdown results in that job being checkpointed, while fast
shutdown does not. In the schedd, if there are no jobs currently
running (i.e. no condor_ shadow processes), both signals result in an
immediate exit. With jobs running, however, graceful shutdown means
that the schedd asks each shadow to gracefully vacate whatever job it
is serving, while fast shutdown results in a hard kill of every shadow
with no chance of checkpointing.
For all daemons, ``reconfigure'' just means that the daemon re-reads
its configuration file(s) and any settings that have changed take effect.
For example, changing the level of debugging output, the value of
timers that determine how often daemons perform certain actions, the
paths to the binaries you want the condor_ master to spawn, etc.
See section 3.3 on
page
, ``Configuring Condor'' for full
details on what settings are in the configuration files and what they do.
3.9.2 DaemonCore and
Command-line Arguments
The other visible feature that DaemonCore provides to administrators
is a common set of command-line arguments that all daemons understand.
These arguments and what they do are described below:
- -b
- Causes the daemon to start up in the background. When a
DaemonCore process starts up with this option, it disassociates itself
from the terminal and forks itself, so that it runs in the
background. This is the default behavior for Condor daemons.
- -f
- Causes the daemon to start up in the foreground. Instead of
forking, the daemon runs in the foreground.
NOTE: When the condor_ master starts up daemons, it does
so with the -f option, as it has already forked a process for the
new daemon. There will be a -f in the argument list for all
Condor daemons that the condor_ master spawns.
- -c filename
- Causes the daemon to use the specified filename
(use a full path name) as its global configuration file. This
overrides the CONDOR_CONFIG environment variable and the
regular locations that Condor checks for its configuration file: the
user condor's
home directory and file /etc/condor/condor_config.
- -p port
- Causes the daemon to bind to the specified port as its
command socket. The condor_ master daemon
uses this option to ensure that the
condor_ collector and condor_ negotiator start up using
well-known ports that the rest of Condor depends upon them using.
- -t
- Causes the daemon to print out its error message to
stderr instead of its specified log file. This option forces
the -f option.
- -v
- Causes the daemon to print out version information and
exit.
- -l directory
- Overrides the value of LOG as specified in
the configuration files. Primarily, this option is used with the
condor_ kbdd when it needs to run as the individual user logged
into the machine, instead of running as root. Regular users would
not normally have permission to write files into Condor's log
directory. Using this option, they can override the value of
LOG and have the condor_ kbdd write its log file into a
directory that the user has permission to write to.
- -a string
- Append a period (``.'') concatenated with string
to the file name of the log for this daemon,
as specified in the configuration file.
- -pidfile filename
- Causes the daemon to write out its PID
(process id number) to the specified filename.
This file can be used to
help shutdown the daemon without first searching through
the output of the Unix ps command.
Since daemons run with their current working directory set to the
value of LOG, if a full path (one that begins with a ``/''),
the file will be placed in the LOG directory. If you leave
the filename in the LOG directory, add this
filename to the VALID_LOG_FILES configuration variable,
described in section 3.3.16 on
page
, so that condor_ preen does not
remove it.
- -k filename
- For non-Windows operating systems,
causes the daemon to read out a PID from the
specified filename, and send a SIGTERM to that process.
The daemon started with this optional argument waits until the
daemon it is attempting to kill has exited.
- -r minutes
- Causes the daemon to set a timer, upon expiration
of which, it sends itself a SIGTERM for graceful shutdown.
- -q
- Quiet output; write less verbose error
messages to stderr when something goes wrong,
and before regular logging can be initialized.
- -d
- Use dynamic directories.
The LOG, SPOOL, and EXECUTE directories
are all created by the daemon at run time,
and they are named by appending the
parent's IP address and PID to the value in the
configuration file.
These settings are then inherited by all children of the daemon
invoked with this -d argument.
For the condor_ master,
all Condor processes will use the new directories.
If a condor_ schedd is invoked with the -d argument,
then only the condor_ schedd daemon and any
condor_ shadow daemons it spawns will use the dynamic
directories (named with the condor_ schedd daemon's PID).
Note that by using a dynamically-created spool directory
named by the IP address and PID,
upon restarting daemons,
jobs submitted to the original condor_ schedd daemon
that were stored in the old spool directory will not be noticed
by the new condor_ schedd daemon,
unless you manually specify the old, dyanmically-generated
SPOOL directory path in the configuration of the
new condor_ schedd daemon.
Next: 3.10 Pool Management
Up: 3. Administrators' Manual
Previous: 3.8 The Checkpoint Server
Contents
Index
condor-admin@cs.wisc.edu