Package: ifupdown Version: 0.8.41 Severity: normal 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]: [email protected]: 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]: [email protected]: 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.
