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.
Same thing applies to ntpdate, so if there are already some bugs in GNATS about that, this should be duped appropriately. -Garrett
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
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.
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.
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
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
This should no longer be a problem with our modern ntp.conf. We've switched from specific hostnames to the 'pool' feature that adds hosts from the pool as needed. The pool management is fully dynamic, periodically adding new servers when there not enough available, which amounts to automatic retries following dns failures at startup time. When it is necessary to have ntpd set time before allowing rc processing to conclude, options to ensure ntpd can resolve names include setting the interface config to SYNCDHCP instead of plain DHCP, or add one or more interface names to the netwait_if= list in rc.conf to ensure the names will resolve at startup.