----- Original Message -----
> 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. In the
meantime, NFS mounts are attempted and fail. I have "solved" this so
far in a couple ways. One way is to issue a sleep statement before
mounting the NFS shares. Another way, which can be seen at the
following link, is to create a 'pingtest' service and make my NFS
mounting script wait for that to succeed.
https://bugs.funtoo.org/browse/FL-2644

I appreciate the assertion that NFS should handle this situation better.
Note that the "bg" option seems like it should handle this situation,
but my experience says it does not. I also appreciate the assertion
that this can be addressed by the init system. In any case, I'm
mentioning it here so that anybody looking to make a better init can
consider this use case.

-Rob