From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 20:38:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A63EF1065687 for ; Tue, 31 Mar 2009 20:38:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 3F94C8FC0C for ; Tue, 31 Mar 2009 20:38:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 10278 invoked by uid 399); 31 Mar 2009 20:38:52 -0000 Received: from localhost (HELO 192-168-15-100.nohostname) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Mar 2009 20:38:52 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D277B5.5040205@FreeBSD.org> Date: Tue, 31 Mar 2009 13:06:13 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Poul-Henning Kamp References: <96526.1238484035@critter.freebsd.dk> In-Reply-To: <96526.1238484035@critter.freebsd.dk> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 20:38:56 -0000 Poul-Henning Kamp wrote: > In message <49D1B261.6010406@FreeBSD.org>, Doug Barton writes: > >> There has been some discussion recently about the idea of adding an >> option for the rc.d startup process to wait until name resolution >> comes on line. (There is also room for a more general "wait for the >> network to come on line" option, but I chose to focus on the named >> version since my time is limited atm.) > > Maybe we need to do a more general mechanism, since many also > would like us to have confirmed the wall-clock-time via NTP before > we start anything that depends on it ? I am not opposed to that, I just don't have time to work on it. Doug -- This .signature sanitized for your protection