Very long delay and error message with dhcpcd -k & dhcpcd -x

[peabee]

Slackware Current Sat Nov 15 00:38:46 UTC 2025 dhcpcd-10.3.0-x86_64-1.txz: Upgraded.

# dhcpcd -k
sending signal ALRM to pid 6284
waiting for pid 6284 to exit
..........very long delay then.........
pid 6284 failed to exit

also with dhcpcd -x

[rsmarples]

@peabee does dhcpcd actually exit though? If not, can you check logs / dmesg for any error?

[peabee]

Hello Roy Many thanks for your response. I can't see any errors in the logs or dmesg. There have been some other system updates since my original post and the output has changed ** however I am still seeing long delays during shutdown in some situations. Things go back to normal though if I revert to 10.2.4 As the delays happen during shutdown, I can't confirm whether dhcpcd exits. ** output when run in a terminal now:

# ps | grep dhcpcd
 7136 root      0:00 dhcpcd: wlan0 [ip4]

# dhcpcd -k
no such user dhcpcd
dhcpcd is not running

Thanks Peter

[luebking]

Subscribing w/ a tentative +1

I've had massive problems w/ the ifplugd and auto services from netctl after the last update, particularly when waking from S3 (services didn't act, restarting them required systemd to SIGKILL stuff)

After testing around a bit I noticed dhcpcd did not respond to direct SIGTERMs. There's nothing in dmesg. I've then switched to dhclient and the first try afterwards has shown no problems.

I'll wait some more S3 cycles (I don't want to rush them synthetically in case there's some HW or race involved) and then I guess you want to see backtraces of the hanging dhcpcd processes (they're not dormant/waiting for IO)?

[KrisQdt]

Hello,

I have the same issue on the version 10.2.2 & 10.0.6 on a linux-arm system

I have the following traces when i try to stop the daemon with the command dhcpcd -k

Jan 01 00:02:16 [362]: sending signal ALRM to pid 308 /* stop deamon dhcpcd / Jan 01 00:02:16 [362]: waiting for pid 308 to exit ... Jan 01 00:02:16 [309]: ps_root_writeerror: result 0 errno 0 Jan 01 00:02:16 [308]: ps_stopprocess: me=308 pid=310 fd=3 network proxy Jan 01 00:02:16 [309]: ps_recvpsmsg: fd=11 48 Jan 01 00:02:16 [309]: ps_root_recvmsgcb: IN cmd 21, psp (nil) Jan 01 00:02:16 [309]: ps_root_writeerror: result 0 errno 0 Jan 01 00:02:16 [310]: ps_recvpsmsg: fd=7 0 Jan 01 00:02:16 [310]: process 310 stopping Jan 01 00:02:16 [311]: ps_recvpsmsg: fd=14 0 Jan 01 00:02:16 [311]: process 311 stopping Jan 01 00:02:21 [308]: ps_process_timeout: timed out / timeout */ Jan 01 00:02:21 [309]: ps_recvpsmsg: fd=11 0 Jan 01 00:02:21 [309]: process 309 stopping

The process number are: 308 dhcpcd 4576 S dhcpcd: [manager] [ip4] [ip6] 309 root 4692 S dhcpcd: [privileged proxy] 310 dhcpcd 4420 S dhcpcd: [network proxy] 311 dhcpcd 4420 S dhcpcd: [control proxy]

What i understand it is that the processes 309,310 & 311 have received the signal SIGALRM to stop but they don't stop so process 308 doesn't receive the signal SIGCHLD. I can add some traces to help to understand if you need

logDhcpcdError.txt

[LoneFox78]

I noticed this problem on my laptop, and did some testing:

On wifi

• Using typical wireless bootscript, which shuts down wpa_supplicant before dhcpcd, this buggy behavior happens.
• But if wpa_supplicant is still running, dhcpcd exits with no problem.

On regular wired ethernet

• It normally works OK.
• If I unplug the cable and then try to shut down dhcpcd, the bug happens.

So, it works when the system is still connected to the network, but fails when it's not. I guess it is waiting forever for something from the DHCP server...