Traditionally, init on Unix was not a service manager as such

October 4, 2024

Init (the process) has historically had a number of roles but, perhaps surprisingly, being a 'service manager' (or a 'daemon manager') was not one of them in traditional init systems. In V7 Unix and continuing on into traditional 4.x BSD, init (sort of) started various daemons by running /etc/rc, but its only 'supervision' was of getty processes for the console and (other) serial lines. There was no supervision or management of daemons or services, even in the overall init system (stretching beyond PID 1, init itself). To restart a service, you killed its process and then re-ran it somehow; getting even the command line arguments right was up to you.

(It's conventional to say that init started daemons during boot, even though technically there are some intermediate processes involved since /etc/rc is a shell script.)

The System V init had a more general /etc/inittab that could in theory handle more than getty processes, but in practice it wasn't used for managing anything more than them. The System V init system as a whole did have a concept of managing daemons and services, in the form of its multi-file /etc/rc.d structure, but stopping and restarting services was handled outside of the PID 1 init itself. To stop a service you directly ran its init.d script with 'whatever stop', and the script used various approaches to find the processes and get them to stop. Similarly, (re)starting a daemon was done directly by its init.d script, without PID 1 being involved.

As a whole system the overall System V init system was a significant improvement on the more basic BSD approach, but it (still) didn't have init itself doing any service supervision. In fact there was nothing that actively did service supervision even in the System V model. I'm not sure what the first system to do active service supervision was, but it may have been daemontools. Extending the init process itself to do daemon supervision has a somewhat controversial history; there are Unix systems that don't do this through PID 1, although doing a good job of it has clearly become one of the major jobs of the init system as a whole.

That init itself didn't do service or daemon management is, in my view, connected to the history of (process) daemonization. But that's another entry.

(There's also my entry on how init (and the init system as a whole) wound up as Unix's daemon manager.)


Comments on this page:

The first, albeit specialized, active supervision system (with health checks!) I could find was ninit (1991) by Ted Ts'o which restarted BIND when it got stuck.

By K.C. Marshall at 2024-10-07 08:52:42:

Carnegie Mellon has had "nanny" since time immemorial... the man page I see is dated 1986 and says it was created in 1985. It is even immortalized on page 198 of "The UNIX-HATERS Handbook" ( from 1994 )

nanny worked well and is generalized, but it is not easy to use. nanny has a clever "back off" timing for restarts - it'll try a few restarts quickly and then it will wait progressively longer until it reaches its maximum (60 minutes). I never tested to see if or when it resets its back-off timing, but then I never had any reason to dig into it since it seemed to just work as needed.

Upstart and Systemd finally grew the general ability to restart failed services, which is a nice feature.

Written on 04 October 2024.
« (Unix) daemonization turns out to be quite old
Daemonization in Unix programs is probably about restarting programs »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Fri Oct 4 23:05:27 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.