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

Rick Moen rick at svlug.org
Sat Jan 3 17:27:42 PST 2015


Julius Caesar didn't have it quite right.  Gall isn't divided into just
Cisalpine Gall, Transalpine Gall, and Latin Gall[1]:  There's also the Gall of
Ivan, which we observe by Ivan Sergio Borgonovo going out of his way to hurl
at me personally a lot of insulting talk about conspiracy theories, and then
having the unmitigated gall to accuse _me_ of gratuitously personalising th
discussion when I am irritated by him pulling that nonsense gutter rhetoric.

Oh well.  Want to see how one rises about stupid soap opera (including the 
passive-aggressive bit where Ivan accuses me of shouting everyone down 
because I ignored the mailing list completely for several days and then
answered four technical queries everyone else blew off)?  Watch, here's
one way to do it.


Part of the origin of the recent squabble over inits arises from the
gradually increasing intrusion of event-based code in both the Linux kernel
and many other ancillary codebases over the last decade, a trend accelerated
by the recent elimination of the kernel's big spinlock code.  One warning of
the problems created by this trend was delivered in 2009 by the
co-maintainers of Debian's SysVInit subsystem, Petter Reinholdtsen, Kel
Modderman, Armin Berres, and is readable here:
https://lists.debian.org/debian-devel-announce/2009/09/msg00003.html

  Over the last few years, the boot system in Debian has progressively
  deteriorated due to changes in the Linux kernel which make the kernel
  more and more event based. For example, the kernel and its drivers no
  longer block all processing while detecting disks, network interfaces
  and other hardware, making the once trusty old boot system in Debian
  increasingly fragile. During the current boot sequence device files in
  /dev/ are often missing when fsck or mount are looking for them, or
  the network is not available when the boot system tries to mount NFS
  entries because network interfaces were slow to initialise, or audio
  devices are missing when audio settings should be set. The problem is
  fundamental to the way we boot Debian today - sequentially, and a
  solution needs to address this fundamental problem. We believe the
  solution is to migrate to an event based boot system.  
  [...]

(These are not Poeterringware groupies, but rather SysVInit specialists, who
know whereof they speak.)

Being a pragmatist at heart, I have to consider the likelihood that they're
very right, at least as to typical _desktop_ users (albeit not in server
contexts that are almost all I really care about).  They definitely are
describing a problem that is real in many usage scenarios, and this is one
of the reasons why inits are a matter under scrutiny at all.

As both Marc and I have stressed, one of the drawbacks of any event-driven
code including inits is debugging, which suddenly becomes greatly more
difficult and the code's behaviour markedly more non-deterministic.  But
there is a genuine need.

One of the interesting paths forward is an event-driven init of sane design,
that does its work _without_ needing to be PID 1, and can be adapted to
manage cgroups if that is desired:  OpenRC.  Jake Edge's article for LWN.net
about Debian's ongoing adaptation of OpenRC is very insightfu:
https://lwn.net/Articles/512719/

One of the interesting things about Debian's OpenRC packaging is that it
provides a way to handle dynamic system events (hotplugging of mass storage,
changing of network interfaces, addition and removal of various other USB
devices) much more sanely than at present, without needing to dictate choice
of init, as it doesn't monopolise PID 1 and leaves the admin able to pick
best of breed for any init, any service supervisor, etc.


[1] It's a silly pun, but works better out loud, I fear.  (If Western-Civ
challenged and not getting the joke, look up 'Omnia Gallia in tres partes
divisa esta.')



More information about the svlug mailing list