Re: [EXT] Re: org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 18, 2022 at 10:47 AM Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> Mantas Mikulenas <grawity@xxxxxxxxx> schrieb am 17.08.2022 um 15:17 in
Nachricht
<CAPWNY8Wzk0Qpo+4D-EbM_uyegQLSoJ_3oHqcY60Ubho0Jrp07g@xxxxxxxxxxxxxx>:
> On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms <etienne.doms@xxxxxxxxx>
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.

--
Mantas Mikulėnas

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux