rc(8) script -- waiting for the network to become usable

[Daniel Braniss]

> On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote:
> > I'd like to discuss the possibility of introduction of a new script into
> > /etc/rc.d base system a script, which when enabled, would provide a way
> > to wait until the IP networking layer (using ping(8)) is up and usable
> > before continuing with daemon startup.
> > 
> > Let's discuss.  :-)
> > 
> > 
> > HISTORY
> > =========
> > The situation which brought this debacle to my attention:
> > 
> > I found that on reboot of some of our systems, ntpdate (used to sync the
> > clock initially before ntpd would be started) wouldn't work.  The daemon
> > would report that it couldn't resolve any of the FQDNs within ntp.conf,
> > and would therefore act as a no-op before continuing on.
> 
> By way of discussion, I'd just like to re-iterate what I
> said the first time around: it must be understood that this
> sort of thing is a (necessary) hacky-workaround that should
> ultimately be unnecessary.  In preference, we should work on
> the failing daemons or hassle up-stream daemon authors so
> that the daemons in question either (a) retry until they *do*
> get the information they're after or (b) fail properly, so
> that they can be restarted by an external process monitoring
> framework like sysutils/daemontools or launchd.  The reasoning
> is simple: network outage is something that can happen even
> after startup, and when network connectivity returns, the
> routing and addresses that are visible won't necessarily be the
> same.  Consider laptops that suspend, as a particular example.
> Or mobile devices that switch from wi-fi to cellular networking
> to no connectivity on a regular basis.  The "get it right at
> boot time" model is important and traditional, but (I think)
> a fragile and diminishing fraction of use cases.  Our rc-ng
> framework favours solution (a).  I'm more a fan of approach (b),
> myself: I use daemontools for many services, and I like the way
> that launchd works on my Mac laptops.

I think that rc is being overloaded yet again(*), and a launchDaemon
kind of solution should be followed, maybe even as a replacement for
inetd?
/blah
(*): in the begining rc would do everything, but life was simple - no internet,
then it got complicated, too many daemons, so inetd was invented, things
were back in control, for a while. Then sysv invented init.d/init levels, then
rc-ng came along, though it solves many problems, 1) the order of things,
2) easy to configure services, it's getting complicated to get 1 'correctly'.
blah/

danny