Stuff starting at boot largely has an ordering dependency because that daemons are not really all that clever.
NFS needs to wait for networking? Well, the NFS daemon should be able to block on netlink until a route to the server appears.
Why does ssh need to wait? Because in some cases resolv.conf isn't updated yet, or the address it wants to bind to doesn't exist yet. Fix that and the dependency goes away.
Hopefully upstart has a better dependency mechanism than just waiting for script X to finish. It should be things like 'run me after /var/run/ appears' or 'run me after eth0 appears' or 'run me after a route to x.x.x.x appears'. ie things that actually matter.
Posted Sep 7, 2009 10:26 UTC (Mon) by hppnq (guest, #14462)
[Link]
Therein lies the actual problem.
Not really. The problem is that the distribution's boot sequence logic is not as clever as some of the programs it is trying to start, or the kernel it is running. Dependencies will always be there: it will remain difficult to communicate with another host if that host cannot be reached. The boot sequence dependencies are special because both the events, as well as their ordering, in most cases, are known in advance. You can circumvent them with the existing init/init.d setup as well -- but it is probably a better idea to move to an infrastructure that is more event based and up-to-date.
(Where it matters, some programs have or should been clever enough to detect and solve dependency problems themselves -- IIRC for years it has been possible to bind() to a certain address while the interface is not there yet. This, however, has for obvious reasons never been perceived as the solution to the problem that a user may plug in to different networks, or forgets to plug in the network cable in time.)