2014-06-12
An init system has two jobs
Ever since System V init came on the scene, it's been clear that a Unix init system really has not one but two jobs. I don't quite mean this in the sense of init's historical roles but in a more high level sense of what people want from their init.
The first job is to be init, PID 1, with everything that that implies. Init starts things on boot, supervises processes, does things on shutdown, doesn't crash, and so on. This job is well recognized and understood and as a result, essentially any real init system is pretty good at it (although some are better around the edges than others). Certainly any of them will get the job done.
The second job of an init system is to help you manage the init
system and the services and processes it controls. This is the job
not of starting and stopping things but of letting you control what
is started and stopped and so on. Not being an init system, but
controlling the init system. This job is much less well recognized
and as a result much more immature (partly because the job only
really started when System V init showed that perhaps there might
be a better way to do it than editing /etc/rc.local and running
daemons by hand, and even then it stagnated for quite a while).
Init systems are all over the map when it comes to the second job. Some of them still barely acknowledge that it exists; some sort of handle it; some are actually pretty decent. A few are genuinely pleasant. Some, unfortunately, are wretched at it. In short, this is the area where init systems really distinguish themselves from each other.
(There are differences in how init systems approach the first job and some of them do make a difference, but my view is that it's nowhere near as big a difference as the second job creates.)
As a system administrator I find this kind of an unfortunate state of affairs, since that second job is something we get to deal with on a regular basis. I really wish most init systems paid more attention to it.