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

Steve Litt slitt at troubleshooters.com
Sat Jan 17 14:26:52 PST 2015

On Sat, 17 Jan 2015 11:04:46 -0700
Akkana Peck <akkana at shallowsky.com> wrote:

> Rick Moen writes:
> > Steve Litt wrote:
> > 
> > > You have me at a disadvantage because I don't think I've ever
> > > seen a system boot indeterminately, or at least not in the last
> > > 10 years. I've never seen eth0 and eth1 switch, and the machine
> > > I've been doing all this testing on has both.
> > 
> > Anyway, truth to tell, I'm likewise at a disadvantage in attempting
> > to intelligently discuss this problem, being both late to the party
> > and having through either luck or careful avoidance of problem
> > scenarios not seen the referenced problems.
> Things may have changed -- this is based on problems I used to hit
> five or so years ago -- but here are two cases that used to cause
> indeterminacy:
> 1. Boot with two or more USB disks plugged in. Then add /etc/fstab
> entries that try to mount partitions on those disks using /dev/sdb1,
> /dev/sdc2 etc. 

> rather than using SSIDs or labels. 


> Sometimes it'll
> work, sometimes you'll get something entirely wrong.
> 2. Multiple network cards. For instance, try booting a laptop that
> has built-in wi-fi but also a USB wi-fi dongle; 

This is a fairly unusual use case. It's by no means contrived, I've
done it to get wired Ethernet on a box with Broadcom wifi, but it's

Anyway, given that it's a laptop and not a server 200 miles from home,
I'd boot it without the USB, and plug in the USB after it's all booted
up. Inconvenient? Minorly. A showstopper? Probably not.

> or try plugging in
> two different USB wi-fi dongles. 

Are the two the same, or different chipsets?

> But -- here's the kicker -- first
> remove the udev entries that most modern distros add as workarounds
> to get around the indeterminacy. For instance, on Debian, remove
> both of these files:
> /etc/udev/rules.d/70-persistent-net.rules
> /lib/udev/rules.d/75-persistent-net-generator.rules 
> Those persistent net rules are merely workarounds, and cause other
> problems. If you add a new network card, your old connections may
> stop working because they're all set up to use wlan0 and now your
> network interface is named wlan1.

If this were a problem for me, I'm sure I could solve it in a day or
two, waaaaay outside of the kernel, initramfs, or the init system.
Probably a shellscript with a bunch of ip commands, and maybe a little
wpa_supplicant and wpa_cli and iwlist stuff.

> Now, a new init system isn't the only, or necessarily the best, fix
> for these problems; but at least they're relatively common situations
> (which I've hit myself, and had to figure out how to fix) where an
> ordinary user can get race conditions at boot time. I'm sure there
> are other, thornier problems where a dependency-based init really is
> the best fix.

By dependency based, did you mean event based? Because all the
daemontools-inspired inits can do process dependencies with three lines
of shellscript. And even Epoch and sysvinit handle process
dependencies, albeit via consecutive instantiation rather than

As far as event-driven inits, I'm sure they offer some help in calming
the indeterminancies, especially with conveniences like Gnome,
always-connected USB drives, multiple network cards, and the like. So
sometimes they're the way to go.

It's a cost-benefit thing. Is the convenience of not having to wait til
boot's complete to plug in your thumb drive or USB NIC dongle worth the
complexity and DIY complication of a more complex init? That's a
decision we each need to make.

Is the "just works" factor bestowed by a systemd tamed by hundreds of
person-hours weekly, again with complexity and DIY complications,
better than doing stuff like mknod and loading your own drivers? Again,
that's a decision we each need to make.

Would a longer boot be a good trade for a simpler and more modular
and DIY friendly system? We each need to make that choice.

Is our computer an appliance, or a configurable tool we want to
control? Our choice.

Is pretty, transparency, and drag and drop worth a decrease in
DIYability? Our choice.

NOTE TO AKKANA: From this point down, anything I say about pro-event
arguments and the people who make them do not apply to you. What I say
is more about systemd sycophants like Lennart Poettering and his

We each make our choice. What bothers me is the propaganda I've seen
saying we have no choice: They say it's systemd or else you have an
unbootable, indeterminate, two minute boot doorstop. And they trot
out, if not edge cases, at least unusual cases to make their point.
Fine, let the unusual cases use systemd if they can't DIY their way out
of the problem, but don't tell normal users that the kernel's
construction now requires a systemd like init: For normal users, it
doesn't, and when they say otherwise, it's ingenuous, and tanks their


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

More information about the svlug mailing list