<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 18, 2022 at 10:47 AM Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de" target="_blank">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>> Mantas Mikulenas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> schrieb am 17.08.2022 um 15:17 in<br>
Nachricht<br>
<<a href="mailto:CAPWNY8Wzk0Qpo%2B4D-EbM_uyegQLSoJ_3oHqcY60Ubho0Jrp07g@mail.gmail.com" target="_blank">CAPWNY8Wzk0Qpo+4D-EbM_uyegQLSoJ_3oHqcY60Ubho0Jrp07g@mail.gmail.com</a>>:<br>
> On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms <<a href="mailto:etienne.doms@gmail.com" target="_blank">etienne.doms@gmail.com</a>><br>
wrote:<br>
> <br>
>> Hi,<br>
>><br>
>> I'm developing an application for an embedded system that needs to<br>
>> wait for proper NTP synchronization. systemd-timesyncd is running and<br>
>> I can read NTPSynchronized from /org/freedesktop/timedate1 using<br>
>> D-Bus. I read in the manual that this property is not signaled, and<br>
>> that I need to do some weird magic with timerfd's<br>
>> TFD_TIMER_CANCEL_ON_SET flag.<br>
>><br>
>> It works, but having the ECANCELLED on the read() means that something<br>
>> somewhere did clock_settime(CLOCK_REALTIME, <...>), not especially<br>
>> that I got a proper NTP synchronization. Then, I still need to query<br>
>> NTPSynchronized after, and retry the timerfd thing if it didn't switch<br>
>> to "true", which is still some kind of polling (but very unlikely,<br>
>> sure).<br>
>><br>
>> As a result, I'm a bit curious, what was the rationale of not simply<br>
>> signaling NTPSynchronized?<br>
>><br>
> <br>
> timedated itself doesn't have knowledge of that event, because it isn't the<br>
> daemon that performs actual synchronization (that's timesyncd), so all that<br>
> the D-Bus property does is report you the status of adjtimex() –<br>
> specifically it returns whether ".maxerror < 16000000". Timedated would<br>
> still need to poll and/or do timerfd tricks in order to see that state<br>
> being reached. (Currently timedated is not a continuously running daemon –<br>
> it starts up only whenever properties are queried and exits when idle.)<br>
> <br>
> A better question is why the timesyncd daemon does not have such a D-Bus<br>
> signal; looks like it *almost* does<br>
> (org.freedesktop.timesync1.Manager.NTPMessage) but it looks like it only<br>
> emits the raw messages and not whether they resulted in a successful sync.<br>
<br>
Maybe because a "successful sync" is actually not sharply defined.<br>
There can be very interesing scenarios (like requiring three "surviving<br>
clocks", but only two were found)<br></blockquote><div><br></div><div></div><div>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.<br clear="all"></div></div><br>-- <br><div dir="ltr"><div dir="ltr">Mantas Mikulėnas</div></div></div>