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.

Reply via email to