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.