[systemd-devel] use RTC date/time to set system date time

[Lennart Poettering]

On Mo, 01.03.21 17:17, Michał Zegan (webczat_200 at poczta.onet.pl) wrote:

> > But this stuff is racy of course if the RTC is compiled as module and
> > you care for generic hw, that might or might not have an RTC: we
> > cannot gues swhether an RTC will show up or not in that case,
> > i.e. whether there is an RTC connected and whether there's a driver
> > for it. Hence we time-{set|sync}.target cannot possibly wait for it to
> > show up since it might mean we have to wait indefinitely...
> I actually think kernel doesn't set on module load, and if it does, it's
> very recent. How recent would it be? What kernel?

https://github.com/torvalds/linux/commit/f9b2a4d6a5f18e0aaf715206a056565c56889d9f

(also see: https://github.com/systemd/systemd/issues/17737)

> > If you really don't want to compile it in, and love the extra
> > headaches this involves, then make sure you run a recent kernel that
> > can sync the system clock to RTC even when the module is loaded
> > later. And then manually add an ordering dep to time-set.target to
> > wait for /dev/rtc0, since that is the target that should be delayed
> > until the RTC shows up and is probed:
>
> What is normally attached to this target?

time-set.target is the target that software that needs "roughly
correct time" is ordered after. (as opposed to time-sync.target which
is the target that software that needs "accurate correct time" is
ordered after). Sounds vague? That's because it is, on purpose.

To illustrate the two targets a bit:

systemd-timesyncd.service is ordered before time-set.target. It
maintains a touch file in /var/lib/ that is used to make the clock
monotonic. systemd-timesyncd.service will complete initialization only
after bumping the system clock according to that timestamp
file. Enabling this service hence won't cause much boot-time delay,
but at best gives you monotonic time, and only in late boot (since
/var/ needs to be mounted first).

OTOH systemd-time-wait-sync.service is ordered before
time-sync.target. This service blocks until an initial NTP sync is
acquired over the nwtrok. Enabling this will cause boot-time delay,
since we need to wait for an external networked time source to become
available across the network, but it gives you pretty correct time.

> In addition, the fact the device appear probably doesn't necessarily
> mean the time was set already?

if the kernel includes the aforementioned commit then yes, this means
the time was set already, since the kernel's rtc_hctosys() call is
invoked by the time the uevent notification is emitted.

> > But really, just figure out what your hw is and link the driver into
> > the kernel. It saves you a lot of headaches, and kernel timestamps
> > won't be crap initially.
>
> But kernel sets time at late boot anyway. So aren't they crap before it?
> Like I don't understand something about the mechanism.

Well, the nice thing with the kernel's own time syncing logic is that
it is applied immediately when the rtc shows up and has been
probed. There are no extra delays. So yes, if your RTC is super slow
to probe, then yeah a good number of early boot timestamps will still
be crap, and in the worst case time-set.target will catch this and be
delayed for the time necessary to make the timestamps accurate. But if
the RTC is quick to be probed then you get correct timestamps as early
as possible.

Lennart

--
Lennart Poettering, Berlin