Start from the error string. Diagnose before you change anything.
Troubleshooting articles on CodeNx are organised around the error string a reader is holding, because that is what people search for at the moment they need help.
Each one follows the same order: what the message means, the command that identifies which of several causes applies, the fix for each, and a verification step that proves the fix took effect on the running process rather than only in a config file.
The diagnosis step is not padding. Most error strings in this stack have more than one cause, and the fixes diverge sharply. “Too many open files” is either a limit set too low or a descriptor leak in the application — raising the limit resolves the first and merely postpones the second. “Connection timed out” from a CDN is a firewall; “connection refused” is a service that is not listening. Same shape of symptom, completely different work.
Three failure families account for most of what lands here. Kernel and process resource limits, which are inherited from a systemd unit rather than from your shell and therefore are not where people look. Networking, where a container runtime writing its own firewall rules invalidates the mental model most people bring from non-container hosts. And lifecycle, where a command returns success before the thing it started is actually able to serve.
Every fix here has been reproduced on a stated OS and version. Where a fix is version-sensitive, the article says so rather than presenting one answer as universal.
Start here
Diagnose which file descriptor limit you actually hit — container, daemon or kernel — then raise it properly, and work out whether the real problem is a leak rather than a limit.
A reading order that builds Fixes knowledge in the sequence it is actually needed.
Failure modes that come up repeatedly with Fixes, and where each one is solved.
Diagnose which file descriptor limit you actually hit — container, daemon or kernel — then raise it properly, and work out whether the real problem is a leak rather than a limit.
Diagnose which file descriptor limit you actually hit — container, daemon or kernel — then raise it properly, and work out whether the real problem is a leak rather than a limit.
Match the error string first, then run the diagnostic command before applying any fix. Applying a fix that matches the symptom but not the cause is how a five-minute problem becomes a two-hour one.
Because the same error string has several causes. "Too many open files" can be a limit that is too low or a descriptor leak, and raising the limit on a leak only delays the failure.
Version and locale change wording. Search for the distinctive middle of the message — a syscall name, an errno, a config key — rather than the whole line.