[systemd-devel] Oneshot killed by timeout
Mantas Mikulėnas
grawity at gmail.com
Wed Jan 29 10:22:02 UTC 2025
On Wed, Jan 29, 2025 at 11:56 AM Henti Smith <henti at gaydonsmith.co.uk>
wrote:
> On Tue, 28 Jan 2025 at 16:05, Mantas Mikulėnas <grawity at gmail.com> wrote:
>
>> On Tue, Jan 28, 2025 at 4:42 PM Henti Smith <henti at gaydonsmith.co.uk>
>> wrote:
>>
>>> Good day all.
>>>
>>> I'm having some timeouts on a oneshot service and I cannot explain the
>>> failure based on the documentation.
>>>
>>> We have a service that runs a script that checks for a valid upstream
>>> NTP server before dependent services can start to
>>>
>>
>> Systemd itself has a "systemd-time-wait-sync.service" for that purpose.
>> It waits for the NTP daemon to set the 'Clock in sync' kernel flag via
>> adjtimex (or, really, *unset* the 'Clock out of sync' flag) so it should be
>> compatible with both ntpd and chrony (with rtcsync on) – and with
>> systemd-timesyncd of course.
>>
>
> Good morning Mantas,
>
> Thank you so much for your reply. This is very encouraging as this would
> replace two mechanisms we're maintaining ourselves, which we really should
> not.
>
> Can we set a minimum required stratum systemd-timesyncd. We're using
> Cradlepoint hardware for timesyncm and unfortunately they serves a totally
> bogus NTP time while it is booting, and although it doesn't set the stratum
> to "unsynchronised" (=16) like it
> should while serving a heinous time, it does at least set a higher stratum
> than when it's serving the correct time, which we're currently checking in
> our own scripts.
>
Not with timesyncd, although it additionally looks at the NTP 'leap' flag
indicating "not in sync" in case the Cradlepoint happens to set that... If
the stratum check is needed then I guess you'll better use a "full" NTP
daemon which might have that option (chrony with 'orphan' flag, maybe).
(...or iptables u32 to discard NTP response packets that indicate a
too-high stratum, so that timesyncd thinks the server is down. It's very
much a hack but at least a different type of hack.)
--
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250129/3f3c4ea9/attachment.htm>
More information about the systemd-devel
mailing list