Self-daemonizing code is awful

The classical UNIX approach to services is to implement them as “daemons,” +programs that run without a terminal attached and provide some service. The +key feature of a classical daemon is that, when started, it carefully +detaches itself from its initial environment and terminal, then continues +running in the background.

This is awful and I'm glad modern init replacements discourage it.

Process Tracking

Daemons don't exist in a vacuum. Administrators and owners need to be able to +start and stop daemons reliably, and check their status. The classic +self-daemonization approach makes this impossible.

Traditionally, daemons run as children of init (pid 1), even if they start +out as children of some terminal or startup process. Posix only provides +deterministic APIs for processes to manage their children and their immediate +parents; the classic daemonisation protocol hands the newly-started daemon +process off from its original parent process, which knows how to start and +stop it, to an unsuspecting init, which has no idea how this specific +daemon is special.

The standard workaround has daemons write their own PIDs to a file, but a +file is “dead” data: it's not automatically updated if the daemon dies, and +can linger long enough to contain the PID of some later, unrelated program. +PID file validity checks generally suffer from subtle (or, sometimes, quite +gross) race conditions.

Complexity

The actual code to correctly daemonize a process is surprisingly complex, +given the individual interfaces' relative simplicity:

+
The daemon must start its own process group
+
+
The daemon must detach from its controlling terminal
+
+
The daemon should close (and may reopen) file handles inherited from its + parent process (generally, a shell)
+
+
The daemon should ensure its working directory is predictable and + controllable
+
+
The daemon should ensure its umask is predictable and controllable
+
+
If the daemon uses privileged resources (such as low-numbered ports), it + should carefully manage its effective, real, and session UID and GIDs
+
+
Daemons must ensure that all of the above steps happen in signal-safe ways, + so that a daemon can be shut down sanely even if it's still starting up
+

See this list +for a longer version. It's worse than you think.

All of this gets even more complicated if the daemon has its own child +processes, a pattern common to network services. Naturally, a lot of daemons +in the real world get some of these steps wrong.

The Future

Supervisord, +Foreman, +Upstart, +Launchd, +systemd, and daemontools all +encourage services not to self-daemonize by providing a sane system for +starting the daemon with the right parent process and the right environment +in the first place.

This is a great application of +DRY, as the daemon management +code only needs to be written once (in the daemon-managing daemon) rather +than many times over (in each individual daemon). It also makes daemon +execution more predictable, since daemons “in production” behave more like +they do when run attached to a developer's console during debugging or +development.

+ + + +

+ + +comments powered by Disqus +

+ + + + + +