Bug 11020 - Hardware clock not adjusted for skew.
Summary: Hardware clock not adjusted for skew.
Status: CLOSED DUPLICATE of bug 1142
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xntp3 (Show other bugs)
(Show other bugs)
Version: 6.2
Hardware: All Linux
medium
low
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-04-24 22:50 UTC by Sam Varshavchik
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Sam Varshavchik 2000-04-24 22:50:12 UTC
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 06:18:59 UTC
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 18:04:59 UTC
*** 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.