Steve Litt <sl...@troubleshooters.com> wrote: > In all daemontools-inspired process supervisors, dependency handling, > if you indeed need it, is just this easy: > > ============================================== > #!/bin/sh > if ping <should_be_pingable_address>; then > exec /path/to/app_depending_on_network > fi > sleep 1 > ============================================== > > In the preceding, if the ping succeeds, the run script is replaced by > app_depending_on_network. If the ping fails, after 1 second the run > script finishes, at which time or soon after, daemontools will try it > again.
There is an argument for doing everything that way. IIRC it was discussed in here, I know I've seen it discussed elsewhere, but there are inherent problems with the "classical" dependency model - namely that "ready" is often a nebulous thing, and may only be transient. A classic example of that is networking. When is "the network" ready ? When the first ethernet port is active ? When a WiFi port is active ? When a PPP link is up ? When you can actually ping "something on the internet" ? Something else ? In the general case, it's absolutely not possible for a generic supervisor, running a generic config, to know that for every combination of networking that people could come up with. And of course, what if an interface goes down ? So logically, anything that relies on "networking" being active should have (probably installation specific) checks to determine for itself when there is sufficient networking available. And of course there are (these days) very often dependencies outside of the host that's starting up - eg no point starting the mail service if the back end database it needs isn't available. So if every "something" was made responsible for working out when it's dependencies are met, startup sequencing becomes "fire up everything" and leave them to it. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
