Re: non-event-based init systems are unfixable [Was: Re: RFC: OpenRC as Init System for Debian]

[Patrick Lauer <patrick@gentoo.org>]

On 04/30/12 02:09, Steve Langasek wrote:
> On Sun, Apr 29, 2012 at 03:59:03PM +0200, Stephan Seitz wrote:
>> On Sun, Apr 29, 2012 at 10:33:16PM +0900, Miles Bader wrote:
>>> Isn't mounting filesystems, which can depend on the network, part of
>>> the boot process?
>> Yes, but how do you check if the network is configured and operational?
>> - when the link is up?
>> - when the IP address is configured (how do you check this with
>> IPv6?)?    What are you doing if more than one IP address is
>> configured for this   NIC or more than one NIC is available?
>> - when the switch accepts traffic on the port you are connected to?
>> - when the router/firewall accepts traffic from your IP address?
> Retransmitting your packets because the network is not yet delivering them
> is an entirely different error handling scenario from rebinding because your
> service was started before the system has an address (or interface).  The
> former is handled transparently by the protocol stack and the latter
> requires every application to handle it manually - and the only way the
> application can handle it is by stupid polling.
This becomes quite esoteric and theoretical.

The usual conventions are "when you have an IP that interface is up" or,
if you have something really funky, maybe "when you can send ICMP and
get a reply the interface is up". All those corner cases need specific
checks added for that specific deviation from what we call "standard"
either way.

It's not easily fixable in the general case.
>
> Linux is an event-based system, and we need to do event-based activation of
> the software, so that we don't have to patch a hundred processes to poll for
> the network to show up underneath them.
What a confusing idea.

If your init scripts had dependencies (I know, a radical new idea that
won't work anyway) it'd be trivial to not start foo until bar reports to
be started. And bar could make that is-started-check as elaborate and
complex as you want ...

>
> The fact that v6 addresses may come and go without generating events seen by
> userspace is a deficiency with the current system; but a) it's a solvable
> one, b) having reliable events for all the *other* scenarios is a huge
> reliability improvement over the sysvinit status quo.
>
> For some insight into how upstart structures its events to ensure reliable
> start of network services on boot, see the Upstart Cookbook:
>
>   http://upstart.ubuntu.com/cookbook/
>
>> No event based init system will solve these problems when you have
>> dependencies outside the box you are booting. The local admin has to
>> check if all timings are right and must adjust them if they are not
>> fitting.
> IOW, "the admin has to add a bunch of sleep's everywhere"?  Pass, thanks.
>
Old-skool. Haven't seen that style in a while, I thought it had died out
in the last decade.

Maybe you should spend some more time with these newfangled gizmos and
thingamajigs before claiming they are ugly and don't work anyway?

Take care,

Patrick