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.
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
