dhcpcd 10.5.2 (privsep) exits with status 1 on resume from hibernation: script_runreason: Interrupted system call / No such process

[gilgamezh]

Summary

On roughly half of my resumes from hibernation, dhcpcd (privsep, running as a systemd service on all interfaces) logs script_runreason: Interrupted system call twice, tears down the addresses/routes on wlan0, logs script_runreason: No such process twice, and then the main process exits with status 1. Nothing brings it back, so the laptop reconnects to Wi-Fi (iwd) but never gets an address until I systemctl restart dhcpcd by hand.

Plain suspend/resume never triggers it; only resume from hibernation (suspend-then-hibernate). Over the last 14 days it happened on 5 of 11 hibernation resumes.

This looks different from #609 (which was an eloop hang fixed in 10.5.1): here the daemon does not go unresponsive, it exits.

Environment

• dhcpcd 10.5.2 (Arch Linux package dhcpcd 10.5.2-1, privsep enabled: INET ARP ARPing IPv4LL INET6 DHCPv6 AUTH PRIVSEP)
• Linux 7.1.11-arch1-1, systemd 261.2
• Wi-Fi: MediaTek MT7925 (mt7925e), managed by iwd 3.12 with EnableNetworkConfiguration=false
• Started by the stock Arch unit: ExecStart=/usr/bin/dhcpcd -q -B

/etc/dhcpcd.conf (comments stripped):

clientid
persistent
vendorclassid
option domain_name_servers, domain_name, domain_search
option static_routes, classless_static_routes
option interface_mtu
option host_name
require dhcp_server_identifier
slaac private
noipv4ll

No custom hooks; only the stock 20-resolv.conf, 30-hostname, 50-timesyncd.conf.

Log (journal, one occurrence; all five are identical)

kernel: PM: hibernation: hibernation exit
kernel: mt7925e 0000:c0:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260605184651a
dhcpcd[176783]: script_runreason: Interrupted system call
dhcpcd[176783]: script_runreason: Interrupted system call
dhcpcd[176783]: wlan0: deleting address fd8a:403:d33f::2bd/128
kernel: wlan0: Driver requested disconnection from AP 00:00:00:00:00:00
dhcpcd[176783]: wlan0: deleting address fd8a:403:d33f:0:d679:4c6d:e4fe:4e3d/64
dhcpcd[176783]: wlan0: deleting route to fd8a:403:d33f::/64
dhcpcd[176783]: wlan0: deleting route to fd8a:403:d33f::/48 via fe80::dea6:32ff:fe3b:dbf7
dhcpcd[176783]: wlan0: deleting route to 192.168.222.0/24
dhcpcd[176783]: wlan0: deleting default route via 192.168.222.254
dhcpcd[176783]: script_runreason: No such process
dhcpcd[176783]: script_runreason: No such process
systemd[1]: dhcpcd.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: dhcpcd.service: Failed with result 'exit-code'.

All of that is stamped within the same second as hibernation exit. Three seconds later iwd reconnects to the AP fine, but there is no dhcpcd left. An earlier occurrence (2026-08-26, pid 690) also showed the message with the [privileged proxy] prefix:

dhcpcd[690]: privileged proxy][690]: script_runreason: Interrupted system call
dhcpcd[690]: script_runreason: Interrupted system call
dhcpcd[690]: script_runreason: No such process
dhcpcd[690]: privileged proxy][690]: script_runreason: No such process
systemd[1]: dhcpcd.service: Main process exited, code=exited, status=1/FAILURE

After a manual systemctl restart dhcpcd everything works normally (RA, DHCPv6 and DHCPv4 lease all obtained within ~10 s).

What I think is happening

The errors are reported from script_runreason() in the privsep path, i.e. ps_root_script() returned -1 with errno EINTR and then ESRCH. The link goes down/up during thaw, so the manager asks the privileged proxy to run the hook script for the carrier events right as the process tree is being unfrozen. The proxy's waitpid()/child handling for the hook script seems to get interrupted and then the child is gone (No such process), and the resulting error on the root stream is treated as fatal, so the manager exits with EXIT_FAILURE.

I would expect an EINTR/ESRCH while running a hook script to be retried or logged and ignored, rather than take the whole daemon down.

Workaround

A systemd drop-in with Restart=on-failure / RestartSec=2 brings it back within seconds.

Happy to test a patch or gather more info (e.g. run with -d until the next occurrence) if useful.

[rsmarples]

I would expect an EINTR/ESRCH while running a hook script to be retried or logged and ignored, rather than take the whole daemon down.

This is the crux of the matter. If something is interrupted in dhcpcd it will not continue, it will wait for the next event.
This will, by its very definition, put the system into an undefined state. Because the state is undefined dhcpcd just exits.
dhcpcd has always done this, even in the 1.x versions when DHCP is all it it.

Now dhcpcd has grown and it can restart protocols when instructed so it could potentially recover and continue rather than waiting for the next event.

POSIX notes that the default action of SIGINT is to terminate the process.
I am somewhat open to changing the handling of SIGINT as we have other signals like SIGTERM to exit - but maybe allow the current behaviour if we are still attached to a TTY. I don't know how systemd which you use would be affected here. Do you know?

[gilgamezh]

Hey! I'm traveling and don't have my laptop. but will report on a few weeks when I'm back

…

--- Nicolás Demarchi Sent from Proton Mail for Android.

-------- Original Message --------

On Friday, 09/11/26 at 18:33 Roy Marples ***@***.***> wrote: **rsmarples** left a comment (NetworkConfiguration/dhcpcd#722) > I would expect an EINTR/ESRCH while running a hook script to be retried or > logged and ignored, rather than take the whole daemon down. This is the crux of the matter. If something is interrupted in dhcpcd it will not continue, it will wait for the next event. This will, by its very definition, put the system into an undefined state. Because the state is undefined dhcpcd just exits. dhcpcd has always done this, even in the 1.x versions when DHCP is all it it. Now dhcpcd has grown and it can restart protocols when instructed so it could potentially recover and continue rather than waiting for the next event. POSIX notes that the default action of SIGINT is to terminate the process. I am somewhat open to changing the handling of SIGINT as we have other signals like SIGTERM to exit - but maybe allow the current behaviour if we are still attached to a TTY. I don't know how systemd which you use would be affected here. Do you know? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>