[svlug] Inits (was: On the process of picking up systemd)

Rick Moen rick at svlug.org
Sun Jan 4 04:52:04 PST 2015

Steve Litt wrote:

> Almost everyone was forced. Only some, and they tended to be the kind
> who would use Slack, Gentoo, etc, minded being forced.

I think this is somewhere between ahistorical and missing some very critical

Recapping what I said not long ago in this space, during a multiyear period
when some of us (or at least me, speaking for myself) weren't paying a lot
of attention, Linux-based systems of all kinds started generating important
yet asynchronous system actions.  There were a number of separate causes for
this, including some heroic kernel work that finally eliminated the
much-dislike big spinlock code.  Also, a lot of work went into adding
hotplug support, which involved generation of 'uevents', and management of
those events through the new /sys abstract filesystem -- events that then 
typically got picked up by (the new) udevd, and where /sys got accessed by
(the new) library libudev.

Tutorial:  http://www.signal11.us/oss/udev/

I posted a link to that pivotal 2009 recap ('The future of the boot system
in Debian') of the resulting deteriorating situation for old-school
dependency-based code that was sent to debian-devel-announce by the three
maintainers of Debian's SysVInit code.  It's very instructive, and you
(Steve) should read it.  That link again:

In short:  Standard code for booting Linux systems after mounting of the
root FS was starting to break in alarming ways because the timing of device
availability and even of /dev entries had become impossible to plan for in
regular procedural code, such that failure of service startup (or shutdown) 
sometimes ensued - unpredictably.  This was a serious problem.

The three Debian maintainers judged that the only reasonable way out was for
/sbin/init to become an event-driven handler of some kind, as (in their
view) regular procedural code of any sort, irrespective of even very
scrupulous dependency checking, wasn't doing the job.  

You might say that _many_ systems (especially servers) remained determinate
in their startup events, and you would be right, but the maintainers did
have a point.  After a bit of research before posting this resposne, I've
found only five event-based candidates:

o  Upstart:  Original coder Scott James Remnant and also commenters on
LWN.net have shown quite a few serious problems in this codebase.  (That's
not to mention the cutesy Canonical Contributor Licence Agreement.)

o  systemd

o  SMF:  This is Solaris's init, these days, and is a bit gruesome
(take the word of someone who's had to work with the damned thing).

o  launchd:  Apple OS X and Apple Darwin's init.  As gruesome as SMF
and a lot worse documentation, and XML orientation that will make you

o  OpenRC (originally native to _two_ distributions, Gentoo and Funtoo -
sorry, Ivan)

At the time that distros were pondering these issues, Linux distros in
general had implementations only of the first two.  OpenRC packages 
were showing up as experimental entries in many distros, and have only 
now, about four years after the crisis hit, started to become reasonable
options.  So, for practical purposes, the only two event-driven inits
were Upstart and systemd.

Anyway, 'forced'?  I think a more sober look will suggest that the problem 
being addressed was real, except that it becomes minor-to-nonexistent on 
the minority of systems whose administrators don't give a damn about
hotplug device-handling, don't trust the code for that, and would rather it
went away.  I _happen_ to be one such person, but distros in general feel
obliged to accomodate systems where hotplugging is deemed to be A Good Thing
and matters.

I _do_ agree with the author of useelssd, on the previously referenced page
where he forlornly tries to warn people against stupid and useless advocacy
rhetoric, that the reasons for systemd's wide adoption have been a mixture
of the technical and the political, contrary to the claims of both critics
and proponents.  The political include, of course, the policy of
tight-coupled dependencies between layers reaching up and down the stack,
and distros bending to the apparent requirement of an init that gives GNOME
logind the 'services' it requires, with only systemd-logind and (the
unmaintained and imperiled) ConsoleKit, which can be seen as opportunism
at work.

In short, the truth is, as usual, much less dramatic than 'forcing' and
'conspiracy'.  People making decisions at distros made a judgement call
that's understandable given their constraints and the problems they felt
they had to address -- and they effectively had only two qualifying options
according to the criteria they applied, one of which was somewhat broken 
and suffered from the noxious CLA problem I alluded to.

Impugning the motives of the people who made those decisions is
unconstructive and merely adds to the noise bountifully heaped onto this
matter by commentators anyway, hardly anyone of whom - you excluded - 
have much understanding of even what an init is, let alone what the
situation was.

More information about the svlug mailing list