[ale] A history of modern init systems (1992-2015)

Steve Litt slitt at troubleshooters.com
Wed Sep 9 20:51:14 EDT 2015


On Wed, 9 Sep 2015 13:14:53 -0400
"Jeremy T. Bouse" <jeremy.bouse at undergrid.net> wrote:

> And here all along I just thought daemontools only existed because DJB
> doesn't like to use tools he didn't write himself.

There's some truth in that.

Back when djb created daemontools, the alternatives had simple benefits
but not a simple construction. I don't know djb, but judging from his
program and his code, I imagine he looked around at the available ways
to start processes, and said "I'm not using this crap to start *my*
software." For all I know, he might have had all sorts of complaints
how djbdns and qmail etc started with the various inits at the time.

So he made the most conceptually simple, beautifully simple init to
match his other stuff. Once again, he used the Linux file hierarchy as
hs database. This makes things *so* easy to understand, describe and
document. Then, he did something revolutionary: He decided that his
process supervisor would put the programs in the background, not the
programs themselves. This gave him a whole new level of control over
the processes, and eliminated the need to keep track of pid files and
make sure they get deleted when something terminates, no matter how it
terminates.

I'm pretty sure djb had no intention of daemontools ever being used as
an init. I think his vision was for the init to spawn daemontools, and
daemontools to spawn his software (qmail, djbdns, etc).

The thing is, people who tried daemontools loved daemontools, and two
things were inevitable: 1) People would make supersets of daemontools,
and 2) People would start trying to use daemontools as the major part
of the init.

The runit and s6 programs succeeded in making a daemontools superset
into an init program. But nobody cared: sysvinit was good enough, so
they just kept putting 

SV:123456:respawn:/command/svscanboot

into /etc/inittab in order to run a few daemons that were inconvenient
with sysvinit run scripts.

Then systemd came out, and that had two effects:

1) After years of nobody paying any attention to sysvinit (or Upstart),
   all of a sudden everyone was saying that sysvinit (and Upstart) were
   junk.

2) Systemd's "everything connects to everything else" architecture
   caused some folks to seek an alternative to systemd. Sysvinit, once
   not maintained, wasn't a good alternative because its init scripts
   are so convoluted.

All of a sudden, init was important. So everyone started studying what
inits really do. Rich Felker wrote his famous doc explaining what he
felt init should and shouldn't encompass, and a lot of people used that
as a model. All of a sudden, people were trying runit and s6. Some used
something like RichFelker init plus daemontools to init. Systemd
created a tremendous itch for a daemontools-style init, and lots of
people learned enough to actually make that happen on their systems.

And yes, it all started when djb looked around at how people were
starting daemons, and said no way, Jose, I'm writing my own.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust


More information about the Ale mailing list