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

Steve Litt slitt at troubleshooters.com
Fri Jan 16 07:09:57 PST 2015


On Fri, 16 Jan 2015 00:24:51 -0800
Rick Moen <rick at svlug.org> wrote:

> 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.
> 
> I've made the same observation to people describing the problem to me,
> except I tend to say 'never in 20 years' instead of just 10.  ;->
> The several times I had that conversation with people much more
> versed in dynamic kernel event-handling than I, usually on Don
> Marti's linux-elitists mailing list, were frustrating because my
> interlocutors seem to have concluded I was just being contrary in
> saying 'What problem?'
> 
> 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.
> 
> Come to think of it, it's quite possible that one of the things that's
> prevented me from seeing it is udev.  One sees things like this in
> /etc/udev/rules.d/70-persistent-net.rules, obviously intended to
> ensure that a specified MAC address always ends up as eth0:
> 
> # PCI device 0x8086:0x100e (e1000)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="08:00:27:aa:b2:05", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> 
> I.e., among other consequences, my thoughts of adopting a
> 'static /dev was never broken' stance may have been unrealistic.  Not
> sure yet, but am leaning that way.
> 
> > If all this kernel event stuff is that indeterminate, we have bigger
> > fish to fry, because the initramfs does a lot of stuff long before
> > it knows whether /sbin/init is Epoch, runit, systemd, or /bin/bash.
> 
> It's my understanding that this is precisely why initramfs has a
> built-in hook to execute /sbin/hotplug from the RAMdisk immediately,
> to pick up relevant kernel events for, in particular, loading
> firmware images necessary to iniitalising network interfaces.  
> 
> Anyway, like you I'm a bit at a loss to produce indeterminate bootup
> sequences -- at least, in Linux systems that comply with my
> prejudices, e.g., avoiding that silliness of mounting /home from a
> USB drive -- so I cannot say 'Here, look at this [link] session data
> that proves that an event-driven handler is required for at least the
> early phase of init'. However, reading the 2011-2012 technical
> discussions from before the subject devolved into verbal warfare, I
> see broad consensus that such is the case, FWIW.

I think the 2011-2012 guys were discussing edge cases, not stuff the
vast majority is likely to have a problem with. I've continuously been
a member of a LUG since November 1998, and I don't remember having
somebody come up to me with the kind of symptom we've been discussing,
except that more than a decade ago, you were supposed to not put two
identical NICs in your machine so that your NICs were determinate, but
that was a decade or more ago. It's almost like you'd need to contrive
it to make one of these edge case problems happen.

Of course, rarity of the condition doesn't mean we should throw up our
hands and say "wontfix". But what it does mean is we should fix it with
a scalpal and jeweler's screwdriver, not with a machete and jackhammer
(or a marching band).

Another way I look at it is that this event based stuff is a little
like having a $100/month insurance against getting struck by lightning
while traveling by unicycle.

Anyway, I have more information:

http://forums.gentoo.org/viewtopic-t-994548-postdays-0-postorder-asc-start-25.html#7581522

This entry was written by Laurent Bercot, AKA scarnet, developer of the
S6 init system. I don't understand everything he says in this entry,
it's well above my paygrade, but one thing I take away from it is that
this Socket Activation thing is not "Fire off the service when the
kernel says it's OK", and that Poettering's "socket activation" carries
a lot of baggage, and works best with services *specifically
engineered* to work with it (why am I not surprised?).

SteveT

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




More information about the svlug mailing list