Fair warning: the daemontools package represents the latest in Bernstein's ideas about package managment and file system layout. In fact, daemontools is the only package djb has released to date in this new format. As a consequence, the installation procedures for daemontools will differ from most of the other software described at this site.

Following the standard daemontools installation instructions, the following new top-level directories will be found in the filesystem:

/command
/package
/service

Right about now your old-time Unix traditionalists may be screaming, Whoa, dude, not in my hier(7)! Well, the djb way is just gonna be different. Yeah, I know, it really bugs at first, and a lot of keystrokes have been spilled fighting it. But just try going along with Bernstein for now on this, however much it hurts. It's part of the djb way, and will hopefully make some more sense as we go on.

The /command directory will contain symbolic links to the executables built by the package; /package will be used for the top-level build and installation directory; and /service will contain links to sub-directories under the control of daemontools' supervise utility.

The daemontools /service directory, more than any other, will come to represent the center of the djb way as our server build evolves.

Before starting the installation, though, we need to create the /package directory ourselves. For systems with a small, separate root partition (as is common on BSD systems, and recommended in any case), we set up the /package directory by way of symbolic link to a directory in the /usr partition:

# mkdir -p /usr/local/package
# chmod 1755 /usr/local/package
# ln -s /usr/local/package /package

Now all the installed files will be accessible through /package, though they will physically reside in /usr/local/package. Check this with a directory listing (the ouput is truncated here to fit the page width):

# ls -ld /package
lrwxr-xr-t ... /package -> /usr/local/package

The top-level /command and /service directories will be created by the installation procedure itself. These directories will be populated only by symlinks, and should not be an issue even on small root partitions.

As long as we're making directories, we'll go ahead and add a few more now for use later on:

# mkdir /var/svc.d
# mkdir /var/multilog
# mkdir /etc/tcprules

The /var/svc.d directory will be the base directory for daemontools service definitions. The /var/multilog directory will be used for the output from the multilog logger we'll be running for each service. The /etc/tcprules directory will be used for the tcpserver access rules described when we cover the ucspi-tcp package.

Ok? Now we're ready to go. Snag the sources into your local repository:

# cd /usr/local/djb/dist
# wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz

Verify the MD5 checksum of the package:

# md5 daemontools-0.76.tar.gz
MD5 (daemontools-0.76.tar.gz) = 1871af2453d6e464034968a0fbcb2bfc

If the checksum reported doesn't agree, the package has been altered or corrupted. Delete the archive and download the package again from a trusted source.

Unpack the source archive into /package:

# cd /package
# tar -xzvpf /usr/local/djb/dist/daemontools-0.76.tar.gz

Change into the admin/daemontools-0.76 directory just created:

# cd admin/daemontools-0.76

If you need to apply the errno patch, take care of it now:

# patch -p1 < /usr/local/djb/patches/daemontools-0.76.errno.patch

This daemontools-0.76.sigq12.patch patch may also be applied to add support for sending QUIT, USR1, and USR2 signals to supervised processes, useful for the fetchmail service, mathopd web server, and postgresql dbms:

# patch -p1 < /usr/local/djb/patches/daemontools-0.76.sigq12.patch

Then build and install the package:

# package/install

The daemontools installation is now complete! If you have a BSD system, you should check to see that the file /etc/rc.local has been created or appended with a line that reads:

csh -cf '/command/svscanboot &'

This will automatically start the daemontools svscan utility on the /service directory with the next system boot. To start up svscan now without rebooting, just run the same on the command line:

# csh -cf '/command/svscanboot &'

Similarly, if you have a System V style init, the file /etc/inittab should have been appended with a line that reads:

SV:123456:respawn:/command/svscanboot

In this case, init should have started up svscan automatically without rebooting.

Now you may be thinking, So what? Or possibly, Big deal. After all, nothing obvious is happening at this point, because we haven't installed any services yet. To verify that svscan is actually running, check that the process status looks something like:

# ps -jxww | grep svscan
root     359     1   359    0 I    con-   0:00.00 /bin/sh /command/svscanboot
root     389   359   359    0 S    con-   0:00.33 svscan /service
# ps -jxww | grep readproctitle
root     390   359   359    0 I    con-   0:00.33 readproctitle (lots of dots)

This shows that daemontools is successfully installed, ready and waiting for our next command. The following sections provide a brief overview of the package, and a blabby tutorial example.

For an advanced discussion of booting and logging svscan, see the appendix booting svscan. (Also refer to this section if you are using FreeBSD.)

In the meantime, you can report your successful installation:

# mail djb-sysdeps@cr.yp.to < /package/admin/daemontools/compile/sysdeps

Note: we refer to the type of build procedure described here as slashpackage. See also the appendix in building djb for a recap.