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

[Etienne Doms]

Oh, should have added a bit more context, indeed.

The piece of software is bringing a specific interface up, checking
that something is connected (link going up or not), then issues a DHCP
request onto it to fetch an IP and NTP servers, and then waits for
proper NTP synchronization to keep on. If the remote is not present,
or if it fails to answer us within a given time frame, we give up and
do something else.

Maybe we can play with dedicated .service/.target using Requires/After
and OnFailure to drive all that mecanic with different oneshot
processes, but using libsystemd internally in a single process sounded
just more KISS for our usage.

I'm just confused that I cannot have a proper "NTP sync'ed" event, the
documentation explicitly states "we don't signal it, use some timerfd
things" and I'm curious about the rationale of this choice.

Le mer. 17 août 2022 à 14:01, Ulrich Windl
<Ulrich.Windl at rz.uni-regensburg.de> a écrit :
>
> >>> Etienne Doms <etienne.doms at gmail.com> schrieb am 17.08.2022 um 12:58 in
> Nachricht
> <CACGcE5K6zKJjPeJDbEyMW8VM8i_9J1JtJc-8PbtwTib0HjAHTw at mail.gmail.com>:
> > Hi,
> >
> > I'm developing an application for an embedded system that needs to
> > wait for proper NTP synchronization. systemd-timesyncd is running and
>
> What's wrong with time-sync.target? Or maybe even time-set.target?
>
> > 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?
> >
> > Thanks,
> > Etienne
>
>
>
>