On Sat, 4 Jun 2016 22:06:47 +0100
Simon Hobson <linux@???> wrote:

> Steve Litt <slitt@???> 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 ?

With daemontools-inspired process supervisors, you'd just bake those
things into the if statement. When I say "you", ultimately I mean the
admin, because, as you say below:

> 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 ultimately, the definition of "sufficient" rests with the admin,
because, as you mention, either the distro nor the "upstream" knows
about the admin's exact use case.

> 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.

Yes. That's pretty much what daemontools-inspired process supervisors
do. It sounded to me like it would be a football field of ping pong
balls mounted on mousetraps, and might take 10 minutes of trial and
error to get everything up, but in fact that didn't turn out to be the
case.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb