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

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Thu Aug 18 07:47:54 UTC 2022


>>> 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)
when the status output of NTP looks as if synchronized, but in fact the time
is "running away".
Acually "NTP sync" is not a Boolean, but more like an indicator ranging from 0
(unsynced) to 1 (well-synced).
(I tried to implement such an indicator in the past, but only very few servers
have a score of "1.0")

Regards,
Ulrich

> 
> For now, if you're using timesyncd you can use inotify to watch
> /run/systemd/timesync/synchronized, which is touched after a sync.
> 
> -- 
> Mantas Mikulėnas





More information about the systemd-devel mailing list