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

[Ulrich Windl]

>>> Etienne Doms <etienne.doms at gmail.com> schrieb am 17.08.2022 um 14:49 in
Nachricht
<CACGcE5+aZBRwCZ8D=khfkSJTJdUQ3mPA0biiUfWRy9ck8VOJaQ at mail.gmail.com>:
> 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.

Hi!

I suspect such an event wasn't implemented, because you would typically get at
most one per host boot.
(For completeness the opposite event should be there, too)
What will your software do if NTP sync is lost?

Regards,
Ulrich


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