From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 23:38:00 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 D6E421065670 for ; Sun, 18 Apr 2010 23:38:00 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF5F8FC1A for ; Sun, 18 Apr 2010 23:38:00 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1386449qwi.7 for ; Sun, 18 Apr 2010 16:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CJNqBHvT6PThDnnJnxC9xWMbkNY93IVq95vPvVC5EAY=; b=W86O7H+AM2aPiqA159y+xyyhJp24b1K6gl0yMUJdBlnHfSaOlX8YO1x7OXiAuAHlZh edq/fuu8cqOFF5qWuoSOGCYnlFaaurS7zpY+ZKZMk7VUZCOyNJD5vJcsXFytyT4/3pqb sd/Ah01c/ytKXFLtlfgOBkjM6B6INMyppMy7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uL0tygryadYSIDpH/U/YG1MLmwyOUqSMb+1FDAsLAK2qd1YMQRgZkTdMeLx9egKmRe oMgUEw+FSPcGQg/iFM/8dVOWoVQT8JWy+XNH3AYa900KBXHire786WpYULiNb7UdbQ1U +l4RKYOdxVRED7qwi40b/GPl0Fgs5ryvtrIwE= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Sun, 18 Apr 2010 16:37:59 -0700 (PDT) In-Reply-To: <20100418232420.GA4620@duncan.reilly.home> References: <20100418213727.GA98129@icarus.home.lan> <20100418232420.GA4620@duncan.reilly.home> Date: Sun, 18 Apr 2010 16:37:59 -0700 Received: by 10.229.248.211 with SMTP id mh19mr4827839qcb.104.1271633879660; Sun, 18 Apr 2010 16:37:59 -0700 (PDT) Message-ID: From: Garrett Cooper To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sun, 18 Apr 2010 23:38:01 -0000 On Sun, Apr 18, 2010 at 4:24 PM, Andrew Reilly wro= te: > 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. =A0:-) >> >> >> HISTORY >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> 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. =A0The daem= on >> 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. =A0In 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. =A0The 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. =A0Consider 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. =A0The "get it right at > boot time" model is important and traditional, but (I think) > a fragile and diminishing fraction of use cases. =A0Our rc-ng > framework favours solution (a). =A0I'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 agree with Andrew. This is the model that Mac has been on for a while now with launchd and this is the way that we should be migrating towards (IMO) as it does a better job at detecting asynchronous system events and could improve the overall init / rc model used in FreeBSD. What ever happened to this work: http://wiki.freebsd.org/launchd ? I remember that Apple went in a more OSX centric set of APIs in Leopard+, but it might be worthwhile to start with the older version of launchd, and migrate from there. Thanks, -Garrett