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.