The history (sort of) of service management in Unix

The history (sort of) of service management in Unix

February 20, 2022

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

(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

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.

Read More

[an error occurred while processing the directive]