In article <20050316105101.GW16595@mewburn.net>,
	Luke Mewburn <lukem@NetBSD.org> writes:
> 
> On Wed, Mar 16, 2005 at 10:24:20AM +0000, Alistair Crooks wrote:
>  |
>  | Exactly - and this is where we have the chicken and egg problem.
>  | named requires "good time", presumably for TTLs (and I would think
>  | that kdc would need this too), and to get that, we need to go to
>  | a time server and find out what the "good time" is. But we can
>  | only do that when we've resolved the name of the time server.
> 
> Can anyone confirm if named will not barf if ntpdate starts after
> named and ntpdate skews the time ?

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.

I should add that Dave Mills often says that "ntpdate must die",
because it duplicates code in "ntpd", and because it doesn't sanity
check the results as well (or at all). He recommends using "ntpd -g"
for the same purpose, but most users complain that that's too slow,
so I guess we shouldn't do anything about that just yet.


Frederick