Frederick Bruckman said:

>I can confirm that named will not barf if ntpd{,ate} steps the time
>while it's starting up, or even thereafter.  I think the worst that
>could happen is that a dead battery would cause the clock to start
>up at 1970, and then when it steps forward everything in the cache
>is expired immediately.  That's hardly a problem when named has
>just started up, as the cache would be nearly empty, so I vote put
>named before ntpdate before ntpd.

Going back into the dim past, everywhere I've ever worked the consensus
was to use hard-wired ip addresses and not FQDN in /etc/ntp.conf. Thus
there are no DNS problems, and it is less likely that the system will
connect to a bogus ntp server that is spoofing the FQDN. Using "ntpq -p"
occasionly will let the system administrator see the external systems that
he is connecting to for time syncing.

Ntpdate is not needed unless the system has a really bad clock chip. It is
true that the clock chips in Intel boxes are marginal these days. When Sun
first started including XNTP, ntpdate would get kicked off before DNS and
NIS. This would often mean a looping ntpdate process that would go on forever
or until it was killed. Ntpdate is just not needed on a casual reboot of a
system, but, if ntp.conf contains ip addresses rather than FQDN, then the
only problem is the network being down.
-- 
Rick Kelly	rmk@rmkhome.com
		<http://www.rmkhome.com/>
		<http://rkba.rmkhome.com/>