dmesg – How to confirm that the kernel is (or is not) updating the hwclock/RTC

Can someone explain how to confirm that the kernel is (or is not) updating the hwclock/RTC?

Install the adjtimex tool, run adjtimex -p, and note the “status” value. The tool is old and a bit rudimentary and doesn’t even decode the status flags to text, so you’ll have to use a calculator or Python or some other REPL to check whether it includes the value 64 (STA_UNSYNC). If the flag is absent, then the clock is kept in sync; if it’s present, then the clock is not synchronized and RTC updates are disabled.

$ adjtimex -p
 status: 24577

$ echo $[24577 & 64]
0

$ python
>>> 24577 & 64
0

(Unfortunately, that is not what the timedatectl “System clock synchronized:” item reports, even though I was just about to suggest that. It deliberately ignores the STA_UNSYNC indication and only considers the maxerror.)

Generally STA_UNSYNC is set by default and the RTC remains untouched by the kernel unless you have an NTP daemon running (timesyncd, chrony, ntpd) which adjusts the system clock and clears the flag to enable RTC updates.

Note that the popular chrony NTP daemon doesn’t always rely on the kernel to update RTC; its default configuration used to be that the chrony daemon itself would make the hwclock adjustments while leaving STA_UNSYNC set (i.e. kernel updates disabled).

Alternative experimental approach: Use hwclock to set the RTC to an obviously wrong time, then wait approx. 11 minutes (the kernel’s usual update interval), then read out the RTC value again. If it’s now correct, then something has definitely updated it.

It’s occurred to me that the kernel may be performing the SYSTOHC sync only during shutdown, and maybe not being captured by dmesg…

If it is only done on shutdown, then it is not done by the kernel at all – that’s something part of your distribution’s startup/shutdown scripts.

However, I did find a reference to a fake-hardware clock (which seems odd).

As you noted, earlier Pi versions did not have a real RTC. But they still needed to store the rough system time somewhere, so that the system would not boot to 1970 every time. Thus a file on disk serves as a RTC that doesn’t tick.

(Systemd in fact has this functionality built in, even without the fake-hwclock.service.)