Update on hardware clocks and drift

Update on hardware clocks and drift

I received a comment about Tuesday's post about ssh and clock sync issues and figured it's worthy of an additional public reply.

Paraphrased, the comment was that my line "If the machine had a hardware clock, it would have come up with time pretty close to when it had gone offline" is a little confusing because hardware clocks tend to keep ticking while powered off. It's not going to be four hours off if the machine was powered off for four hours.

They are right that a hw clock isn't going to drift too much under most circumstances. It is, however, subject to a bunch of things, like whether the system administrators have bothered to set up something to periodically flush the system clock (the software one maintained by the kernel) back to the hardware clock. This is usually from a wide-ranging thing that happened to also do this (does systemd do this yet?) or just a cron job to run 'hwclock --utc --systohc'.

(You do sync your hardware clock somehow, right? Better go check...)

If nobody's done this since the machine was installed, it might be in the approximate neighborhood of the current time (so certs will still work), but it won't be close by any stretch of the imagination.

I could have written that post to instead say that it would be spot-on accurate, but that would also be incorrect, albeit for different reasons.

Basically, no matter how I worded it, someone could always "well but" the post. Short of being exhaustive to the point of no longer being interesting, that angle always exists.

As a practical matter, when given the choice of two options both with their own caveats while writing that post, I made a choice. I went for the option that's less likely to instill confidence in a device that will never be a truly good time keeper in most machines... that being the hardware RTC.