Ever wonder why unix daemons have a "run in the foreground" option (usually `-f`)?
A long time ago (before Linux), all daemons in AT&T unix-land were managed by init(1), ie. admins would add the lines like the following to /etc/inittab, run `telinit q`, and init(1) would start up the daemons and restart them if they ever fell over.1
na:3:respawn:/usr/sbin/named -f se:3:respawn:/usr/sbin/sendmail -bD ss:3:respawn:/usr/local/sbin/sshd -f
So how were daemons restarted?
Signals. Most of time, one never needed to restart a daemon, as the config only needed to be reloaded, eg. `killall -HUP sendmail ; tail -f /var/log/mail ` A full restart was just `killall -TERM sendmail` because sendmail(8) would clean up and exit, then init(1) would dutifully respawn it. And if that didn't work, `killall -KILL sendmail` would do its job.
What about site-dependent startup customizations?
Instead of running the binary directly, /etc/inittab would refer to `/usr/local/sbin/init-httpd.sh` which would look something like
#!/bin/sh exec chroot /chroot/www /usr/local/sbin/httpd -DFOREGROUND
So why did the SysVinit-based Linux distributions stop using inittab? It seems to have been a less-than-optimal change, as this story about sysv-inflicted braindamage indicates.2
djb's daemontools points out that automation was an issue. Which is weird, why wouldn't we have just update init(1) to respawn scripts in /etc/inittab.d/, especially when we were already hacking in C with start-stop-daemon.c?
In contrast, with inittab, ttys, and rc.local, creating a new service means adding some lines to a centralized file, and removing the service means locating and removing those lines. This is much more difficult to automate; there are no portable tools for editing the file. Most packages leave it to the user to do the editing.
People apparently thought /etc/inittab was not to be used? Even though (a) it's an important part of System V init3 and (b) there's the above counterfactual that all major unix daemons had a "run in foreground" mode for normal operation.
There is no provision for restarting services on failure. Technically you can give your service a direct /etc/inittab entry (if it doesn't background itself) but then you move it outside of what people consider 'the init system' and lose everything associated with a regular init script.
Anyway, adding this to the list of things to fix once my time-machine is up and running.