If networking.service is restarted (needrestart defaults to not restarting
it but will list it in the services that need to restart to take the
current configuration) then kea-dhcp4 won't work after that until it is
restarted.

I expect that the system will just sort it out.  kea-dhcp4-server.service
could be restarted by systemd as a dependency on networking it systemd
was setup in that way.  The kea process could just notice that the interface
went down and up and it could reonfigure itself.  A final option would be
for the daemon to recognise it as a fatal error condition and abort in which
case systemd would restart it and the service would end up in a good state.

Below are the relevant logs of a system where this happened:

Jul 22 13:18:27 usagi systemd[1]: Stopping networking.service - Raise network interfaces...
Jul 22 13:18:27 usagi kea-dhcp4[3427066]: 2025-07-22 13:18:27.636 ERROR [kea-dhcp4.packets/3427066.139656111945664] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Pkt4FilterLpf to receive UDP4 data
Jul 22 13:18:28 usagi systemd[1]: networking.service: Deactivated successfully.
Jul 22 13:18:28 usagi systemd[1]: Stopped networking.service - Raise network interfaces.
Jul 22 13:18:28 usagi systemd[1]: networking.service: Consumed 2min 32.148s CPU time, 40.8M memory peak.
Jul 22 13:18:28 usagi systemd[1]: Starting networking.service - Raise network interfaces...
Jul 22 13:19:08 usagi systemd[1]: Finished networking.service - Raise network interfaces.

After that there were no log entries about DHCP requests being received, so the
service was not operating.

Hi,

we’re currently trying to debug/fix a set of interconnected issues
in the KEA DHCP/DHCP6 server which involve systemd as well:


One is that, when the services start, the network is not precisely
up and working yet, and so it logs…

Apr 21 09:29:11 debian kea-dhcp4[1634]: WARN  DHCPSRV_NO_SOCKETS_OPEN no interf[…]

… but starts successfully despite not working.

It already has…

Wants=network-online.target
After=network-online.target

… which a coworker who knows systemd better says ought to suffice,
but it turns out (in his debugging experiments) that network-online
can still have the network interfaces in DOWN state.

Restarting the service once the system has booted makes it work.

I think this is something we need to address by a code change (abort
instead of continuing when this particular error occurs) plus a change
in the unit to let systemd attempt to restart it… can it do this with
a backoff (i.e. first after 30s, then after a minute, then after 3min,
etc.)?


The other is that KEA DHCPD (both v4 and v6) must be restarted when
the network is restarted. Am I correct that keeping the After= from
above and changing the Wants= into BindsTo=network-online.target will
do that?

(KEA maintainers, is this also needed for the third (DDNS) service?)


Thanks in advance,
//Thorsten

forwarded 1109690 https://gitlab.isc.org/isc-projects/kea/-/issues/4469
thanks

Turns out that this will most likely be a one-liner; I’ve already
identified the correct place in the code as it’s the only one that
throws this warning.

https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/lib/dhcpsrv/cfg_iface.cc#L92-94

Same code (lines 172ff.) in the 3.0.3 currently in testing/sid.
Changing that to somehow abort with an error, plus…

… this (someone who knows systemd please jump in) could do the trick.

Gruß
//Thorsten