daemon - turns other processes into daemons

 usage: daemon [options] [--] [cmd arg...]
 options:

   -h, --help              - Print a help message then exit
   -V, --version           - Print a version message then exit
   -v, --verbose[=level]   - Set the verbosity level
   -d, --debug[=level]     - Set the debugging level

   -C, --config=path       - Specify the system configuration file
   -N, --noconfig          - Bypass the system configuration file
   -n, --name=name         - Guarantee a single named instance
   -X, --command=cmd       - Specify the client command as an option
   -P, --pidfiles=/dir     - Override standard pidfile location
   -F, --pidfile=/path     - Override standard pidfile name and location

   -u, --user=user[.group] - Run the client as user[.group]
   -R, --chroot=path       - Run the client with path as root
   -D, --chdir=path        - Run the client in directory path
   -m, --umask=umask       - Run the client with the given umask
   -e, --env="var=val"     - Set a client environment variable
   -i, --inherit           - Inherit environment variables
   -U, --unsafe            - Allow execution of unsafe executable
   -S, --safe              - Deny execution of unsafe executable
   -c, --core              - Allow core file generation

   -r, --respawn           - Respawn the client when it terminates
   -a, --acceptable=#      - Minimum acceptable client duration
   -A, --attempts=#        - Respawn # times on error before delay
   -L, --delay=#           - Delay between spawn attempt bursts (seconds)
   -M, --limit=#           - Maximum number of spawn attempt bursts

   -f, --foreground        - Run the client in the foreground
   -p, --pty[=noecho]      - Allocate a pseudo terminal for the client

   -l, --errlog=spec       - Send daemon's error output to syslog or file
   -b, --dbglog=spec       - Send daemon's debug output to syslog or file
   -o, --output=spec       - Send client's output to syslog or file
   -O, --stdout=spec       - Send client's stdout to syslog or file
   -E, --stderr=spec       - Send client's stderr to syslog or file

       --running           - Check if a named daemon is running
       --restart           - Restart a named daemon client
       --stop              - Terminate a named daemon process

daemon(1) turns other processes into daemons. There are many tasks that need to be performed to correctly set up a daemon process. This can be tedious. daemon performs these tasks for other processes.

The preparatory tasks that daemon performs for other processes are:

•

First revoke any setuid or setgid privileges that daemon may have been installed with (by system administrators who laugh in the face of danger).

•

Process command line options.

•

Change the root directory if the CW--chroot option was supplied.

•

Change the process uid and gid if the CW--user option was supplied. Only root can use this option. Note that the uid of daemon itself is changed, rather than just changing the uid of the client process.

•

Read the system configuration file (CW/etc/daemon.conf by default, or specified by the CW--config option) unless the CW--noconfig option was supplied. Then read the user's configuration file (CW~/.daemonrc), if any. Generic options are processed first, then options specific to the daemon with the given name. Note: The root directory and the user must be set before access to the configuration file can be attempted so neither --chroot nor --user options may appear in the configuration file.

•

Disable core file generation to prevent leaking sensitive information in daemons run by root (unless the CW--core option was supplied).

•

Become a daemon process:

•

If daemon was not invoked by init(8) or inetd(8):

•

Background the process to lose process group leadership.

•

Start a new process session.

•

Under SVR4, background the process again to lose process session leadership. This prevents the process from ever gaining a controlling terminal. This only happens when CWSVR4 is defined and CWNO_EXTRA_SVR4_FORK is not defined when libslack(3) is compiled. Before doing this, ignore CWSIGHUP because when the session leader terminates, all processes in the foreground process group are sent a CWSIGHUP signal (apparently). Note that this code may not execute (e.g. when started by init(8) or inetd(8) or when either CWSVR4 was not defined or CWNO_EXTRA_SVR4_FORK was defined when libslack(3) was compiled). This means that the client can't make any assumptions about the CWSIGHUP handler.

•

Change directory to the root directory so as not to hamper umounts.

•

Clear the umask to enable explicit file creation modes.

•

Close all open file descriptors. If daemon was invoked by inetd(8), CWstdin, CWstdout and CWstderr are left open since they are open to a socket.

•

Open CWstdin, CWstdout and CWstderr to CW/dev/null in case something requires them to be open. Of course, this is not done if daemon was invoked by inetd(8).

•

If the CW--name option was supplied, create and lock a file containing the process id of the daemon process. The presence of this locked file prevents two instances of a daemon with the same name from running at the same time. The standard location of the pidfile is CW/var/run on Linux and CW/etc on Solaris for root or CW/tmp for ordinary users. If the CW--pidfiles option was supplied, its argument specifies the directory in which the pidfile will be placed. If the CW--pidfile option was supplied, its argument specifies the name of the pidfile and the directory in which it will be placed.

•

If the CW--umask option was supplied, set the umask to its argument. Otherwise, set the umask to CW022 to prevent clients from accidentally creating group or world writable files.

•

Set the current directory if the CW--chdir option was supplied.

•

Spawn the client command and wait for it to terminate. The client command may be specified as command line arguments or as the argument of the CW--command option. If both the CW--command option and command line arguments are present, the client command is the result of appending the command line arguments to the argument of the CW--command option.

•

If the CW--syslog, CW--outlog and/or CW--errlog options were supplied, the client's standard output and/or standard error are captured by daemon and sent to the respective syslog destinations.

•

When the client terminates, daemon respawns it if the CW--respawn option was supplied. If the client ran for less than 300 seconds (or the value of the CW--acceptable option), then daemon sees this as an error. It will attempt to restart the client up to five times (or the value of the CW--attempts option) before waiting for 300 seconds (or the value of the CW--delay option). This gives the administrator the chance to correct whatever is preventing the client from running without overloading system resources. If the CW--limit option was supplied, daemon terminates after the specified number of spawn attempt bursts. The default is zero which means never give up, never surrender. When the client terminates and the CW--respawn option wasn't supplied, daemon terminates.

•

If daemon receives a CWSIGTERM signal, it propagates the signal to the client and then terminates.

•

If daemon receives a CWSIGUSR1 signal (from another invocation of daemon supplied with the CW--restart option), it sends a CWSIGTERM signal to the client. If started with the CW--respawn option, the client process will be restarted after it is killed by the CWSIGTERM signal.

•

If the CW--foreground option was supplied, the client process is run as a foreground process and is not turned into a daemon. If daemon is connected to a terminal, so will the client process. If daemon is not connected to a terminal but the client needs to be connected to a terminal, use the CW--pty option.

Display a help message and exit. Display a version message and exit. Set the message verbosity level to level (or 1 if level is not supplied). daemon does not have any verbose messages so this has no effect unless the CW--running option is supplied. Set the debug message level to level (or 1 if level is not supplied). Set to level 1 for a trace of all functions called. Set to level 2 for more detail. Debug messages are sent to the syslog(3) facility, CWdaemon.debug. Specify the configuration file to use. By default, CW/etc/daemon.conf is the configuration file if it exists and is not group or world writable and does not exist in a group or world writable directory. The configuration file lets you predefine options that apply to all clients and to specifically named clients. Bypass the system configuration file, CW/etc/daemon.conf. Only the user's CW~/.daemonrc configuration file will be read (if it exists). Create and lock a pid file (CW/var/run/nameCW.pid), ensuring that only one daemon with the given name is active at the same time. Specify the client command as an option. If a command is specified along with its name in the configuration file, then daemons can be started merely by mentioning their name:

    daemon --name ftumpch

CW/etc/daemon.conf, CW~/.daemonrc - define default options

Each line of the configuration file consists of a client name or CW'*', followed by whitespace, followed by a comma separated list of options. Blank lines and comments (CW'#' to end of the line) are ignored. Lines may be continued with a CW'\' character at the end of the line.

For example:

    *       errlog=daemon.err,output=local0.err,core
    test1   syslog=local0.debug,debug=9,verbose=9,respawn
    test2   syslog=local0.debug,debug=9,verbose=9,respawn

The command line options are processed first to look for a CW--config option. If no CW--config option was supplied, the default file, CW/etc/daemon.conf, is used. If the user has their own configuration file, CW~/.daemorc it is also used. If the configuration files contain any generic (CW'*') entries, their options are applied in order of appearance. If the CW--name option was supplied and the configuration files contain any entries with the given name, their options are then applied in order of appearance. Finally, the command line options are applied again. This ensures that any generic options apply to all clients by default. Client specific options override generic options. User options override system wide options. Command line options override everything else.

Note that the configuration files are not opened and read until after any CW--chroot and/or CW--user command line options are processed. This means that the configuration file paths and the client's file path must be relative to the CW--chroot argument. It also means that the configuration files and the client executable must be readable/executable by the user specified by the CW--user argument. It also means that the CW--chroot and CW--user options must not appear in the configuration file. Also note that the CW--name must not appear in the configuration file either.

If you specify (in a configuration file) that all clients allow core file generation, there is no way to countermand that for any client (without using an alternative configuration file). So don't do that. The same applies to respawning and foreground.

It is possible for the client process to obtain a controlling terminal under BSD (and even under SVR4 if CWSVR4 was not defined or CWNO_EXTRA_SVR4_FORK was defined when libslack(3) is compiled). If anything calls open(2) on a terminal device without the CWO_NOCTTY flag, the process doing so will obtain a controlling terminal and then be susceptible to unintended termination by a CWSIGHUP.

Clients run in the foreground with a pseudo terminal don't respond to job control (i.e. suspending with Control-Z doesn't work). This is because the client belongs to an orphaned process group (it starts in its own process session) so the kernel won't send it CWSIGSTOP signals. However, if the client is a shell that supports job control, it's subprocesses can be suspended.

Clients can only be restarted if they were started with the CW--respawn option. Using CW--restart on a non-respawning daemon client is equivalent to using CW--stop.

The following mailing lists exist for daemon related discussion:

 daemon-announce@libslack.org - Announcements
 daemon-users@libslack.org    - User forum
 daemon-dev@libslack.org      - Development forum

To subscribe to any of these mailing lists, send a mail message to listnameCW-request@libslack.org with CWsubscribe as the message body. e.g.

 $ echo subscribe | mail daemon-announce-request@libslack.org
 $ echo subscribe | mail daemon-users-request@libslack.org
 $ echo subscribe | mail daemon-dev-request@libslack.org

Or you can send a mail message to CWmajordomo@libslack.org with CWsubscribe listname in the message body. This way, you can subscribe to multiple lists at the same time. e.g.

 $ mail majordomo@libslack.org
 subscribe daemon-announce
 subscribe daemon-users
 subscribe daemon-dev
 .

A digest version of each mailing list is also available. Subscribe to digests as above but append CW-digest to the listname.

libslack(3), daemon(3), coproc(3), pseudo(3), init(8), inetd(8), fork(2), umask(2), setsid(2), chdir(2), chroot(2), setrlimit(2), setgid(2), setuid(2), setgroups(2), initgroups(3), syslog(3), kill(2)

20040806 raf <raf@raf.org>