Bug 144804 - ntpd(8) cannot resolve hostnames at system start
Summary: ntpd(8) cannot resolve hostnames at system start
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 8.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-16 20:10 UTC by andy wilson
Modified: 2018-07-04 14:45 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description andy wilson 2010-03-16 20:10:00 UTC
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.
Comment 1 Garrett Cooper 2010-03-16 23:11:01 UTC
Same thing applies to ntpdate, so if there are already some bugs in
GNATS about that, this should be duped appropriately.
-Garrett
Comment 2 Garrett Cooper 2010-03-16 23:22:42 UTC
    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
Comment 3 Санек Гурин 2010-03-18 12:05:46 UTC
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.
Comment 4 andy wilson 2010-03-18 18:04:17 UTC
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.
Comment 5 jako.andras 2013-05-04 21:18:54 UTC
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
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:30 UTC
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
Comment 7 Ian Lepore freebsd_committer freebsd_triage 2018-07-04 14:45:33 UTC
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.