On 04/27/12 08:02, Russ Allbery wrote:
> Petter Reinholdtsen <p...@hungry.com> writes:
>
>> Say you want to mount a network disk during boot. This depend on the
>> network being configured. This in turn might depend on a DHCP reply
>> from a DHCP server, and to send the DHCP request the network card need
>> to be detected. To detect the network card, the network driver need to
>> be loaded, and the network card need to be found on the PCI or some
>> other internal bus. And with the Linux kernel today, there is no way to
>> know when during boot the network card will be found on the bus. To
>> make this work reliably, the boot system need to be event based, not
>> sequence based.
I disagree. If you have stateful init scripts you just wait until the
needed event arrives / statechange happens, *then* mark it as started.
And during that time you let the init script handler run in a loop that
polls, say, every second if the other init script declares itself started.
>
> And lest someone think this is a theoretical exercise, we *frequently* get
> bugs filed against packages like OpenAFS, the Kerberos KDCs, or OpenLDAP
> that are boot-order-dependent and network-dependent and either don't start
> or start in unuseful ways or at unuseful times because of lack of event
> notification for when interfaces are *actually* ready or when network
> devices are *really* available.
That looks like a lack of design to me - and random timeouts are
dangerous. It might work on a lightly loaded machine, most of the time.
It makes more sense to me to have meaningful return values :)
>
> These bugs are essentially unresolvable without something that understands
> kernel events
... udev/mdev/ /sys/kernel/uevent_helper to the rescue ...
> and can use them as input into boot dependency processing.
and now you're just reimagining OpenRC ;)
> This is why so many packages resort to adding "sleep" calls with random
> delays to their init scripts in the hope that everything will be ready
> after some arbitrary delay.
>
> The alternative is to add significantly additional complexity to every
> package like those listed above that needs the network to loop and retry
> if the network isn't available when it first starts. This is a huge waste
> of effort.
... or make the wrappers around init scripts smart enough, so you have
marginal complexity in one place.
Don't Repeat Yourself applies to init scripts too, there's no need to
have more than a #! line as boilerplate.
Just for fun, here's all the logic we need to get rsyncd started, *and*
it only starts once network is properly up (where the definition of "up"
is user-configurable as we often disagree on it):
#!/sbin/runscript
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/net-misc/rsync/files/rsyncd.init.d-r1,v 1.1
2012/03/22 22:01:21 idl0r Exp $
command="/usr/bin/rsync"
command_args="--daemon ${RSYNC_OPTS}"
pidfile="/var/run/${SVCNAME}.pid"
depend() {
use net
}
Because repeating yourself is tedious we have default functions now, so
no need for explicit start and stop - it just works.
Enjoy,
Patrick
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f99f18a.10...@gentoo.org
