Date: Sun, 18 Apr 2010 16:37:59 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Andrew Reilly <areilly@bigpond.net.au> Cc: freebsd-stable@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: rc(8) script -- waiting for the network to become usable Message-ID: <n2w7d6fde3d1004181637h17e1f717p823dfd9b872efe33@mail.gmail.com> In-Reply-To: <20100418232420.GA4620@duncan.reilly.home> References: <20100418213727.GA98129@icarus.home.lan> <20100418232420.GA4620@duncan.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 18, 2010 at 4:24 PM, Andrew Reilly <areilly@bigpond.net.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n2w7d6fde3d1004181637h17e1f717p823dfd9b872efe33>