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

[Mantas Mikulėnas]

On Thu, Aug 18, 2022 at 10:47 AM Ulrich Windl <
Ulrich.Windl at rz.uni-regensburg.de> wrote:

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220818/9791b026/attachment.htm>