Bug#2982: ntpdate called at bootup

[Michael Shields <shields@crosslink.net>]

At 1996-05-17 01:06  +0000, Ian Jackson wrote:
>Surely the correct solution is to add an option to xntpd to tell it
>`believe the servers rather than the local clock when they are wildly
>different', so that instead of exiting it warps the local clock
>straight away.

You're right.  That would avoid the situation where the server really is
wildly wrong, the client boots during that period, and then when the server
fixes its clock, the client xntpd gives up and dies.

RFC 1305 says:

# The basic NTP robustness model is that a host has no other means to
# verify time other than NTP itself. In some equipment a battery-backed
# clock/calendar is available for a sanity check. If such a device is
# available, it should be used only to confirm sanity of the timekeeping
# system, not as the source of system time. In the common assumption (not
# always justified) that the clock/calendar is more reliable, but less
# accurate, than the NTP synchronization subnet, the recommended approach
# at initialization is to set the Clock register as determined from the
# clock/calendar and the other registers, counters and flags as described
# above. On subsequent updates if the time offset is greater than a
# configuration parameter (e.g., 1000 seconds), then the update should be
# discarded and an error condition reported.

In my environment, the CMOS clock *is* a good sanity check, because my
machines never boot anything but Linux, and I have redundant timeservers
that won't ever all be seriously wrong in the same way.  I'd still like the
config script to prompt me and give me the behavior of never warping the
clock more than 1024 seconds.

--
Shields, CrossLink.