Public bug reported:
dhcpcd 1:10.5.2-4 (currently in stonking-proposed) has a regression from
10.3.2: once it daemonises, the daemon keeps the stdout/stderr it inherited
instead of redirecting them to /dev/null. Any caller that reads dhcpcd's
output through a pipe waits for an end-of-file that never comes, so it
hangs forever, even though the lease has been applied.
[Impact]
* netplan.io autopkgtest "wifi" (test_wifi_ap_open) hangs until the
autopkgtest timeout, blocking dhcpcd migration. The test runs:
subprocess.check_output(['dhcpcd', '-w', '-d', dev],
stderr=subprocess.STDOUT, text=True)
(tests/integration/wifi.py:212)
Failing runs (amd64, all hang in test_wifi_ap_open):
https://autopkgtest.ubuntu.com/results/autopkgtest-stonking/stonking/amd64/n/netplan.io/20260919_064946_ae19d@/log.gz
https://autopkgtest.ubuntu.com/results/autopkgtest-stonking/stonking/amd64/n/netplan.io/20260923_080537_14c28@/log.gz
https://autopkgtest.ubuntu.com/results/autopkgtest-stonking/stonking/amd64/n/netplan.io/20260926_144530_4f263@/log.gz
https://autopkgtest.ubuntu.com/results/autopkgtest-stonking/stonking/amd64/n/netplan.io/20260927_133731_55e53@/log.gz
migration-reference/0 passes (dhcpcd 1:10.3.2-6).
* cloud-init runs dhcpcd the same way for ephemeral DHCP
(dhcpcd --ipv4only --waitip --persistent --noarp ...). Upstream has a
report that this hangs until cloud-init's 300s timeout with 10.5.2,
delaying boot (Alpine: upstream issue #737). This may affect real
Ubuntu cloud boots too, not only tests.
[Root cause]
Upstream commit 62018896 made the privsep setrlimit(RLIMIT_NOFILE, {0,0})
unconditional, so it now applies on Linux too. On Linux, dup2(oldfd,
newfd) fails with EBADF once newfd >= RLIMIT_NOFILE. As a result, the
dup2() calls in dhcpcd_daemonised() that should point fds 1/2 at
/dev/null fail, and the return value is not checked.
[Test case]
dhcpcd --ipv4only --waitip --persistent --noarp <iface> | cat
* 10.3.2: returns after the lease is acquired.
* 10.5.2: the lease is applied but the command never returns.
* /proc/<dhcpcd pid>/fd/1 and fd/2 point to the pipe instead of
/dev/null.
[Upstream]
* https://github.com/NetworkConfiguration/dhcpcd/issues/716
* https://github.com/NetworkConfiguration/dhcpcd/issues/737
* Proposed fix (not merged yet):
https://github.com/NetworkConfiguration/dhcpcd/pull/733
"privsep: Fix daemonising broken by RLIMIT_NOFILE of 0"
(caps RLIMIT_NOFILE at STDERR_FILENO + 1 instead of 0)
[Proposed resolution]
Cherry-pick PR #733 into the Ubuntu package (and forward it to Debian),
then retry the netplan.io autopkgtests.
[Related]
LP: #2131252 (earlier, different pipe/stdin issue in dhcpcd on noble)
** Affects: dhcpcd (Ubuntu)
Importance: Undecided
Assignee: Nick Rosbrook (enr0n)
Status: New
** Affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** Tags: regression-proposed stonking update-excuse
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** Changed in: dhcpcd (Ubuntu)
Assignee: (unassigned) => Nick Rosbrook (enr0n)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2168834
Title:
dhcpcd 10.5.2 does not close stdout/stderr when daemonising, callers
reading its output hang
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dhcpcd/+bug/2168834/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
