Bug 4238 - xntpd can't fix clocks way out of date
Summary: xntpd can't fix clocks way out of date
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xntp3
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-28 14:52 UTC by nelson
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-07-28 15:03:39 UTC

Attachments (Terms of Use)

Description nelson 1999-07-28 14:52:53 UTC
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.

Comment 1 Jeff Johnson 1999-07-28 15:03:59 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.