Summary
The fd-leak fix #108 ("fix(traefik): finite readTimeout on entrypoints to stop fd-leak unreachability", commit fd1d05b) is merged to main but in no released image tag, so no shard is actually running it.
Evidence
Impact
Without a finite entrypoint readTimeout, connections from public-IP scanning never close → traefik fds accumulate → EMFILE ("too many open files") → traefik stops accept4()-ing on all entrypoints → shard unreachable. This is the primary fault behind shard diagnostics 326, 331, 333. The nofile ceiling (controller v17 daemon.json) is only defense-in-depth; #108 is the actual fix and it is undeployed.
Ask
Summary
The fd-leak fix #108 ("fix(traefik): finite readTimeout on entrypoints to stop fd-leak unreachability", commit
fd1d05b) is merged to main but in no released image tag, so no shard is actually running it.Evidence
0.39.3is from 2026-06-05 — predates the fix.git tag --contains fd1d05b→ empty.0.39.3, so all shards run without the readTimeout fix.Impact
Without a finite entrypoint readTimeout, connections from public-IP scanning never close → traefik fds accumulate → EMFILE ("too many open files") → traefik stops
accept4()-ing on all entrypoints → shard unreachable. This is the primary fault behind shard diagnostics 326, 331, 333. The nofile ceiling (controller v17 daemon.json) is only defense-in-depth; #108 is the actual fix and it is undeployed.Ask
fd1d05b(e.g.0.39.4) and add a new controller core-version pinning it, so the readTimeout fix actually reaches shards. Note the MQTT:8883TCP entrypoint where HTTP respondingTimeouts don't apply — confirm fix(traefik): finite readTimeout on entrypoints to stop fd-leak unreachability #108 covers it or that nofile is the intended mitigation there.