This leaves process management to each program. MaraDNS, for example, has three different 100-line shell scripts to manage the starting and stopping of MaraDNS processes, and a nearly 300-line C program (duende) which handles making MaraDNS a UNIX daemon ("service" in Windows' parlance) and logging MaraDNS' messages.
Much to Nicholas Bamber's annoyance, the way daemons are managed on Red Hat/CentOS 6 (the system I develop MaraDNS on) is somewhat different than the way Debian (the system Nicholas ports MaraDNS to) handles processes, which makes the port more difficult than it should be.
SysVInit has other annoyances. For example, a single daemon that, for whatever reason, takes a while to start up will slow down the boot process for the entire system. Sendmail is notorious for sometimes taking minutes to start up; it's a very frustrating experience watching a system boot stall until Sendmail is finally running.
Pretty soon, a UNIX server can be running a number of different "daemonizing" programs that all do more or less the same thing: Starting, stopping, restarting, and logging processes.
This kind of fragmentation is a headache for system administrators, who now have to learn multiple ways of handling processes on their system. It also means that each "home grown" solution will not be as well-developed as a single unified solution. Duende, for example, only respawns a terminated process under certain circumstances which are hard-wired in its C source code.
It replaces a menagerie of different daemonizers with a single clean, elegant, centrally maintained init replacement. It will make it easier for me to maintain MaraDNS, because I will be able to concentrate on the central daemon that processes DNS queries instead of worrying about how its daemonization is handled in a given Linux distribution.
To post a comment about an entry, send me an email and I may or may not post your comment (with or without editing)