<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2025 at 4:42 PM Henti Smith <<a href="mailto:henti@gaydonsmith.co.uk">henti@gaydonsmith.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Good day all. <br></div><div><br></div><div>I'm having some timeouts on a oneshot service and I cannot explain the failure based on the documentation. <br></div><div><br></div><div>We have a service that runs a script that checks for a valid upstream NTP server before dependent services can start to</div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>set PTP master for other slaves on the network to use to set system time. The service file looks like this: <br></div><div><br></div><div>[Unit]<br>Description=NTP boot-time synch<br><br>[Service]<br>Type=oneshot<br>RemainAfterExit=yes<br>ExecStart=/opt/timesync-master/ntpsync_start.sh<br>TimeoutStartSec=infinity<br><br>[Install]<br>WantedBy=multi-user.target</div><div><br></div><div>For the most part this seems to work, but we're seeing failures like this:</div><div>root@server:~# systemctl status custom.check.serviceroot@server:~# systemctl status custom.ntpsync.service<br>* oxbotica.ntpsync.service - NTP boot-time synch<br>     Loaded: loaded (/lib/systemd/system/custom.ntpsync.service; enabled; vendor preset: enabled)<br>     Active: failed (Result: timeout) since Mon 2024-06-17 20:31:23 UTC; 4 days ago<br>    Process: 1695 ExecStart=/opt/timesync-master/ntpsync_start.sh (code=killed, signal=TERM)<br>   Main PID: 1695 (code=killed, signal=TERM)</div><div><br></div><div>This seems to indicate that this was a timeout error and systemd sent TERM to the script, but according to the docs ands and since we don't set TimeoutStartSec and Type=oneshot is used, timeout is disabled by default. <br></div><div><br></div><div>I'm not sure how the process got killed if it's oneshot and timeout is disabled, but the error seems to indicate it was a timeout TERM ? <br></div></div></blockquote><div><br></div><div>Run a `systemctl show` on the unit and check what settings are in effect – it might be that a default timeout is set globally in systemd/system.conf or something like that.</div><div><br></div><div>I'd also try booting with "systemd.log_level=debug" in the kernel command line, in case it adds anything more useful to the journal whenever this happens.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>To paint a fuller picture, these computers are ARM without hardware clocks, hence the need for NTP from external source, and on default boot they revert back to epoch and during boot get's set to a more up to date time, which changes with each firmware update from the vendor. <br></div></div></blockquote><div><br></div><div>It might very well be systemd itself doing this; on startup it bumps the clock either to its build timestamp or to the timestamp of "/usr/lib/clock-epoch" or "/var/lib/systemd/timesync/clock", whichever is more recent. (The latter file is periodically touched by systemd-timesyncd.)<br></div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>