Rob Owens <row...@ptd.net> writes:
>> From: "Rainer Weikusat" <rainerweiku...@virginmedia.com>
>> Laurent Bercot <ska-de...@skarnet.org> writes:
>
>>> I'm talking normal use cases here, i.e. situations where the services
>>> *will* succeed. In those situations, it is better to start everything
>>> according to the dependency graph, because then you do *not* trigger
>>> failure paths, which is nicer.
>>
>> Or you do trigger 'failure paths' which may not be nice at all. Eg,
>> according to a Solaris depenency specification I saw at some time in the
>> past, sending local mails on a Solaris system won't be allowed before
>> LDAP has been started. But there's really no way to predict this because
>> 'starting program A before program B' does not mean 'program A will be
>> ready to serve program B by the time program wants to use its services'.
>
> Here is a real-world scenario that has caused me trouble over the years.
> I have a system that connects wirelessly to my local network. The system
> uses wicd to manage the network connections, and wicd starts at boot.
> This system is supposed to mount several NFS shares on boot, but it
> always fails -- even when using openrc (which is dependency-based) on
> Funtoo.
>
> The problem is that even though wicd has started, it takes several
> seconds (sometimes up to 30 seconds) to acquire an ip address.
There are two solutions to this:
- fix the NFS code such that it doesn't trip over its own feet
in such a case: Considering that this is "network programming"
it has to be able to cope with transient "network not
available" situations at any time. At least they can happen at
any time.
- use "a suitable callback mechanism" to kick "the NFS" in the
desired direction whenever some relevant aspect of "the
network status" changes
The second one is really just a better workaround as it can't cover all
situations.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
