Red Hat Bugzilla – Bug 4238
xntpd can't fix clocks way out of date
Last modified: 2008-05-01 11:37:51 EDT
A variety of things in Redhat 6.0 conspire to prevent xntpd
from keeping a clock set properly in all circumstances.
xntpd has a feature where it won't change the system clock
if the clock is way out of line (roughly 10 minutes). This
feature makes some sense as a sanity check, but it means
that xntpd alone won't alwaysset the clock. If a system
boots with a wildly incorrect time, Redhat 6.0 won't fix it.
Worse, xntpd never sets the hardware clock. So even if a
system boots correctly and xntpd keeps it synced, if the
hardware clock drifts badly then when the system reboots the
time will be so far off xntpd can't help.
The fix for the first problem is to run ntpdate at bootup.
Redhat used to do this, I'm not sure why it's been removed.
I believe the fix for the second problem is to reset the
hardware clock from time to time with hwclock.
Add the host that you wish to synchronize against using ntpdate
to /etc/ntp/step-tickers. Look at /etc/rc.d/init.d/xntpd for details.
We do not synchronize the hardware clock with the system clock because
of the numerous support issues associated with setting the hardware
clock on multiple platforms. For example, dual booting machines
often require localtime rather than UTC, and many BIOS's do not
support daylight saveings times.