"Too many open files" errors occur when a process exceeds the maximum number of file descriptors it's allowed to have open simultaneously — a common issue for busy web servers, databases, or applications handling many concurrent connections.
Why This Happens
Linux limits how many files (including network sockets, which count as file descriptors) a process can have open at once — default limits are often conservative, set for typical desktop use rather than high-concurrency server workloads.
Checking Current Limits
ulimit -nShows the current soft limit for the current shell session — often defaults to 1024, frequently too low for a busy production server.
Checking a Specific Process's Actual Open File Count
ls /proc/PID/fd | wc -lCompare against the configured limit to confirm the process is genuinely approaching or hitting its limit.
Checking System-Wide Limits
cat /proc/sys/fs/file-maxIncreasing Limits Temporarily (Current Session Only)
ulimit -n 65536Increasing Limits Permanently (System-Wide)
sudo nano /etc/security/limits.conf* soft nofile 65536
* hard nofile 65536Increasing Limits for a Specific systemd Service
sudo systemctl edit nginx[Service]
LimitNOFILE=65536systemd services don't automatically inherit /etc/security/limits.conf settings — they need this explicit override for their specific unit.
Reloading and Restarting the Service
sudo systemctl daemon-reload
sudo systemctl restart nginxVerifying the New Limit Applied
cat /proc/PID/limits | grep "Max open files"Increasing the System-Wide Maximum (If Needed)
sudo nano /etc/sysctl.conffs.file-max = 2097152sudo sysctl -pRarely needed unless you're running an exceptionally high number of concurrent processes/connections across the entire system, not just one specific service.
Application-Level Considerations
If a specific application is genuinely leaking file descriptors (opening files/connections without properly closing them), raising limits only delays the problem rather than fixing the underlying leak — investigate whether the growth in open files is expected for your actual load, or indicates an application bug.
Common Errors
Limit increase in limits.conf doesn't seem to apply — verify you're checking the limit for a genuinely new session/process started after the change, and remember systemd services need their own explicit override, not just the global limits.conf setting.
Continue Reading
- How to Manage Kernel Parameters with sysctl
- Nginx Performance Tuning: Worker Processes, Caching & Gzip
- How to Diagnose a Slow VPS: Complete Performance Checklist
Browse more articles in Troubleshooting & FAQ.
