#1147284 ifupdown: the DHCP client shares the interface's lifecycle, so losing the client costs the interface with no way back

Package:
ifupdown
Source:
ifupdown
Description:
high level tools to configure network interfaces
Submitter:
Aleksandr Petrov
Date:
2026-09-10 12:09:02 UTC
Severity:
normal
#1147284#5
Date:
2026-09-10 12:00:04 UTC
From:
To:
Dear Maintainer,

On a Debian 12 server the kernel OOM killer took dhclient, and the
interface went down with it and stayed down. Versions: ifupdown 0.8.41,
systemd 252.39-1~deb12u2, isc-dhcp-client 4.4.3-P1-2; virtio NIC,
`iface eth0 inet dhcp`, no drop-ins on the unit.

ifupdown starts the DHCP client with a plain fork (inet.defn: `dhclient
-4 -v $CLIENT -pf /run/dhclient.%iface%.pid ...`), so the client lives in
the cgroup of ifup@<iface>.service. systemd's DefaultOOMPolicy=stop then
reads the kill as the unit failing and runs ExecStop=/sbin/ifdown:

  systemd[1]: ifup@eth0.service: A process of this unit has been killed
              by the OOM killer.
  ifdown[NNN]: DHCPRELEASE of 10.x.x.x on eth0 to 10.x.x.1 port 67
  systemd[1]: ifup@eth0.service: Failed with result 'oom-kill'.

A healthy, forwarding interface was deconfigured and its address
released while hours of lease remained. The default route was gone for
32 hours until someone noticed by hand.

There is no way to restart just the client. ifupdown has no notion of
the DHCP client as a thing that can be managed on its own: there is one
state, "interface is configured", and the client is an implementation
detail of it. Restarting the unit tears the interface down first, and
suppressing ExecStop makes the restart a no-op, since ifup is idempotent
against /run/network/ifstate and it is ifdown that clears it.

There is also no way back unattended: the only automatic trigger for
ifup@ is a udev "add" event, and ifdown does not remove the device, so
no second "add" can arrive.

Every other stack in Debian models this differently -- dhcpcd@ is a
per-interface unit with Restart=always, systemd-networkd runs the client
inside its own process, NetworkManager keeps external clients under its
own child watch. ifupdown is the one place where the client's death is
indistinguishable from the interface's failure.

I am not proposing a patch: the knobs available on the unit each trade
one bad outcome for another, and the direction that would resolve it is
the one #780882 (2015) points at -- give the client a life of its own,
so that losing it is recoverable without touching the link.

Thanks for maintaining ifupdown.