From owner-freebsd-stable@FreeBSD.ORG Tue Oct 25 01:03:29 2011 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 9F77A106566B for ; Tue, 25 Oct 2011 01:03:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 4C60E8FC08 for ; Tue, 25 Oct 2011 01:03:28 +0000 (UTC) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta15.westchester.pa.mail.comcast.net with comcast id oory1h00316LCl05Fp3V7H; Tue, 25 Oct 2011 01:03:29 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta06.westchester.pa.mail.comcast.net with comcast id op3U1h01E1t3BNj3Sp3Uuz; Tue, 25 Oct 2011 01:03:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 43B19102C1A; Mon, 24 Oct 2011 18:03:27 -0700 (PDT) Date: Mon, 24 Oct 2011 18:03:27 -0700 From: Jeremy Chadwick To: Steven Hartland Message-ID: <20111025010327.GA75437@icarus.home.lan> References: <4EA5EBB5.3090101@quip.cz> <20111024232750.GA74032@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: ntpd couldn't resolve host name on system boot 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: Tue, 25 Oct 2011 01:03:29 -0000 On Tue, Oct 25, 2011 at 12:36:56AM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "Jeremy Chadwick" > > > >The problem is that the networking layer is not TRULY available by the > >time ntpd starts. This does have to do with NIC drivers, but the same > >behaviour can be seen on all NICs, including excellent ones like em(4). > > This is generally caused by links to high end switches e.g. cisco which > havent had their "server" ports configured with portfast or similar > settings. This creates quite a delay once link establishes before traffic > is passed and hence the issue. Correct. Folks using STP, RSTP, or LLDP are most likely to see this. However, in our environment we have all of these turned off on our ProCurve switches yet we still see a ~1 second period of time between when the kernel says "em0 is up" vs. when actual packets flow. My point is that even in bare-bones environments (consumer switches, etc.) it's likely that there will be a small period of time where layer 3 packets aren't actually working yet, despite layer 1 and (a portion of) layer 2 being done. > netwait is an excellent script which fixes this and other network dependency > issues, something we use as standard on all our machines now :) It's a hackish workaround for something that should be solved elsewhere, but solving it elsewhere has already been discussed at length in the past so I won't get into it here. (Simple version: we really need something like "svcs" for Solaris, or one of those service-wrapper daemons that Linux and other OSes use. But let's not discuss that here please) netwait's "design model" is very specific given people's needs; the original design worked fine on some machines (all of ours) but I started getting reports of problems from people using vlan(4) and bge(4), etc... so the way it works now is actually reliable for all current NICs and "weirder" environments. The one shortcoming of netwait is that it doesn't support waiting for multiple NICs. Some people have dual-homed environments where they really would like to wait for both, say, em0 and em1, to come up and be functional before any more scripts are started. I left that as a project for someone else, but it's something that should be added given its importance. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |