| Summary: | after ntpdate, we may want to update the hardware clock | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Marc MERLIN <marc_soft> |
| Component: | xntp3 | Assignee: | David Lawrence <dkl> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | |
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. 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 *** Bug 9800 has been marked as a duplicate of this bug. *** 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 |
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> 02/13/99 01:49 -------