From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 06:49:26 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 CA239106564A for ; Mon, 19 Apr 2010 06:49:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 7C96B8FC1B for ; Mon, 19 Apr 2010 06:49:26 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1O3knM-000MaT-3E; Mon, 19 Apr 2010 09:49:24 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Andrew Reilly In-reply-to: <20100418232420.GA4620@duncan.reilly.home> References: <20100418213727.GA98129@icarus.home.lan> <20100418232420.GA4620@duncan.reilly.home> Comments: In-reply-to Andrew Reilly message dated "Mon, 19 Apr 2010 09:24:20 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Apr 2010 09:49:24 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, Jeremy Chadwick 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: Mon, 19 Apr 2010 06:49:26 -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. 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