Part of #9222.
Seen on a PR CI run (Valgrind Test CLN 7/12):
https://github.com/ElementsProject/lightning/actions/runs/30115026145/job/89556718080
tests/test_misc.py::test_emergencyrecoverpenaltytxn stops l1 and later
starts it again. The restart failed:
lightningd-1 2026-07-24T18:36:18.268Z BROKEN connectd: Failed to bind socket for 127.0.0.1:38381: Address already in use
TimeoutError: Unable to find "[re.compile('Server started with public key')]" in logs.
connectd is a separate process and exits on its own schedule after
lightningd is gone; under valgrind its teardown can lag tens of
seconds. In this run the old connectd logged 'Shutting down' at
18:35:41 and the new one's bind still failed at 18:36:18. Nothing in
the test harness waits for the old process to release the listen
socket before relaunching.
The filesystem port locks from #9211 don't cover this case: they keep
other pytest workers from reserving the port, but the restarting node
owns its reservation both times.
Any test that restarts a node can hit this. It reproduces
deterministically by holding the node's port from the test process
for a few seconds after stop() and then calling start().
Part of #9222.
Seen on a PR CI run (Valgrind Test CLN 7/12):
https://github.com/ElementsProject/lightning/actions/runs/30115026145/job/89556718080
tests/test_misc.py::test_emergencyrecoverpenaltytxn stops l1 and later
starts it again. The restart failed:
lightningd-1 2026-07-24T18:36:18.268Z BROKEN connectd: Failed to bind socket for 127.0.0.1:38381: Address already in use
TimeoutError: Unable to find "[re.compile('Server started with public key')]" in logs.
connectd is a separate process and exits on its own schedule after
lightningd is gone; under valgrind its teardown can lag tens of
seconds. In this run the old connectd logged 'Shutting down' at
18:35:41 and the new one's bind still failed at 18:36:18. Nothing in
the test harness waits for the old process to release the listen
socket before relaunching.
The filesystem port locks from #9211 don't cover this case: they keep
other pytest workers from reserving the port, but the restarting node
owns its reservation both times.
Any test that restarts a node can hit this. It reproduces
deterministically by holding the node's port from the test process
for a few seconds after stop() and then calling start().