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.¹

  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.²

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.

-- djb

People apparently thought /etc/inittab was not to be used? Even though (a) it's an important part of System V init³ 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.

-- cks

Anyway, adding this to the list of things to fix once my time-machine is up and running.