Problem
The ulimit -Sn {{ .Values.fileDescriptorLimit | int }} || exit 1 entrypoints added to nico-pxe, nico-hardware-health, and nico-ssh-console-rs (#4960, #5262) crashloop on any runtime whose container hard nofile limit is below the 65536 default. Reproduced on dev6: the containerd hard limit there is 65535 — one below the default — so all three deployments CrashLoopBackOff on a current main deploy, with only dash's terse ulimit: error setting limit (Invalid argument) as diagnostic.
A second failure mode from the same line: a fileDescriptorLimit: null override (Helm null deletes the chart default) or a non-numeric value renders ulimit -Sn 0, which dash accepts — the server then starts with zero usable FDs and fails with misleading I/O errors.
Fix
In all three chart entrypoints:
- Clamp to the runtime hard limit:
h=$(ulimit -Hn); [ "$N" -gt "$h" ] && N=$h (or echo a clear error before exiting).
- Guard the template against null/non-numeric:
| default 65536 | int plus a positivity check (or required).
- Extend the chart unittests to cover both.
Consider the v2.0 backport (#5263) — same line, and a stable-line patch upgrade should not be able to crashloop a working PXE service.
Follow-up question (separate)
The 65536 default exists because of FD exhaustion during high-concurrency ingestion (#4955). Whether that consumption is a genuine leak (needs a code fix before prod) or legitimate concurrent-connection load (raising the limit is the right call) has not been established — worth a profiling pass on ssh-console/hardware-health FD usage under ingestion load.
Problem
The
ulimit -Sn {{ .Values.fileDescriptorLimit | int }} || exit 1entrypoints added to nico-pxe, nico-hardware-health, and nico-ssh-console-rs (#4960, #5262) crashloop on any runtime whose container hard nofile limit is below the 65536 default. Reproduced on dev6: the containerd hard limit there is 65535 — one below the default — so all three deployments CrashLoopBackOff on a current main deploy, with only dash's terseulimit: error setting limit (Invalid argument)as diagnostic.A second failure mode from the same line: a
fileDescriptorLimit: nulloverride (Helm null deletes the chart default) or a non-numeric value rendersulimit -Sn 0, which dash accepts — the server then starts with zero usable FDs and fails with misleading I/O errors.Fix
In all three chart entrypoints:
h=$(ulimit -Hn); [ "$N" -gt "$h" ] && N=$h(or echo a clear error before exiting).| default 65536 | intplus a positivity check (orrequired).Consider the v2.0 backport (#5263) — same line, and a stable-line patch upgrade should not be able to crashloop a working PXE service.
Follow-up question (separate)
The 65536 default exists because of FD exhaustion during high-concurrency ingestion (#4955). Whether that consumption is a genuine leak (needs a code fix before prod) or legitimate concurrent-connection load (raising the limit is the right call) has not been established — worth a profiling pass on ssh-console/hardware-health FD usage under ingestion load.