The daemontools package gives you a set of tools to build, start, run, log and control daemons, otherwise known as services.
The services you run with the help of daemontools are defined by simple "run" scripts. In fact, the daemontools "run" scripts are actually named run, installed into specific locations. The conventional path to a service "run" script is simply:
The elements of this path are:
The "run" script itself execs the desired service, and may be as simple as:
#!/bin/sh # myservice/run exec myservice
exec is used to run myservice, so that the shell process is replaced by myservice. Otherwise, the only other requirement for a daemontools service is that it run in the foreground.
It is customary to add logging to a service. Logging is itself a service, and is also installed with a "run" script, following this naming convention:
The additional elements of this path are:
Whenever a logging service is found for a service, daemontools automatically connects the standard output from the service "run" script to the standard input of the logging "run" script. The logging run script for myservice may be as simple as:
#!/bin/sh # myservice/log/run exec multilog t /var/multilog/myservice
Here the daemontools multilog utility is used to capture the output from myservice, timestamp it, and write it to a set of automatically rotated log files in the directory /var/multilog/myservice.
We will see a lot of "run" scripts along the djb way, and describe them in more detail. For now we only want to illustrate the essential simplicity of daemontools. Just install a couple of "run" scripts:
And your service is good to go.
To properly install and manage services in practice, we do introduce a slight complication to this scheme: the installation of myservice into /service is really performed via symbolic link, pointing to the true location of the myservice definition elsewhere on the system.
In this documentation we use /var/svc.d as the standard base directory for all daemontools services defined for a system. So the "run" scripts and configuration files for myservice will actually reside in:
Activating myservice is then a symlink away:
# ln -s /var/svc.d/myservice /service/myservice
A directory listing of /service will then show (output truncated):
$ ls -ld /service/* /service/myservice -> /var/svc.d/myservice
The symlink makes the "run" scripts visible under /service as before, where svscan will find them:
And your service is good to go.
Of course, all of this will become clearer as you work through the tutorial and begin to install a few services on your own.
For now, let's recap the utilities installed with daemontools, categorized by purpose:
|utilities for running services:|
|supervise||supervise a single service|
|svcan||supervise a directory of services||svscanboot||start svscan on the /service directory|
|utilities for checking services:|
|svok||exit 0 if supervise running a service|
|svstat||print readable status report for a service|
|utility for controlling services:|
|svc||control/signal a service|
|utilities for logging services:|
|multilog||log a service|
|readproctitle||logging to ps|
|utilities for building "run" scripts:|
|envdir||setup environmental variables|
|envuidgid||setup for privelege control|
|"hacks" and other utilities for run scripts:|
|fghack||try to keep a program in the foreground||pgrphack||run a program in a separate process group|
|setlock||set a file lock while running a program|
|TAI timestamp utilities:|
|tai64n||apply tai timestamp to each line of input|
|tai64nlocal||convert tai timestamp to readable format|
This may seem like a lot, and it is: there is a lot of power here.
Fortunately, you will be able to access this power as you go along, mastering the use of daemontools as your familiarity with services and "run" scripts grows. Because every service we describe will always follow this simple daemontools paradigm:
Ready for more? Check out the "blabbyd" tutorial to get started.
Copyright © 2003, 2004, Wayne Marshall.
All rights reserved.
Last edit 2004.10.04, wcm.