Problems with ntp on one of our systems were traced to using a DNS cache
which came up after ntp tried to poll its servers.

D'OH!

We'd switched dns on the machine to DJBDNS dnscache running under
daemontools. dnscache was taking about 10 seconds to come up after
rc.local (where ntpd is started) completed. Apparently ntpd is pretty
graceless about retrying servers when dns is unavailable.

ntpd log errors were:

13 Dec 04:48:59 ntpd[276]: signal_no_reset: signal 17 had flags 4000000
13 Dec 04:49:01 ntpd[276]: signal_no_reset: signal 14 had flags 4000000

Two instances of ntpd would be present. The second one would hang.

Solution was to put another nameserver in /etc/resolve.conf in addition
to the local cache. I should have had a backup nameserver listed anyway.

My pain has proven most educational.

ScottJ

Scott Jordan wrote:

>Problems with ntp on one of our systems were traced to using a DNS cache
>which came up after ntp tried to poll its servers.
>
>D'OH!
>
>We'd switched dns on the machine to DJBDNS dnscache running under
>daemontools. dnscache was taking about 10 seconds to come up after
>rc.local (where ntpd is started) completed. Apparently ntpd is pretty
>graceless about retrying servers when dns is unavailable.
>
>ntpd log errors were:
>
>13 Dec 04:48:59 ntpd[276]: signal_no_reset: signal 17 had flags 4000000
>13 Dec 04:49:01 ntpd[276]: signal_no_reset: signal 14 had flags 4000000
>
>Two instances of ntpd would be present. The second one would hang.
>
>Solution was to put another nameserver in /etc/resolve.conf in addition
>to the local cache. I should have had a backup nameserver listed anyway.
>
>My pain has proven most educational.
>
>ScottJ
>
>
Yep, ouch.

Have you considered using the pool? My stuff is set up like this

server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
server north-america.pool.ntp.org
server north-america.pool.ntp.org
server north-america.pool.ntp.org

and I've experienced no problems whatsoever. It seems that the "local"
server avoids such problems (although I could be wrong about that) and
the pool appears to work just fine when the network becomes available.
After a few minutes

ntpq -n (or -np)

pops up with the servers it's using with nothing whatsoever in
/etc/resolv.conf.