Hi Torsten, On Tue, Nov 11, 2025 at 10:12:14PM +0100, Thorsten Glaser wrote: > >I can see it tries to DISCOVER a couple of times, goes to sleep, tries > >again but then it's not heard from again with no process left behind - > >until I restarted the interface at 21:02. > > That’s roughly what I expect from dhclient, actually. > If there’s no DHCP response for $smallnum minutes after > the system come up, to give up and exit anyway, so the > boot process continues and the local admin can login on > the console and fix the situation (e.g. net.ifnames=0 on > the kernel command line and reboot to fix interface names).
You're right it should not block ifup, that's why it forks into the
background to keep running in normal operation - which is what happened
here.
I just tried to reproduce this in a both a sid and bookworm debvm and the
behaviour is as I'd expect it forks into the background after $timeout and
keeps trying DISCOVER at $retry interval seemingly forever. I lowered all
of timeout/retry/reboot to 10s to observe multiple cycles.
To simulate the DHCP server not responding I used tc-netem - remember that
DHCP clients use raw sockets which bypass nftables:
$ tc qdisc add dev enp0s2 root netem loss 100%
$ ifup enp0s2; journalctl -t dhclient -f
--Daniel
signature.asc
Description: PGP signature
