Thanks for the insight.
W dniu 01.03.2021 o 17:34, Lennart Poettering pisze:
> On Mo, 01.03.21 17:17, Michał Zegan (webczat_200@xxxxxxxxxxxxxx) 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
>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
