----- Original Message ----- > From: "Rainer Weikusat" <[email protected]> > Laurent Bercot <[email protected]> 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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
