[systemd-devel] Antw: Re: [EXT] Re: org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?

[Ulrich Windl]

>>> Mantas Mikulenas <grawity at gmail.com> schrieb am 18.08.2022 um 10:20 in
Nachricht
<CAPWNY8VepcCEDh5+yndEHDQ0TP-pH1O2LB8jrRiviieLoR15AQ at mail.gmail.com>:
> On Thu, Aug 18, 2022 at 10:47 AM Ulrich Windl <
> Ulrich.Windl at rz.uni-regensburg.de> wrote:
> 
>> >>> Mantas Mikulenas <grawity at gmail.com> schrieb am 17.08.2022 um 15:17 in
>> Nachricht
>> <CAPWNY8Wzk0Qpo+4D-EbM_uyegQLSoJ_3oHqcY60Ubho0Jrp07g at mail.gmail.com>:
>> > On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms <etienne.doms at gmail.com>
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> I'm developing an application for an embedded system that needs to
>> >> wait for proper NTP synchronization. systemd-timesyncd is running and
>> >> I can read NTPSynchronized from /org/freedesktop/timedate1 using
>> >> D-Bus. I read in the manual that this property is not signaled, and
>> >> that I need to do some weird magic with timerfd's
>> >> TFD_TIMER_CANCEL_ON_SET flag.
>> >>
>> >> It works, but having the ECANCELLED on the read() means that something
>> >> somewhere did clock_settime(CLOCK_REALTIME, <...>), not especially
>> >> that I got a proper NTP synchronization. Then, I still need to query
>> >> NTPSynchronized after, and retry the timerfd thing if it didn't switch
>> >> to "true", which is still some kind of polling (but very unlikely,
>> >> sure).
>> >>
>> >> As a result, I'm a bit curious, what was the rationale of not simply
>> >> signaling NTPSynchronized?
>> >>
>> >
>> > timedated itself doesn't have knowledge of that event, because it isn't
>> the
>> > daemon that performs actual synchronization (that's timesyncd), so all
>> that
>> > the D-Bus property does is report you the status of adjtimex() –
>> > specifically it returns whether ".maxerror < 16000000". Timedated would
>> > still need to poll and/or do timerfd tricks in order to see that state
>> > being reached. (Currently timedated is not a continuously running daemon
>> –
>> > it starts up only whenever properties are queried and exits when idle.)
>> >
>> > A better question is why the timesyncd daemon does not have such a D-Bus
>> > signal; looks like it *almost* does
>> > (org.freedesktop.timesync1.Manager.NTPMessage) but it looks like it only
>> > emits the raw messages and not whether they resulted in a successful
>> sync.
>>
>> Maybe because a "successful sync" is actually not sharply defined.
>> There can be very interesing scenarios (like requiring three "surviving
>> clocks", but only two were found)
>>
> 
> It's an SNTP client, it only deals with one timeserver at a time. And it
> already has a specific definition of "synced" in the code because it sets a
> flag file on the filesystem when that happens, just doesn't do the same via
> D-Bus.

So strictly speaking the event is not "time synced", but "time set".
The difference will be obvious after a week or so ;-)

Regards,
Ulrich

> 
> -- 
> Mantas Mikulėnas