Bug 1142
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: | |
Embargoed: |
Description
Marc MERLIN
1999-02-13 06:47:53 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. 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 |