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.

On further investigation, races seem to be a well-known issue with path
units:

https://github.com/systemd/systemd/issues/5770

This suggests that the implementation using path units is fundamentally
flawed and cannot be fixed using systemd. The only simple way to tackle
this Imcame up with is by having the script somehow start watching for
changes itself while it runs.

On filesystems with subsecond mtime resolution (which is likely true
for /run as it usually uses tmpfs), this could be fixed by stat'ing
/run/systemd/netif/leases when the script starts to run (e.g. stat +c%y),
and then testing again at the end. if the mtime has changed, the script
should loop (possibly with a a delay of a few seconds for busy systems).