On 2012-11-20 14:24, Trevor Cordes wrote:
On 2012-11-20 Gilles Detillieux wrote:
fails. As far as I can tell, neither RHEL5 nor F17 call hwclock at any point during shutdown, which seems odd/bass-ackwards.
Ya, it looks like no one is touching hwclock at shutdown. To me it makes sense that on boot we read the hwclock, then we update with ntpdate/ntpd, ... system runs ..., then on shutdown we put our idea of the proper date (which if things are working should always be correct) back to hwclock for next time. This is how it used to work, but doesn't now.
I found: https://bugzilla.redhat.com/show_bug.cgi?id=816752 (long-winded)
Yeah, this is one of the things that bugs me about RedHat/Fedora (and maybe the whole Linux culture in general). Bug threads will sometimes degenerate into philosophical arguments between conflicting ideologies, and since an ideal solution isn't readily available, the default choice is to do nothing (or remove something that was working, but not ideal).
Sometimes, you just want to grab a pragmatist's clue-stick, and start whacking! ;)
In F16 (and newer) it looks like you need to enable both ntpd.service and ntpdate.service in systemd. On all my boxes I had just ntpd on. Time to change that.
Then set SYNC_HWCLOCK=yes in /etc/sysconfig/ntpdate
Looks like systemd is properly setup to run ntpdate before ntpd.
Yeah, this should work for startup, but unfortunately, doesn't address the issue of RTC drift during uptime. They really should fix the ntpd script to rewrite the RTC on shutdown, if SYNC_HWCLOCK is set. (And, ntpdate should really be merged back into ntpd's script, but that's a whole other nerd debate...)
Thanks guys.
You're welcome.