2022-02-20
The history (sort of) of service management in Unix
It's common for sophisticated Unix init systems to also be some degree of service management systems; the most obvious example is Linux's systemd. However, many people have observed that it doesn't have to be this way and have created separate systems for this, such as D. J. Bernstein's daemontools. Since service management (or lack of it) has become one of the important areas of Unix init systems, you might wonder why they've come to have this responsibility. A significant part of the reason is history, although there are also pragmatic reasons.
(I also think that it's what people want. System administratorys mostly don't want to have to deal with an init system and then a separate service supervision system; they want to deal with one thing.)
Specifically, for a long time Unix didn't have any sort of service
management as such, beyond init restarting getty processes. All services were simply started as part of
the boot process in what started as a very simple script and grew
only somewhat from there in BSD Unixes. If you needed to check the
status of services, you ran ps; if you needed to restart a service,
you terminated it with kill and started the new version by hand.
The System V init system moved this forward somewhat by creating
scripts that encapsulated the knowledge of how to start, stop, and
sometimes check the status of each service, but it did nothing to
manage the services as such; it still merely booted (and shut down)
the system. Noticing that a service's daemons had died and starting
them again was up to you.
(In System V init you could theoretically use /etc/inittab for restarting daemons, but the overall init system environment didn't support doing it this way.)
Historically, starting services was considered intertwined with the
process of booting Unix. Starting from when Sun introduced "diskless"
NFS based workstations and other people copied them, some daemons
needed to be started and running before /usr could be mounted.
You couldn't defer starting all services until the system was 'up',
but at the same time you couldn't just start all services in a bunch
and be done with it, because many of them required filesystem mounts
and the like. This entanglement of starting daemons and booting the
system made putting everything in boot scripts the natural way
forward from the mid 1980s onward. A daring Unix vendor could have
introduced a separate services system (Sun eventually sort of did
in SMF),
but it still would have been deeply entwined in the boot process
and thus the init system if it was going to handle all daemons and
services on the system.
(Third party systems such as djb's daemontools generally had a simpler job because they weren't envisioned as handling all daemons and services; they were just going to handle some of them, such as djb's other programs such as qmail and tinydns.)
In practice, Unix vendors in the 1990s were not daring. Instead, they were busy fighting with each other (see OSF/1 versus System V release 4) and getting run over by the march of the cheap. The free Unixes did no better; the free BSDs were busy being faithful to the purity of UCB BSD 4.x, and Linux was hard at work building a Unix from scratch (and perhaps was not inclined to depart from various versions of what was 'Unix' at the time as a result of the 'Linux is not Unix' controversies of the time).
(This is a somewhat grumpy summary of the situation, since the free BSDs did make major changes in their init setups in practice. But for whatever reason, none of them changed drastically into a separate services manager setup, although daemontools and other implementations shows that the idea was definitely around in the open source Unix community. Possibly one problem is that Solaris SMF wasn't a good system.)
PS: I wrote up a somewhat different version of this history some years ago in How init wound up as Unix's daemon manager. Rereading that, I see that in writing this entry I forgot how the addition of networking in BSD Unix complicated system boot and daemon startup, because now you needed the network configured before some daemons got started.