On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms <etienne.d...@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. 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