Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 4238 - xntpd can't fix clocks way out of date
Summary: xntpd can't fix clocks way out of date
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xntp3
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 1999-07-28 15:03:39 UTC
Embargoed:

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.