Below is the relevant section of /etc/network/interfaces:

auto br0
iface br0 inet static
  address 10.0.0.1
  network 10.0.0.0
  netmask 255.255.0.0
  broadcast 10.0.255.255
  bridge_ports ethtopl ethtopr ethbl ethbr
  bridge_stp on
  bridge_fd 3
  bridge_hello 1
  up /usr/local/sbin/firewall

Below are the errors from systemctl status kea-dhcp4-server.service:

Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.229 INFO  [kea-dhcp4.dhcpsrv/2029.140300455860160] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv.2
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.229 INFO  [kea-dhcp4.dhcpsrv/2029.140300455860160] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.229 INFO  [kea-dhcp4.dhcpsrv/2029.140300455860160] DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4 extracting extended info saw 21 leases, extended info sanity checks modified 0 / updated >
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.230 INFO  [kea-dhcp4.dhcpsrv/2029.140300455860160] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.230 WARN  [kea-dhcp4.dhcpsrv/2029.140300455860160] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface br0 is not running
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.230 INFO  [kea-dhcp4.dhcp4/2029.140300455860160] DHCP4_OPEN_SOCKETS_FAILED maximum number of open service sockets attempts: 0, has been exhausted without success
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.230 WARN  [kea-dhcp4.dhcpsrv/2029.140300455860160] DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.230 INFO  [kea-dhcp4.dhcpsrv/2029.140300455860160] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 10.0.0.0/16
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.232 WARN  [kea-dhcp4.dhcp4/2029.140300455860160] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 18, queue size: 64
Nov 10 23:23:34 xev kea-dhcp4[2029]: 2025-11-10 23:23:34.232 INFO  [kea-dhcp4.dhcp4/2029.140300455860160] DHCP4_STARTED Kea DHCPv4 server version 2.6.3 started

The end result is that it is not serving DHCP.

I run systemctl restart kea-dhcp4-server.service and then it's fine.

This happens if serving on *any* interface, even not bridges.

Apr 20 20:42:12 b1v0 kea-dhcp4[744]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface eth1 is not running

“ip a” shows it’s up:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:ad:fd:3c brd ff:ff:ff:ff:ff:ff
    altname enp8s0
    altname enx525400adfd3c
    inet 10.32.4.161/28 brd 10.32.4.175 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fead:fd3c/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

/e/n/i snippet:

auto eth1
iface eth1 inet static
        address 10.32.4.161/28

And this is even on a system with systemd (test VM).

And, indeed, it fails to serve until I do…

tg@b1v0:~$ sudo systemctl restart kea-dhcp4-server.service

… after which it works as advertised, and very quickly.

This is a showstopper for server use; raising severity accordingly.

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

I’ve found a way to query the service for this status.

$ echo '{"command":"status-get"}' | sudo socat UNIX:/run/kea/kea4-ctrl-socket - | jq '.arguments.sockets | [.status, .errors] == ["ready", null]'

If the result is not `true`, then the service needs to be
restarted once network is available.

I’ll throw this into the check_mk plugin I’m writing first,
to get an idea of how many systems this affects. Upstream’s
https://gitlab.isc.org/isc-projects/kea/-/issues/4469 isn’t
being responded to at the moment, but I hope they discuss a
change so that it aborts on that error.

bye,
//Thorsten

I'm lowering the severity to important, as the package is not in Policy
violation and this bug does not make it "completely unusable to everyone".

The definition of "network is online" is tricky (Which interfaces should
be UP? Is the link being UP enough or do we want an IP and/or IPv6 too?
Should there be a default route? How long to wait for discovery via
DHCP, DHCPv6, IPv6 RA, BGP, ...? Should a DNS be configured?)

I believe systemd-network has some better heuristics than ifupdown
regarding this, see systemd-networkd-wait-online.service(8).

I suggest trying to switch the network config to systemd-networkd to see
if that helps. That may also help with #1109690.

Yes.

That’s not an option.

I still think that KEA should just error out if it cannot create the
corresponding sockets, but that’s probably something where you would
not want to deviate from upstream, *and* I’ve found out how to check
for that error condition using the management API, so I’m ok waiting
for upstream to decide and to keep the bug open but on hold for now.

With monitoring, we’ll see how many systems this even affect and add
a restart job where needed.

Gruß
//Thorsten