Sorry .. more context I forgot to add. Ubuntu 20.04.6 on ARM. default package Systemd
systemd 245 (245.4-4ubuntu3.24) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid On Tue, 28 Jan 2025 at 14:42, Henti Smith <he...@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 set PTP master for other > slaves on the network to use to set system time. The service file looks > like this: > > [Unit] > Description=NTP boot-time synch > > [Service] > Type=oneshot > RemainAfterExit=yes > ExecStart=/opt/timesync-master/ntpsync_start.sh > TimeoutStartSec=infinity > > [Install] > WantedBy=multi-user.target > > For the most part this seems to work, but we're seeing failures like this: > root@server:~# systemctl status custom.check.serviceroot@server:~# > systemctl status custom.ntpsync.service > * oxbotica.ntpsync.service - NTP boot-time synch > Loaded: loaded (/lib/systemd/system/custom.ntpsync.service; enabled; > vendor preset: enabled) > Active: failed (Result: timeout) since Mon 2024-06-17 20:31:23 UTC; 4 > days ago > Process: 1695 ExecStart=/opt/timesync-master/ntpsync_start.sh > (code=killed, signal=TERM) > Main PID: 1695 (code=killed, signal=TERM) > > 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. > > 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 ? > > 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. > > I really don't know if any of this is relevant, there are so many moving > parts to this. > > Any assistance to figure this out would be most welcome. > > Kind regards > Henti >
