[systemd-devel] hardware clock

[Lennart Poettering]

On Wed, 27.07.16 19:54, Michał Zegan (webczat_200 at poczta.onet.pl) wrote:

> Hello.
> 
> There is, it seems, a problem with the hardware clock. That is, the
> systemd does not care about it. Neither systemd nor udev rules set the
> system time using the hardware clock.
> From what I know, if the clock is a cmos rtc, the kernel always sets
> time during bootup. In any other case, it should do this anyway if it is
> configured to do so during compilation, but only when appropriate rtc
> support is compiled into the kernel. So, userspace does not have to.
> The problem is that there are cases when the rtc is not a cmos one, and
> the driver is compiled as a module. This is a specific case because the
> kernel will not restore the time, and systemd does not do this either.
> The thing that restores the time is ntp synchronization and that is not
> related to the hardware clock.
> This issue is visible in case of arm boards with external realtime
> clocks, as those clocks are bought separately and not part of the
> platform. It would be nice if systemd would set the time, or if udev had
> a rule to do this, or both (in case the module was loaded earlier during
> initramfs phase). Or any other solution for that would be nice.

We don't really cover cases where the RTC driver is loaded as kernel
module during later boot. Our general suggestion is to compile the RTC
drivers you need directly into the kernel, and let the kernel
initialize the system clock from it.

If you compile your RTC drivers as kernel modules loaded late then I'd
suggest writing udev rules that sync the clocks as soon as the drivers
are loaded.

Generally it's a good idea though to leave this all to the kernel, so
that userspace comes up with a correctly set system clock already, so
that logging doesn't use broken realtime timestamps.

Lennart

-- 
Lennart Poettering, Red Hat