dhcpcd invocation as done by cloud-init never returns

[thresheek]

Hello!

We've noticed that after an Alpine 3.23/3.24 upgrade to dhcpcd 10.5.2 (from 10.3.2, which does not exhibit the issue), system boot up time is much longer than it previously was, from the seconds to at least five minutes until networking/SSH access is available. This bug is tracked over at https://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/work_items/194 .

Looking at the cloud-init logs, it seems the following invocation hangs indefinitely and is getting killed due to a timeout in the Python code:

2026-09-23 22:44:15,613 - performance.py[DEBUG]: Running ['dhcpcd', '--ipv4only', '--waitip', '--persistent', '--noarp', '--debug', '--script=/bin/true', 'eth0'] took 300.101 seconds

Now, when I use a dhcpcd binary from 10.3.2 release (either self-built, or a version that was available in Alpine prior to 10.5.2 bump), this command exits quite fast:

2026-09-23 23:33:39,547 - performance.py[DEBUG]: Running ['dhcpcd', '--ipv4only', '--waitip', '--persistent', '--noarp', '--debug', '--script=/bin/true', 'eth0'] took 2.031 seconds

I've git bisect'ed the commits between v10.3.2 and the current master (5a91691), with the following git bisect log:

git bisect start
# status: waiting for both good and bad commits
# good: [243ad84ac67a87d631ff7eb83b2eed2727acebb5] Release dhcpcd-10.3.2
git bisect good 243ad84ac67a87d631ff7eb83b2eed2727acebb5
# status: waiting for bad commit, 1 good commit known
# bad: [5a91691c65f063551553116ca73f2163ad951c9c] dhcpcd: size the escaped-SSID buffers for the worst case
git bisect bad 5a91691c65f063551553116ca73f2163ad951c9c
# bad: [06f84e4a3f69754a5ece70919edd31ff7e191c3d] ND6: fix OOB reject mask for an undefined option
git bisect bad 06f84e4a3f69754a5ece70919edd31ff7e191c3d
# bad: [082d1f2c1c68ea55744587b664f61d954fb549d1] script: Don't assume AF_PACKET of if not AF_LINK
git bisect bad 082d1f2c1c68ea55744587b664f61d954fb549d1
# good: [0a523884dfadc8dac9ccd730d1178c090e69c1aa] Merge pull request #607 from NetworkConfiguration/bpf
git bisect good 0a523884dfadc8dac9ccd730d1178c090e69c1aa
# bad: [162e68b922a6b6621d349f7aa009ee223208cd67] eloop: fix USE_PPOLL define
git bisect bad 162e68b922a6b6621d349f7aa009ee223208cd67
# good: [97595a0fee0a4187ad98991356873df812044dd6] eloop: always remove event from list on delete
git bisect good 97595a0fee0a4187ad98991356873df812044dd6
# skip: [6b8d4e11ffedd1d2e02c987a94c2c8569ac28be1] eloop: Add eloop_openfdwaiter() and eloop_closefdwaiter()
git bisect skip 6b8d4e11ffedd1d2e02c987a94c2c8569ac28be1
# good: [61b64b96eb199ba95b19e92fb011e0373202b49f] DHCP6: Delete the eloop event before closing an ia listener socket
git bisect good 61b64b96eb199ba95b19e92fb011e0373202b49f
# bad: [620188969138523473a390c6a69166d4587673e6] privsep: Adapt to new eloop_waitfd()
git bisect bad 620188969138523473a390c6a69166d4587673e6
# only skipped commits left to test
# possible first bad commit: [620188969138523473a390c6a69166d4587673e6] privsep: Adapt to new eloop_waitfd()
# possible first bad commit: [6b8d4e11ffedd1d2e02c987a94c2c8569ac28be1] eloop: Add eloop_openfdwaiter() and eloop_closefdwaiter()

And indeed, manually reverting those two patches I can confirm that the hangup is no longer there and the command takes a couple of seconds max to exit, so the boot time is reverted back to normal.

[thresheek]

This seems very related: #733