Daemon process control library and tools for Unix-based systems
zdaemon is a Python package which provides APIs for managing applications run as daemons. Its principal use to date has been to manage the application server and storage server daemons for Zope / ZEO, although it is not limited to running Python-based applications (for instance, it has been used to manage the ‘spread’ daemon).
zdaemon provides a script, zdaemon, that can be used to run other programs as POSIX (Unix) daemons. (Of course, it is only usable on POSIX-complient systems.)
Using zdaemon requires specifying a number of options, which can be given in a configuration file, or as command-line options. It also accepts commands teling it what do do. The commands are:
Start a process as a daemon
Stop a running daemon process
Stop and then restart a program
Find out if the program is running
- foreground or fg
Run a program
- kill signal
Send a signal to the daemon process
Reopen the transcript log. See the discussion of the transcript log below.
- help command
Get help on a command
Commands can be given on a command line, or can be given using an interactive interpreter.
Let’s start with a simple example. We’ll use command-line options to run the echo command:
sh> ./zdaemon -p ‘echo hello world’ fg echo hello world hello world
Here we used the -p option to specify a program to run. We can specify a program name and command-line options in the program command. Note, however, that the command-line parsing is pretty primitive. Quotes and spaces aren’t handled correctly. Let’s look at a slightly more complex example. We’ll run the sleep command as a daemon :)
sh> ./zdaemon -p ‘sleep 100’ start . . daemon process started, pid=819
This ran the sleep deamon. We can check whether it ran with the status command:
sh> ./zdaemon -p ‘sleep 100’ status program running; pid=819
We can stop it with the stop command:
sh> ./zdaemon -p ‘sleep 100’ stop . . daemon process stopped
sh> ./zdaemon -p ‘sleep 100’ status daemon manager not running
Normally, we control zdaemon using a configuration file. Let’s create a typical configuration file:
<runner> program sleep 100 </runner>
Now, we can run with the -C option to read the configuration file:
sh> ./zdaemon -Cconf start . . daemon process started, pid=1136
If we list the directory:
sh> ls conf zdaemon zdsock
We’ll see that a file, zdsock, was created. This is a unix-domain socket used internally by ZDaemon. We’ll normally want to control where this goes.
sh> ./zdaemon -Cconf stop . . daemon process stopped
Here’s an updated configuration:
<runner> program sleep 100 socket-name /tmp/demo.zdsock </runner>
Now, when we run zdaemon:
sh> ./zdaemon -Cconf start . . daemon process started, pid=1139
sh> ls conf zdaemon
The socket file is created in the given directory.
sh> ./zdaemon -Cconf stop . . daemon process stopped
In the example, we included a command-line argument in the program option. We can also provide options on the command line:
<runner> program sleep socket-name /tmp/demo.zdsock </runner>
Then we can pass the program argument on the command line:
sh> ./zdaemon -Cconf start 100 . . daemon process started, pid=1149
sh> ./zdaemon -Cconf status program running; pid=1149
sh> ./zdaemon -Cconf stop . . daemon process stopped
Sometimes, it is necessary to set environment variables before running a program. Perhaps the most common case for this is setting LD_LIBRARY_PATH so that dynamically loaded libraries can be found.
<runner> program env socket-name /tmp/demo.zdsock </runner> <environment> LD_LIBRARY_PATH /home/foo/lib HOME /home/foo </environment>
Now, when we run the command, we’ll see out environment settings reflected:
sh> ./zdaemon -Cconf fg env USER=jim HOME=/home/foo LOGNAME=jim USERNAME=jim TERM=dumb PATH=/home/jim/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin EMACS=t LANG=en_US.UTF-8 SHELL=/bin/bash EDITOR=emacs LD_LIBRARY_PATH=/home/foo/lib
When zdaemon run a program in daemon mode, it disconnects the program’s standard input, standard output, and standard error from the controlling terminal. It can optionally redirect the output to standard error and standard output to a file. This is done with the transcript option. This is, of course, useful for logging output from long-running applications.
Let’s look at an example. We’ll have a long-running process that simple tails a data file:
>>> f = open('data', 'w', 0) >>> import os >>> f.write('rec 1\n'); os.fsync(f.fileno())
Now, here’s out zdaemon configuration:
<runner> program tail -f data transcript log </runner>
Now we’ll start:
sh> ./zdaemon -Cconf start . . daemon process started, pid=7963
After waiting a bit, if we look at the log file, it contains the tail output:
>>> open('log').read() 'rec 1\n'
We can rotate the transcript log by renaming it and telling zdaemon to reopen it:
>>> import os >>> os.rename('log', 'log.1')
If we generate more output:
>>> f.write('rec 2\n'); os.fsync(f.fileno())
The output will appear in the old file, because zdaemon still has it open:
>>> open('log.1').read() 'rec 1\nrec 2\n'
Now, if we tell zdaemon to reopen the file:
sh> ./zdaemon -Cconf reopen_transcript
and generate some output:
>>> f.write('rec 3\n'); os.fsync(f.fileno())
the output will show up in the new file, not the old:
>>> open('log').read() 'rec 3\n'>>> open('log.1').read() 'rec 1\nrec 2\n'
Normally, zdaemon considers a process to have started when the process itself has been created. A process may take a while before it is truly up and running. For example, a database server or a web server may take time before they’re ready to accept requests.
You can optionally supply a test program, via the start-test-program configuration option, that is called repeatedly until it returns a 0 exit status or until a time limit, start-timeout, has been reached.
The following options are available for use in the runner section of configuration files and as command-line options.
Command-line option: -p or –program
This option gives the command used to start the subprocess managed by zdaemon. This is currently a simple list of whitespace-delimited words. The first word is the program file, subsequent words are its command line arguments. If the program file contains no slashes, it is searched using $PATH. (Note that there is no way to to include whitespace in the program file or an argument, and under certain circumstances other shell metacharacters are also a problem.)
Command-line option: -s or –socket-name.
The pathname of the Unix domain socket used for communication between the zdaemon command-line tool and a deamon-management process. The default is relative to the current directory in which zdaemon is started. You want to specify an absolute pathname here.
This defaults to “zdsock”, which is created in the directory in which zdrun is started.
Command-line option: -d or –daemon.
If this option is true, zdaemon runs in the background as a true daemon. It forks a child process which becomes the subprocess manager, while the parent exits (making the shell that started it believe it is done). The child process also does the following:
if the directory option is set, change into that directory
redirect stdin, stdout and stderr to /dev/null
call setsid() so it becomes a session leader
call umask() with specified value
The default for this option is on by default. The command-line option therefore has no effect. To disable daemon mode, you must use a configuration file:
<runner> program sleep 1 daemon off </runner>
Command-line option: -z or –directory.
If the daemon option is true (default), this option can specify a directory into which zdrun.py changes as part of the “daemonizing”. If the daemon option is false, this option is ignored.
Command-line option: -b or –backoff-limit.
When the subprocess crashes, zdaemon inserts a one-second delay before it restarts it. When the subprocess crashes again right away, the delay is incremented by one second, and so on. What happens when the delay has reached the value of backoff-limit (in seconds), depends on the value of the forever option. If forever is false, zdaemon gives up at this point, and exits. An always-crashing subprocess will have been restarted exactly backoff-limit times in this case. If forever is true, zdaemon continues to attempt to restart the process, keeping the delay at backoff-limit seconds.
If the subprocess stays up for more than backoff-limit seconds, the delay is reset to 1 second.
This defaults to 10.
Command-line option: -f or –forever.
If this option is true, zdaemon will keep restarting a crashing subprocess forever. If it is false, it will give up after backoff-limit crashes in a row. See the description of backoff-limit for details.
This is disabled by default.
Command-line option: -x or –exit-codes.
This defaults to 0,2.
If the subprocess exits with an exit status that is equal to one of the integers in this list, zdaemon will not restart it. The default list requires some explanation. Exit status 0 is considered a willful successful exit; the ZEO and Zope server processes use this exit status when they want to stop without being restarted. (Including in response to a SIGTERM.) Exit status 2 is typically issued for command line syntax errors; in this case, restarting the program will not help!
NOTE: this mechanism overrides the backoff-limit and forever options; i.e. even if forever is true, a subprocess exit status code in this list makes zdaemon give up. To disable this, change the value to an empty list.
A command that tests whether the program is up and running. The command should exit with a zero exit statis if the program is running and with a non-zero status otherwise.
Command-line option: -T or –start-timeout.
If the program takes more than start-timeout seconds to start, then an error is printed and the control script will exit with a non-zero exit status.
This defaults to 500 seconds (5 minutes).
When a stop command is issued, a SIGTERM signal is sent to the process. zdaemon waits for stop-timeout seconds for the process to gracefully exit. If the process doesn’t exit in that time, a SIGKILL signal is sent.
Command-line option: -u or –user.
When zdaemon is started by root, this option specifies the user as who the the zdaemon process (and hence the daemon subprocess) will run. This can be a user name or a numeric user id. Both the user and the group are set from the corresponding password entry, using setuid() and setgid(). This is done before zdaemon does anything else besides parsing its command line arguments.
NOTE: when zdaemon is not started by root, specifying this option is an error. (XXX This may be a mistake.)
XXX The zdaemon event log file may be opened before setuid() is called. Is this good or bad?
Command-line option: -m or –umask.
When daemon mode is used, this option specifies the octal umask of the subprocess.
If this option is true, zdaemon enters interactive mode when it is invoked without a positional command argument. If it is false, you must use the -i or –interactive command line option to zdaemon to enter interactive mode.
This is enabled by default.
This option specifies a log file that is the default target of the “logtail” zdaemon command.
NOTE: This is NOT the log file to which zdaemon writes its logging messages! That log file is specified by the <eventlog> section described below.
The name of a file in which a transcript of all output from the command being run will be written to when daemonized.
If not specified, output from the command will be discarded.
This only takes effect when the “daemon” option is enabled.
The prompt shown by the controller program. The default must be provided by the application.
(Note that a few other options are available to support old configuration files, but aren’t needed any more and can generally be ignored.)
In addition to the runner section, you can use an eventlog section that specified one or more logfile subsections:
<eventlog> <logfile> path /var/log/foo/foo.log </logfile> <logfile> path STDOUT </logfile> </eventlog>
In this example, log output is sent to a file and to standard out. Log output from zdaemon usually isn’t very interesting but can be handy for debugging.
Added an option, start-test-program to supply a test command to test whether the program managed by zdaemon is up and operational, rather than just running. When starting a program, the start command doesn’t return until the test passes. You could, for example, use this to wait until a web server is actually accepting connections.
Added a start-timeout option to error if a program takes too long to start. This is especially useful in combination with the start-test-program option.
Added a separate option, stop-timout, to control how long to wait for a graceful shutdown.
Previously, this was controlled by backoff-limit, which didn’t make much sense.
Version 2.0.3 broke support for relative paths to the socket (-s option and socket-name parameter), now relative paths work again as in version 2.0.2.
Fixed change log format, made table of contents nicer.
Fixed author’s email address.
Removed zpkg stuff.
Added support to bootstrap on Jython.
If the run directory does not exist it will be created. This allow to use /var/run/mydaemon as run directory when /var/run is a tmpfs (LP #318118).
No longer uses a hardcoded filename (/tmp/demo.zdsock) in unit tests. This lets you run the tests on Python 2.4 and 2.5 simultaneously without spurious errors.
make -h work again for both runner and control scripts. Help is now taken from the __doc__ of the options class users by the zdaemon script being run.
Fixed backwards incompatible change in handling of environment option.
Fixed test renormalizer that did not work in certain cases where the environment was complex.
Final release for 2.0.0.
When the user option was used, it only affected running the daemon.
The new (2.0) mechanism used by zdaemon to start the daemon manager broke some applications that extended zdaemon.
Added extra checks to deal with programs that extend zdaemon and copy the schema and thus don’t see updates to the ZConfig schema.
Added support for setting environment variables in the configuration file. This is useful when zdaemon is used to run programs that need environment variables set (e.g. LD_LIBRARY_PATH).
Added a command to rotate the transcript log.
In non-daemon mode, start hung, producing annoying dots when the program exited.
The start command hung producing annoying dots if the deamon failed to start.
foreground and start had different semantics because one used os.system and another used os.spawn
Command-line arguments can now be supplied to the start and foreground (fg) commands
zdctl now invokes itself to run zdrun. This means that it’s no-longer necessary to generate a separate zdrun script. This especially when the magic techniques to find and run zdrun using directory sniffing fail to set the path corrrectly.
The daemon mode is now enabled by default. To get non-deamon mode, you have to use a configuration file and set deamon to off there. The old -d option is kept for backward compatibility, but is a no-op.
Fixed a bug in the distribution setup file.
First semi-formal release.
Made ‘zdaemon.zdoptions’ not fail for –help when __main__.__doc__ is None.
Updated test ‘testRunIgnoresParentSignals’:
- o Use ‘mkdtemp’ to create a temporary directory to hold the test socket
rather than creating the test socket in the test directory. Hopefully this will be more robust. Sometimes the test directory has a path so long that the test socket can’t be created.
- o Changed management of ‘donothing.sh’. This script is now created by
the test in the temporarary directory with the necessary permissions. This is to avoids possible mangling of permissions leading to spurious test failures. It also avoids management of a file in the source tree, which is a bonus.
Rearranged source tree to conform to more usual zpkg-based layout:
o Python package lives under ‘src’.
o Dependencies added to ‘src’ as ‘svn:externals’.
o Unit tests can now be run from a checkout.
Made umask-based test failures due to running as root emit a more forceful warning.
SVN tag: svn://svn.zope.org/repos/main/zdaemon/tags/zdaemon-1.1
Tagged to make better ‘svn:externals’ linkage possible.
Document/demonstrate some important features, such as:
Release history Release notifications | RSS feed
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.