[svlug] Inits (was: On the process of picking up systemd)
rick at svlug.org
Thu Jan 15 20:52:52 PST 2015
Steve Litt wrote:
> That 95% will be perfectly happy with systemd. For those of us who
> aren't, there are plenty of reasonable alternatives.
I hope you won't be offended at my saying this, but I'm a little
disappointed at seeing _no engagement with the point I raised_ about what we
agree is (borrowing your well-phrased characterisation) 'the kernel's
increasingly event-driven nature'.
To review: Up until about four years ago, everyone on Linux was relatively
happy with sequential-code init systems, particularly those that included
dependency checking - including but not limited to SysVInit, runit, BSD
init, nosh, s6, and the like.
What I, probably you, and almost everyone else other than a few specialists
was late to realise is the excalating problems (spiking in prominence
starting around the beginning of this decade) caused by kernel behaviour
becoming variable over time and across reboots, hardware status becoming
more dynamic, and all of these state changes being tracked by kernel
'uevent' data accessible via the netlink socket and userspace hotplug
Even though I, and perhaps also you, prefer to use no hotplug code (and to
avoid problem-causing scenarios like mounting /home from an external USB
drive), the problem remains: Some very intelligent and experienced people
have advised me that the dynamic nature of kernel events can now be ignored
only at one's peril, and that event-handling code is necessary or else one
day I'll find that eth0 and eth1 have swapped on reboot for mysterious
reasons, or worse things will happen.
The point is: Are they right, or are they wrong?
Everything I've been reading from relevant technical sources, as I catch up
on this subject, suggests they're right. Which then would mean that
SysVInit, runit, BSD init (on Linux), nosh, s6, and the like are _not_ quite
sufficient even to reliably boot systems with all hardware initialised and
services requiring that software running.
Here's a 2012 posting by one of those people who really can speak
authoritatively on the subject: Petter Reinholdtsen, one of the maintainers
of Debian's SysVInit. Note his comment that _only_ the early portion of
init, in which hardware and filesystems gets set up, needs to handled by
event-based code. Which is a logical alternative to recent approaches that
to my knowledge has not yet been explored.
I'm going to quote Reinholdtsen's full text, as I think he's spot-on:
To: debian-devel at lists.debian.org
Subject: Re: upstart: please update to latest upstream version
From: Petter Reinholdtsen <pere at hungry.com>
Date: Fri, 24 Feb 2012 13:49:34 +0100
Bernhard R. Link wrote:
> Currently we have a system where every user has a chance to debug
> and fix those problems and make their system work again.
I just wanted to give a small comment on this, as one of the sysvinit
package maintainers in Debian. The quoted text give the impression
that the current init.d based boot system is working fine, and that is
not quite how I see it.
The current sysvinit boot system is not working properly on Linux.
And it has broken in new and interesting ways the last few years,
thanks to the fact that the linux kernel developers have removed the
big kernel lock, causing the kernel to become more event based and
less sequential during boot.
These problems lead to boot failures when some kind of hardware is
used (think disks and network cards, but it can happen with any
hardware), because it is not possible for the current dependency based
boot system to know when some hardware device is available during
boot. A well known case is having the user home directory on an
external USB disk, only to discover that the disk device node isn't
available when file systems are mounted during boot. There are other
To solve this problem the early boot (note only the early boot _need_
this) need to become event based, and once the file systems, network
interfaces etc are set up, the later boot can work using simple init.d
I do not know the proper solution to this for Debian, but both upstart
and systemd seem to provide a working solution with different costs
and advantages. Personally I hope kFreeBSD and Hurd will get the
required features used by upstart and systemd, to at least make it
possible to use these systems on all the architectures handled by
Or perhaps we should just teach sysvinit to handle kernel events and
thus make it capable of solving the problem of the event based kernel
internally. No-one so far have volunteered to look at this approach,
and I have no plans to do so myself, but I am sure it would be
possible to integrate the nice features of upstart and systemd into
More information about the svlug