tests: fix test_low_fd_limit failing on RLIM_INFINITY platforms
What the developer wrote
Authored by Níckolas Goline
tests: fix test_low_fd_limit failing on RLIM_INFINITY platforms
When RLIMIT_NOFILE hard limit is RLIM_INFINITY (macOS default) or
larger than UINT32_MAX, passing limits[1] and limits[1]+1 directly as
--dev-fd-limit-multiplier (a u32 option) causes lightningd to reject
the argument as out-of-range and exit(1), making both nodes fail to
start with "Unable to find Server started with public key" timeout.
Cap to TEST_CEILING=65536 when the hard limit is RLIM_INFINITY or
exceeds the ceiling, keeping the existing soft==hard halving path for
normal bounded limits.
Also add the test to the macOS CI list, so the platform it was broken
on now covers it.
Changelog-None
What changed, and why it matters
This commit fixes a test that was failing on macOS and other systems where the operating system reports no practical upper bound on the number of open files (called RLIM_INFINITY). The test was passing values larger than a 32-bit unsigned integer to a command-line option that only accepts 32-bit values, causing the tested program to reject the argument and the test to time out. The fix caps the test's file-descriptor limit to 65,536 and adds the test to the macOS CI list so it stays working. There is no security issue here—only a test reliability fix.
No security action needed. This is a test-only fix improving cross-platform CI reliability. Reviewers can merge after normal CI passes.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The change modifies tests/test_misc.py::test_low_fd_limit. Previously it halved the soft limit only when soft==hard. On macOS the hard RLIMIT_NOFILE is RLIM_INFINITY, and on some platforms it can exceed UINT32_MAX. The –dev-fd-limit-multiplier option is a u32, so passing limits[1] or limits[1]+1 caused lightningd option parsing to fail with an out-of-range error and exit(1), producing a node startup timeout. The patch introduces TEST_CEILING=65536, sets both soft and hard limits to bounded values when the hard limit is RLIM_INFINITY or exceeds the ceiling, and keeps the existing soft==hard halving path otherwise. It also adds the test to .github/workflows/macos.yaml. No production code is changed.
Changed components
tests/test_misc.py.github/workflows/macos.yamlInspect captured patch +11 / −2
diff --git a/.github/workflows/macos.yaml b/.github/workflows/macos.yaml
index 9346bb35..cf67a1e1 100644
--- a/.github/workflows/macos.yaml
+++ b/.github/workflows/macos.yaml
@@ -60,6 +60,7 @@ jobs:
PYTEST_OPTS: "-vvv --timeout=1800 --durations=10"
PYTEST_TESTS: |
tests/test_misc.py::test_ipv4_and_ipv6
+ tests/test_misc.py::test_low_fd_limit
tests/test_connection.py::test_websocket
tests/test_connection.py::test_wss_proxy
tests/test_plugin.py::test_inline_plugin_wait_for_log_no_selfmatch
diff --git a/tests/test_misc.py b/tests/test_misc.py
index 197140ee..48dea0a8 100644
--- a/tests/test_misc.py
+++ b/tests/test_misc.py
@@ -4998,8 +4998,16 @@ def test_set_feerate_offset(node_factory, bitcoind):
def test_low_fd_limit(node_factory, bitcoind):
limits = resource.getrlimit(resource.RLIMIT_NOFILE)
- # We assume this, otherwise l2 cannot increase limits!
- if limits[0] == limits[1]:
+ # dev-fd-limit-multiplier is a u32, so values > UINT32_MAX fail option
+ # parsing. macOS also reports RLIM_INFINITY as the hard limit, making
+ # "ask for more than the hard limit" meaningless. Cap to a bounded
+ # ceiling so the test works on any platform.
+ TEST_CEILING = 65536
+ if limits[1] == resource.RLIM_INFINITY or limits[1] > TEST_CEILING:
+ limits = (TEST_CEILING // 2, TEST_CEILING)
+ resource.setrlimit(resource.RLIMIT_NOFILE, limits)
+ elif limits[0] == limits[1]:
+ # We assume this, otherwise l2 cannot increase limits!
limits = (limits[1] // 2, limits[1])
resource.setrlimit(resource.RLIMIT_NOFILE, limits)
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.