From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 23:24:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45E021065670 for ; Sun, 18 Apr 2010 23:24:23 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas01p.mx.bigpond.com (nschwmtas01p.mx.bigpond.com [61.9.189.137]) by mx1.freebsd.org (Postfix) with ESMTP id C530A8FC08 for ; Sun, 18 Apr 2010 23:24:22 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas01p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100418232420.MRYO17427.nschwmtas01p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Sun, 18 Apr 2010 23:24:20 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20100418232420.SWGO2131.nschwotgx02p.mx.bigpond.com@duncan.reilly.home>; Sun, 18 Apr 2010 23:24:20 +0000 Date: Mon, 19 Apr 2010 09:24:20 +1000 From: Andrew Reilly To: Jeremy Chadwick Message-ID: <20100418232420.GA4620@duncan.reilly.home> References: <20100418213727.GA98129@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100418213727.GA98129@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Sun, 18 Apr 2010 23:24:20 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.4BCB94A4.00E6,ss=1,fgs=0 X-SIH-MSG-ID: rBA7GNP4TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rANv1RsM6kxD9EJhiGNGMkaa7kTY3Rs9mK Cc: freebsd-stable@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 23:24:23 -0000 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