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. Cheers, -- Andrew _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
