Bug 1142 - after ntpdate, we may want to update the hardware clock
after ntpdate, we may want to update the hardware clock
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: xntp3 (Show other bugs)
5.2
i386 Linux
medium Severity low
: ---
: ---
Assigned To: David Lawrence
:
: 9800 11020 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-02-13 01:47 EST by Marc MERLIN
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-03-22 15:09:44 EST
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 Marc MERLIN 1999-02-13 01:47:53 EST
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
boot.
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
/etc/ntp/step-tickers`
                echo
+
+               # 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
values
+                   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
        fi
         # Start daemons.
         echo -n "Starting xntpd: "

------- Email Received From  Marc Merlin <marc@merlins.org> 02/13/99 01:49 -------
Comment 1 Jeff Johnson 1999-02-15 13:06:59 EST
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 05:26:59 EST
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 13:04:59 EST
*** Bug 9800 has been marked as a duplicate of this bug. ***
Comment 4 Avi Alkalay 2000-02-27 20:07:59 EST
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,
Avi
Comment 5 Jeff Johnson 2000-05-05 14:04:59 EDT
*** Bug 11020 has been marked as a duplicate of this bug. ***

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