How init wound up as Unix's daemon manager

December 14, 2014

If you think about it, it's at least a little bit odd that PID 1 wound up as the de facto daemon manager for Unix. While I believe that the role itself is part of the init system as a whole, this is not the same thing as having PID 1 do the job and in many ways you'd kind of expect it to be done in another process. As with many things about Unix, I think that this can be attributed to the historical evolution Unix has gone through.

As I see the evolution of this, things start in V7 Unix (or maybe earlier) when Research Unix grew some system daemons, things like crond. Something had to start these, so V7 had init run /etc/rc on boot as the minimal approach. Adding networking to Unix in BSD Unix increased the number of daemons to start (and was one of several changes that complicated the whole startup process a lot). Sun added even more daemons with NFS and YP and so on and either created or elaborated interdependencies among them. Finally System V came along and made everything systematic with rcN.d and so on, which was just in time for yet more daemons.

(Modern developments have extended this even further to actively monitoring and restarting daemons if you ask them to. System V init could technically do this if you wanted, but people generally didn't use inittab for this.)

At no point in this process was it obvious to anyone that Unix was going through a major sea change. It's not as if Unix went in one step from no daemons to a whole bunch of daemons; instead there was a slow but steady growth in both the number of daemons and the complexity of system startup in general, and much of this happened on relatively resource-constrained machines where extra processes were a bad idea. Had there been a single giant step, maybe people would have sat down and asked themselves if PID 1 and a pile of shell scripts were the right approach and said 'no, it should be a separate process'. But that moment never happened; instead Unix basically drifted into the current situation.

(Technically speaking you can argue that System V init actually does do daemon 'management' in another process. System V init doesn't directly start daemons; instead they're started several layers of shell scripts away from PID 1. I call it part of PID 1 because there is no separate process that really has this responsibility, unlike the situation in eg Solaris SMF.)


Comments on this page:

By Chris at 2014-12-14 03:52:25:

How is it strange? init's job is starting processes. That daemons happen to be long-lived seems more like an implementation detail of daemons, something the daemon starter doesn't need to be concerned with.

By cks at 2014-12-14 16:44:55:

Actually PID 1's job is inheriting orphaned processes and cleaning up after them. This is the one thing that is special about PID 1. Any process can be a daemon manager; only PID 1 inherits orphans.

(Because PID 1 is the first process started, it has also inherited the job of starting the system. However this is not an intrinsic part of its job any more than starting processes and supervising daemons is. In practice almost all of this job is delegated to other processes in a non-systematic way in most systems, and in a systematic way in some (eg Solaris SMF).)

Written on 14 December 2014.
« There are two parts to making your code work with Python 3
Why your 64-bit Go programs may have a huge virtual size »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Dec 14 00:55:12 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.