Package: ntpsec Version: 1.2.2+dfsg1-1+deb12u1 Severity: normal Dear Maintainer,
* What led up to the situation? Pretty normal install of debian using syytemd, systemd-netweorkd and ntpsec on a rather slow arm board. The system is a dhcp client that obtains a lease during boot on the ethernet and wifi devices (total of two). Obtaining those two leases causes ntpsec-systemd-netif to fail, presumably due to being restarted too often: Jul 13 07:04:10 opz3 systemd[1]: Started ntpsec-systemd-netif.service. Jul 13 07:04:10 opz3 systemd[1]: ntpsec-systemd-netif.service: Deactivated successfully. Jul 13 07:04:11 opz3 systemd[1]: Started ntpsec-systemd-netif.service. Jul 13 07:04:12 opz3 systemd[1]: ntpsec-systemd-netif.service: Deactivated successfully. Jul 13 07:04:13 opz3 systemd[1]: Started ntpsec-systemd-netif.service. Jul 13 07:04:13 opz3 systemd[1]: ntpsec-systemd-netif.service: Deactivated successfully. Jul 13 07:04:14 opz3 systemd[1]: Started ntpsec-systemd-netif.service. Jul 13 07:04:14 opz3 systemd[1]: ntpsec-systemd-netif.service: Deactivated successfully. Jul 13 07:04:15 opz3 systemd[1]: Started ntpsec-systemd-netif.service. Jul 13 07:04:15 opz3 systemd[1]: ntpsec-systemd-netif.service: Deactivated successfully. Jul 13 07:04:37 opz3 systemd[1]: ntpsec-systemd-netif.service: Start request repeated too quickly. Jul 13 07:04:37 opz3 systemd[1]: ntpsec-systemd-netif.service: Failed with result 'start-limit-hit'. Jul 13 07:04:37 opz3 systemd[1]: Failed to start ntpsec-systemd-netif.service. * What exactly did you do (or not do) that was effective (or ineffective)? Booted the system, expected no degraded system. * What was the outcome of this action? system degraded due to ntpsec-systemd-netif.service failed. * What outcome did you expect instead? No degraded system. I would suggest configuring much more lenient start limits if obtaining two leases is already too much for the current setup. Also, does the setup really work in the case of races (what happens when the unit is already running while another lease changes? Will it be started again after exiting?) In my case, I added an "ExecStartPre=sleep 5", which kind of works and avoids races in my setup, but that is not a reliable solution. It also reduces the number of invoxations during boot to two, which is a good indicator that the whole setup suffers from race conditions and is buggy because events are lost while the script runs.