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

Steve Litt slitt at troubleshooters.com
Sun Jan 4 08:56:43 PST 2015

On Sun, 4 Jan 2015 04:52:04 -0800
Rick Moen <rick at svlug.org> wrote:

> Tutorial:  http://www.signal11.us/oss/udev/
> https://lists.debian.org/debian-devel-announce/2009/09/msg00003.html
(I'll refer to the preceding link as "FUTURE" for the rest of this

> 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.

There are many, many ways to handle stuff like this. A cost-benefit
analysis must be applied. In my view, making init responsible for the
likes of hot-pluggable devices is a huge cost. A proof of concept
alternative I came up with after 20 minutes' consideration is:

inotifywait -m -e CREATE,DELETE /dev/usb

A little more plumbing and the preceding can mount plugged in thumb
drives. Or one can use the C language inotify library for a more
polished and professional look. Does this have costs? You bet it does.
But so does an event driven init.

The author of FUTURE seems not to be fully cognizent of non-event
possibilities. Consider this dependency method from runit:


Might it add a few seconds to the boot? Of course. Will it be simpler
than event actuation? Probably. Can use cases be found where this is
problematic? I'm sure, but I'm equally sure that fairly easy solutions
can be found to those problems.

The author of FUTURE rightly states that having upstream programmers
guess on the numeric order for their daemons is an undue burden and
error prone. But FUTURE doesn't contemplate the full field of
possibilities. For instance, each upstream programmer could list the
programs that must be running before his/her program can be launched,
and I could write a Python programmer to convert that information into
numeric ordering. Or it could be applied directly to runit scripts. The
shutdown process might be a little more problematic, but nothing that
a half dozen knowledgeable people couldn't solve in a couple days.

And then there's this: Other than listing the running programs and
setup their daemons depend on, why should upstreams be involved in
inits? Why doesn't the distro assign one init-expert person whose job is
to write the init scripts, unit files, run scripts, or epoch.conf
object entries to correctly start everything? It's not the upstream's
job, it never should have been. By the way, there's a guy named Avery
Payne who has done just this job for a huge number of daemons to be
initted by s6, runit, or daemontools:


Bottom line: Initting with an event based kernel can be done with an
event based init, or a non-event based init. The choice is a cost
benefit analysis.


Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

More information about the svlug mailing list