Bug 1142

Summary: after ntpdate, we may want to update the hardware clock
Product: [Retired] Red Hat Linux Reporter: Marc MERLIN <marc_soft>
Component: xntp3Assignee: David Lawrence <dkl>
Severity: low Docs Contact:
Priority: medium    
Version: 5.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-03-22 20:09:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Marc MERLIN 1999-02-13 06:47:53 UTC
For systems which have a hardware clock that is way out of
sync, /etc/rc.d/init.d/xntpd resets the system clock with
ntpdate, and the clock is maintained from then on, but the
hardware clock still has the wrong value and at the next
The problem is that not only the hardware clock is never
fixed, but it creates a jump in syslog and will also confuse
crond because crond is started before xntpd

On my system, I did the following (which I will also send
as Email):
--- xntpd.redhat        Mon Oct 12 18:18:28 1998
+++ xntpd       Fri Feb 12 22:28:29 1999
@@ -25,6 +25,42 @@
                echo -n "Syncing time for xntpd"
                /usr/sbin/ntpdate -b -p 8 -u `cat
+               # Save updated time in hardware clock
+               ARC=0
+               UTC=0
+               if [ -f /etc/sysconfig/clock ]; then
+                   . /etc/sysconfig/clock
+                   # convert old style clock config to new
+                   if [ "${CLOCKMODE}" = "GMT" ]; then
+                           UTC=true
+                   elif [ "${CLOCKMODE}" = "ARC" ]; then
+                           ARC=true
+                   fi
+               fi
+               if [ -x /sbin/hwclock ]; then
+                   CLOCKFLAGS="--systohc"
+                   CLOCK=/sbin/hwclock
+               else
+                   CLOCKFLAGS="-w"
+                   CLOCK=/sbin/clock
+               fi
+               case "$UTC" in
+                 yes|true)
+                   CLOCKFLAGS="$CLOCKFLAGS -u";
+                 ;;
+               esac
+               case "$ARC" in
+                 yes|true)
+                   CLOCKFLAGS="$CLOCKFLAGS -A";
+                 ;;
+               esac
+               $CLOCK $CLOCKFLAGS
         # Start daemons.
         echo -n "Starting xntpd: "

------- Email Received From  Marc Merlin <marc> 02/13/99 01:49 -------

Comment 1 Jeff Johnson 1999-02-15 18:06:59 UTC
Updating the hardware clock opens up a number of issues that have
nothing to do with xntpd. The issues include support for BIOSes
that manually set DST flags and providing the correct hwclock time
for machines that boot multiple operating systems. Win95 usually
expects hwclock to be localtime.

Updating hwclock after ntpdate will not prevent a crond/syslog jump.

There is, of course, nothing stopping you from setting your hwclock
any way that you choose, and xntpd is certainly a good candidate
for a reliable time standard.

Comment 2 Marc MERLIN 1999-02-16 10:26:59 UTC
I understand that you may not want to implement my suggestion, but you
should note that
1) my patch does take into account the fact that the bios clock may
   be set to GMT or local time (by reading sysconfig/clock)
2) yes, my patch still creates a time jump, but only once. After the
   bios clock has been set, every subsequent boot will be fine,
   compared to the default setup were each boot introduces a time jump
   after xntpd is launched.

PS: I wanted to add this comment without reopening the bug, but it
seems that bugzilla insists on checking the reopen bug box

Comment 3 Jeff Johnson 2000-02-27 18:04:59 UTC
*** Bug 9800 has been marked as a duplicate of this bug. ***

Comment 4 Avi Alkalay 2000-02-28 01:07:59 UTC
JBJ, you are right. It's not good to set the hw clock when the system goes up.
But in my patch, the hw clock is adjusted when the system goes down. Anyway,
setting the hw clock will only afect syslog and cron in the next reboot.

Regarding other operationg systems, in both patches this was solved using the
$UTC from /etc/sysconfig/clock and it is safe to set the HW clock.

My patch also takes care about the starting of xntp in init phase. Please check
the patch for the "chkconfig" line.

Thank you,

Comment 5 Jeff Johnson 2000-05-05 18:04:59 UTC
*** Bug 11020 has been marked as a duplicate of this bug. ***