3.8 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.8.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 config 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 config files and what they do.

3.8.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. The 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, disassociates itself from the terminal and forks itself so that it runs in the background. This is the default behavior for Condor daemons, and what you get if you specify no options at all.

-f

Causes the daemon to start up in the foreground. Instead of forking, the daemon just runs in the foreground.

NOTE: when the condor_ master starts up daemons, it does so with the -f option since it has already forked a process for the new daemon. That is why you will see -f in the argument list of all Condor daemons that the master spawns.

-c filename

Causes the daemon to use the specified filename (you must use a full path) as its global config file. This overrides the CONDOR_CONFIG environment variable, and the regular locations that Condor checks for its config file: the condor user's home directory and /etc/condor/condor_ config.

-p port

Causes the daemon to bind to the specified port for its command socket. The master uses this option to make sure the condor_ collector and condor_ negotiator start up on the well-known ports that the rest of Condor depends on 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 described above.

-v

Causes the daemon to print out version information and exit.

-l directory

Overrides the value of LOG as specified in your config files. Primarily, this option would be 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

Whatever string you specify is automatically appended (with a ``.'') to the filename of the log for this daemon, as specified in your config file.

-pidfile filename

Causes the daemon to write out its PID, or process id number, to the specified file. This file can be used to help shutdown the daemon without searching through the output of the ``ps'' command.

Since daemons run with their current working directory set to the value of LOG , if you don't specify a full path (with a ``/'' to begin), the file will be left in the log directory. If you leave your pidfile in your log directory, you will want to add whatever filename you use to the VALID_LOG_FILES parameter, described in section 3.3.14 on page , so that condor_ preen does not remove it.

-k filename

Causes the daemon to read out a pid from the specified filename and send a SIGTERM to that process. The daemon that you start up with ``-k'' will wait until the daemon it is trying to kill has exited.

-r minutes

Causes the daemon to set a timer, upon expiration of which, 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.