Bug 11020 - Hardware clock not adjusted for skew.
Hardware clock not adjusted for skew.
Status: CLOSED DUPLICATE of bug 1142
Product: Red Hat Linux
Classification: Retired
Component: xntp3 (Show other bugs)
6.2
All Linux
medium Severity low
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-24 18:50 EDT by Sam Varshavchik
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-05 14:04:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sam Varshavchik 2000-04-24 18:50:12 EDT
I find that xntp does not adjust the realtime hardware BIOS clock, only the
system clock.  Over time, if a significant skew builds up, on the next
reboot the clock will be thrown back.

If the master is rebooted, when there's a skew, all the slaves will get
their clocks reset.  If the slave is rebooted, several minutes will go by,
then the slave's clock will be jump by a large amount, when it is
resynchronized with a master.

Solution:  add the following to /etc/rc.d/init.d/xntpd, after the killproc
that stops the daemon:

   /sbin/hwclock --systohc

This will adjust the hardware clock with the accumulated skew, before the
system shutdown.
Comment 1 Daniel Roesen 2000-04-27 02:18:59 EDT
xntpd should update the RTC itself. Are you running on Compaq ProLiant hardware?
I think i noticed this problem on ProLiants (hwclock --systohc being unable to
update the RTC).
Comment 2 Jeff Johnson 2000-05-05 14:04:59 EDT
*** This bug has been marked as a duplicate of 1142 ***

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