From owner-freebsd-stable@FreeBSD.ORG Tue Oct 25 17:04:07 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 C8EBD106566C for ; Tue, 25 Oct 2011 17:04:07 +0000 (UTC) (envelope-from doug@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by mx1.freebsd.org (Postfix) with ESMTP id 874608FC15 for ; Tue, 25 Oct 2011 17:04:07 +0000 (UTC) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p9PH46EU015901 for ; Tue, 25 Oct 2011 13:04:06 -0400 (EDT) (envelope-from doug@fledge.watson.org) Received: from localhost (doug@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p9PH46S1015896 for ; Tue, 25 Oct 2011 13:04:06 -0400 (EDT) (envelope-from doug@fledge.watson.org) Date: Tue, 25 Oct 2011 13:04:06 -0400 (EDT) From: doug To: freebsd-stable@freebsd.org In-Reply-To: <4EA6CF88.3050600@quip.cz> Message-ID: References: <4EA5EBB5.3090101@quip.cz> <20111024232750.GA74032@icarus.home.lan> <20111025010327.GA75437@icarus.home.lan> <20111025092012.GA41065@psconsult.nl> <20111025125108.GA87567@icarus.home.lan> <20111025134159.GA96607@psconsult.nl> <4EA6CF88.3050600@quip.cz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 25 Oct 2011 13:04:06 -0400 (EDT) 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 Reply-To: doug@safeport.com 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 17:04:08 -0000 On Tue, 25 Oct 2011, Miroslav Lachman wrote: > Paul Schenkeveld wrote: >> On Tue, Oct 25, 2011 at 05:51:08AM -0700, Jeremy Chadwick wrote: >>> On Tue, Oct 25, 2011 at 11:20:12AM +0200, Paul Schenkeveld wrote: >>>> On Mon, Oct 24, 2011 at 06:03:27PM -0700, Jeremy Chadwick wrote: >>>>> 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. >>>> >>>> How would you like to see multiple interfaces implemented: >>>> >>>> - All interfaces must be up at the same time >>>> - Probe interfaces one by one, proceed to the next when an interface >>>> up or bail out when any interface stays down until the loop times >>>> out >>> >>> 1) Each interface should be checked in the order specified. >>> 2) Each ping probe should be done using that interface (ping -I). >> >>> From ping(8): >> >> -I iface >> Source multicast packets with the given interface address. This >> flag only applies if the ping destination is a multicast address. >> >> I believe that for unicast the interface used is determined by looking >> up the destination address in the routing table (unless overridden by a >> packet filter that changes the next hop). Another way to influence the >> next hop selection and the outgoing interface is using setfib(1) but >> apart from rc.d/jail I see no fib support in rc.conf at all. > > OT: > Unfortunately there are two PRs with patches to add setfib support to > rc.subr, but both of them are laying under the dust without attention of > committers. > conf/132483 conf/132851 > > I tried to bring it to attention in freebsd-rc@ without any luck. (same as my > attempt to add support for cpuset conf/142434). So we have features / tools > without centralized support in rc.subr and if anybody want to use them, must > do it by some hacky ways in rc.local etc. > http://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001816.html > I have not done any debugging, but it seems to me this may be a serialization issue. For me it almost always occurs on MP systems. I have an 8-cpu system that never starts NTP correctly, a 2-cpu laptop that mostly never does. I have never experienced this with a single processor system. My fix is simply to pick a number of geographically close open NTP servers.