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.