Rob Owens <rowens@???> writes:
>> From: "Rainer Weikusat" <rainerweikusat@???>
>> Laurent Bercot <ska-devel@???> 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.