ntpd couldn't resolve host name on system boot

[doug]

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.