From nobody@FreeBSD.org  Tue Mar 16 20:02:47 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 9D6F31065670
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 16 Mar 2010 20:02:47 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 8CF9E8FC0A
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 16 Mar 2010 20:02:47 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o2GK2la6096096
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 16 Mar 2010 20:02:47 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o2GK2l6f096095;
	Tue, 16 Mar 2010 20:02:47 GMT
	(envelope-from nobody)
Message-Id: <201003162002.o2GK2l6f096095@www.freebsd.org>
Date: Tue, 16 Mar 2010 20:02:47 GMT
From: andy wilson <wilson.andrew.j@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ntpd cannot resolve hostnames at system start
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         144804
>Category:       conf
>Synopsis:       ntpd(8) cannot resolve hostnames at system start
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 16 20:10:00 UTC 2010
>Closed-Date:    
>Last-Modified:  Sat May  4 20:20:00 UTC 2013
>Originator:     andy wilson
>Release:        8.0-RELEASE-p2
>Organization:
>Environment:
FreeBSD urania.tx.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #1: Wed Mar 10 13:27:38 CST 2010     root@urania.tx.net:/usr/obj/usr/src/sys/URANIA  i386
>Description:

Due to network initialization taking longer at system startup on 8.0, ntpd cannot resolve hostnames when it is run by /etc/rc.d/ntpd


It spits out some messages that look something like:

ntpd_initres[1469]: host name not found: time.nist.gov
ntpd_initres[1469]: couldn't resolve `time.nist.gov', giving up on it
ntpd_initres[1469]: host name not found: time-b.nist.gov
ntpd_initres[1469]: couldn't resolve `time-b.nist.gov', giving up on it
ntpd_initres[1469]: host name not found: time-c.timefreq.bldrdoc.gov
ntpd_initres[1469]: couldn't resolve `time-c.timefreq.bldrdoc.gov', giving up on it

In this state ntpd isn't very useful until it is restarted after the
network is ready to go.

# ntpq -p
No association ID's returned
# /etc/rc.d/ntpd restart
Stopping ntpd.
Starting ntpd.
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.nist.gov   .ACTS.           1 u    3   64    1   40.103  -20.364   0.004
 time-b.nist.gov .ACTS.           1 u    2   64    0    0.000    0.000   0.000
 time-C.timefreq .ACTS.           1 u    1   64    1   40.769  -20.209   0.004
 nist1.symmetric .ACTS.           1 u    1   64    1   67.883  -11.069   0.004
>How-To-Repeat:

Configure time servers by hostname in /etc/ntp.conf, set ntpd_enable="YES"
in rc.conf and reboot.
>Fix:


>Release-Note:
>Audit-Trail:

From: Garrett Cooper <yanefbsd@gmail.com>
To: andy wilson <wilson.andrew.j@gmail.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: conf/144804: ntpd cannot resolve hostnames at system start
Date: Tue, 16 Mar 2010 16:11:01 -0700

 Same thing applies to ntpdate, so if there are already some bugs in
 GNATS about that, this should be duped appropriately.
 -Garrett

From: Garrett Cooper <yanefbsd@gmail.com>
To: andy wilson <wilson.andrew.j@gmail.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: conf/144804: ntpd cannot resolve hostnames at system start
Date: Tue, 16 Mar 2010 16:22:42 -0700

     Something else to think about (for someone that may attempt to fix
 this bug) is that 1) ntpdate features a -q option for querying an ntpd
 server. 2. Would it be better to implement either a background and
 wait, or a limited query poll and update option if there's an
 equivalent to -q in ntpd (former would probably be preferred as it's
 simpler to implement and user tunable and I'm not sure whether or not
 -q exists in ntpd)?
 
 Thanks,
 -Garrett

From: Andrew Wilson <wilson.andrew.j@gmail.com>
To: =?KOI8-R?B?88HOxcsg59XSyc4=?= <agurin@mail.ru>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: conf/144804: ntpd cannot resolve hostnames at system start
Date: Thu, 18 Mar 2010 13:04:17 -0500

 The problem isn't limited to named; it occurs whether running named as
 a local resolver or setting a remote resolver in /etc/resolv.conf
 
 The problem in both cases is that network connectivity doesn't exist
 yet so name resolution fails when ntpd is started. The network
 interfaces are configured early on in the rc order, but it still takes
 about 20 seconds before packets can actually be sent (this quirk is
 new to FreeBSD 8). Any attempts to resolve hostnames before packets
 can be sent will fail. ntpd assumes that you have a working resolver
 when it is started.

Date: Thu, 18 Mar 2010 15:05:46 +0300
From: =?koi8-r?Q?=F3=C1=CE=C5=CB_=E7=D5=D2=C9=CE?= <agurin@mail.ru>
Reply-To: =?koi8-r?Q?=F3=C1=CE=C5=CB_=E7=D5=D2=C9=CE?= <agurin@mail.ru>
To: bug-followup@FreeBSD.org
Subject: Re: conf/144804: ntpd(8) cannot resolve hostnames at system start

 this bug occurs when your system configured to use a dns server on the
 same system. When a system is starting, the ntpd starts before the named.

From: =?utf-8?B?SsOBS8OTIEFuZHLDoXM=?= <jako.andras@eik.bme.hu>
To: bug-followup@FreeBSD.org, wilson.andrew.j@gmail.com
Cc:  
Subject: Re: conf/144804: ntpd(8) cannot resolve hostnames at system start
Date: Sat, 4 May 2013 22:18:54 +0200

 I have a very similar problem on 9-STABLE (built yesterday).
 
 Messages at boot:
 
 May  3 23:31:56 vpn-gw ntpd[715]: ntpd 4.2.4p5-a (1)
 May  3 23:31:56 vpn-gw ntpd[716]: getaddrinfo: "reggae.eik.bme.hu" invalid host address, ignored
 May  3 23:31:56 vpn-gw ntpd[716]: getaddrinfo: "swing.eik.bme.hu" invalid host address, ignored
 May  3 23:31:56 vpn-gw ntpd[716]: getaddrinfo: "jazz.eik.bme.hu" invalid host address, ignored
 May  3 23:31:57 vpn-gw kernel: re0: link state changed to UP
 
 It seems that the problem is the lack of network connectivity, hence the
 lack of a working resolver (I use recursive DNS servers running on other
 machines) at ntpd startup. However, ntpq returns the correct IP
 addresses (maybe it resolves them at the time I run ntpq, I don't know).
 
 [goya@vpn-gw /usr/share/doc/ntp]$ ntpq -p
      remote           refid      st t when poll reach   delay   offset jitter
 ==============================================================================
  reggae.eik.bme. .INIT.          16 u    -  512    0    0.000    0.000 0.000
  swing.eik.bme.h .INIT.          16 u    -  512    0    0.000    0.000 0.000
  jazz.eik.bme.hu .INIT.          16 u    -  512    0    0.000    0.000 0.000
 [goya@vpn-gw /usr/share/doc/ntp]$ ntpq -np
      remote           refid      st t when poll reach   delay   offset jitter
 ==============================================================================
  152.66.116.122  .INIT.          16 u    -  512    0    0.000    0.000 0.000
  152.66.116.124  .INIT.          16 u    -  512    0    0.000    0.000 0.000
  152.66.116.120  .INIT.          16 u    -  512    0    0.000    0.000 0.000
 [goya@vpn-gw /usr/share/doc/ntp]$
 
 Running '/etc/rc.d/ntpd restart' later resolves the problem.
 
 In the freebsd-stable@ thread
 http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064349.html
 /etc/rc.d/netwait was suggested as a workaround.
 
 I found with Google that OpenSUSE uses a much better (IMHO the correct)
 approach: They have the 'dynamic' keyword for servers defined in
 ntp.conf, causing ntpd to try to resolve the server's domain name later
 also, not only at ntpd startup.
 http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/cha.netz.xntp.html#sec.netz.xntp.dynamic
 (Don't know whether it's a newer ntpd, or their patched version, or a
 completly different NTP software.)
 
 Regards,
 András
>Unformatted:
