Is there a package to do this?
Normally the hardware clock is set during shutdown if one is running ntpd. But if a long-running server shuts down unexpectedly, this isn't done, and the hardware clock might be off by a lot when it comes back up. So setting it periodically from a cron job could be useful.
What do others do? Adding a one liner to /etc/cron.daily that invokes /etc/rc.d/init.d/ntpd would do it but it seems heavyweight to restart ntpd. Alas, the script doesn't export just the sync_hwclock function.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Kenneth Porter Sent: Friday, March 04, 2011 14:15 To: CentOS mailing list Subject: [CentOS] Updating hardware clock from cron
Is there a package to do this?
Normally the hardware clock is set during shutdown if one is running ntpd.
No, hwclock --systohc is only called at start time (in /etc/rc.d/init.d/ntpd), and only if ntpdate got a good time, which is a good thing.
But if a long-running server shuts down unexpectedly, this isn't done, and the hardware clock might be off by a lot when it comes back up.
Not if you are running ntp and it was able to sync, because ntpd activates a mode in the kernel that sets the hwclock every 11 minutes when ntp declares it got synced.
If your hwclock is off by a lot when it comes up I believe it is from one of the following: A) bad cmos battery. B) poor cmos clock C) confusing info in /etc/adjtime due to using both hwclock --adjust [at boot] and ntp (long story, but it is due to both tweaking the clock without coordination between them). D) booting a different OS with different ideas of timezones. E) manual tweaking of time via bios.
So setting it periodically from a cron job could be useful.
What do others do? Adding a one liner to /etc/cron.daily that invokes /etc/rc.d/init.d/ntpd would do it but it seems heavyweight to restart ntpd. Alas, the script doesn't export just the sync_hwclock function.
Recommendation, Understand `hwclock --systohc` should _only_ be called when the admin knows a good system time was *_JUST_* set from a good source, i.e., following a successful call to ntpdate or the admin setting the systime with date.
On some systems that do NOT have ntpd service available (not on a network with a time server), I will have them do a sequence of hwclock --hctosys hwclock --adjust hwclock --hctosys in /etc/rc.d/rc.sysinit where it already does the hwclock --hctosys so that once I have set the time from a known source a few times the box will reasonably self correct time on boot, I will even on some of those systems have that sequence in a cronjob that gets run once a week. If this is on a network, I have the box that is doing this serve ntp (via local clock) to the rest of the network, so they drift together.
Reminder: `hwclock --systohc` should _only_ be called when the admin knows system time was JUST set from a good source, i.e., NOT from a cron job that is not also making sure the ntpdate worked.
on 15:04 Fri 04 Mar, Denniston, Todd A CIV NAVSURFWARCENDIV Crane (todd.denniston@navy.mil) wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Kenneth Porter Sent: Friday, March 04, 2011 14:15 To: CentOS mailing list Subject: [CentOS] Updating hardware clock from cron
Is there a package to do this?
Normally the hardware clock is set during shutdown if one is running ntpd.
No, hwclock --systohc is only called at start time (in /etc/rc.d/init.d/ntpd), and only if ntpdate got a good time, which is a good thing.
But if a long-running server shuts down unexpectedly, this isn't done, and the hardware clock might be off by a lot when it comes back up.
Not if you are running ntp and it was able to sync, because ntpd activates a mode in the kernel that sets the hwclock every 11 minutes when ntp declares it got synced.
If your hwclock is off by a lot when it comes up I believe it is from one of the following: A) bad cmos battery. B) poor cmos clock C) confusing info in /etc/adjtime due to using both hwclock --adjust [at boot] and ntp (long story, but it is due to both tweaking the clock without coordination between them). D) booting a different OS with different ideas of timezones. E) manual tweaking of time via bios.
F) Hardware clock set to local time and booting after a standard -> daylight savings or daylight savings -> standard time shift.
I saw this in a large production environmet.
The main effect was that system logs would show a very large slew during boot, after ntpdate was run. Annoying, possibly confusing, but not a show-stopper.
Generally, the solution is:
1: use ntp, chrony, or another time service to sync system clocks while running.
2: set hwclock to UTC, the way Krell intended it to be.
3: periodically sync the hwclock from system time. I don't really care if you do this hourly, daily, weekly, or monthly (I'd probably select daily myself). But it will tend to avoid big time jumps.
If you're particularly anal, you could periodically compare system and hwclock time, and raise a flag to replace the CMOS battery when this starts to drift. Since other CMOS and BIOS settings can be lost, and about the only perceptible sign is a drifting hwclock, this is actually probably a pretty good practice.
On Fri, Mar 4, 2011 at 3:04 PM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane todd.denniston@navy.mil wrote: [snip]
If your hwclock is off by a lot when it comes up I believe it is from one of the following: A) bad cmos battery. B) poor cmos clock C) confusing info in /etc/adjtime due to using both hwclock --adjust [at boot] and ntp (long story, but it is due to both tweaking the clock without coordination between them). D) booting a different OS with different ideas of timezones. E) manual tweaking of time via bios.
[snip]
good list.. I'd also add "F) Running inside a virtual machine."
The VMWare clock skew can be enormous. On some systems it drifts by a minute per hour if not adjusted via ntp.
--On Friday, March 04, 2011 3:04 PM -0500 "Denniston, Todd A CIV NAVSURFWARCENDIV Crane" todd.denniston@navy.mil wrote:
Not if you are running ntp and it was able to sync, because ntpd activates a mode in the kernel that sets the hwclock every 11 minutes when ntp declares it got synced.
Thanks, this is the part I was unaware of. So that obviates any need for a cron job.