>>> Mantas Mikulenas <graw...@gmail.com> schrieb am 18.08.2022 um 10:20 in Nachricht <capwny8vepccedh5+yndehdq0tp-ph1o2lb8jrriviielor1...@mail.gmail.com>: > On Thu, Aug 18, 2022 at 10:47 AM Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> wrote: > >> >>> Mantas Mikulenas <graw...@gmail.com> schrieb am 17.08.2022 um 15:17 in >> Nachricht >> <capwny8wzk0qpo+4d-ebm_uyegqlsoj_3ohqcy60ubho0jrp...@mail.gmail.com>: >> > 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. >> >> 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.
So strictly speaking the event is not "time synced", but "time set". The difference will be obvious after a week or so ;-) Regards, Ulrich > > -- > Mantas Mikulėnas
