Fixing 'Too Many Open Files' Errors on Linux
An application errors out with EMFILE or ENFILE, even though the system clearly isn't out of resources in any obvious sense. Here's how to find and raise the actual limit involved.
“Too many open files” is Linux enforcing a deliberate limit on how many file descriptors a process (or the system as a whole) may hold open at once — the fix is identifying which specific limit was hit and raising it appropriately, not assuming something is broken.
Step 1: confirm the exact error and which limit it implies
EMFILE: too many open files (per-process limit)
ENFILE: too many open files in system (system-wide limit)EMFILE means one specific process hit its own limit; ENFILE means the entire system’s combined open-file count hit its ceiling — these have different fixes, so identifying which one is actually occurring (check application logs or strace output for the specific errno) matters before changing anything.
Step 2: check the current per-process limit
ulimit -n
cat /proc/<pid>/limits | grep "Max open files"The default per-process soft limit (often 1024) is frequently too low for a server process handling many concurrent connections, each of which typically needs its own file descriptor.
Step 3: check the system-wide limit
cat /proc/sys/fs/file-max
cat /proc/sys/fs/file-nrfile-nr’s first number is the system’s current total open file count; comparing it against file-max shows how close the entire system is to its ceiling, distinct from any individual process’s own limit.
Step 4: raise the per-process limit for a specific user or service
# /etc/security/limits.conf
myappuser soft nofile 65536
myappuser hard nofile 65536This requires the affected user to log in again (or the service to restart) for the new limit to take effect — a common reason a limits.conf change appears not to work is simply not having restarted the relevant session or service afterward.
Step 5: raise the limit for a systemd-managed service specifically
# in the unit's [Service] section, or via a drop-in:
LimitNOFILE=65536systemctl daemon-reload
systemctl restart myserviceServices started by systemd don’t necessarily inherit /etc/security/limits.conf settings the way an interactive login shell does — the limit needs to be set directly in the unit file for services specifically.
Step 6: raise the system-wide ceiling if needed
sysctl -w fs.file-max=2097152
echo "fs.file-max=2097152" >> /etc/sysctl.confOnly necessary if Step 3 showed the system-wide count approaching file-max — raising a per-process limit alone won’t help if the system-wide ceiling is the actual constraint.
Step 7: check for a file descriptor leak rather than just raising limits
ls /proc/<pid>/fd | wc -l
lsof -p <pid>A process whose open file count climbs continuously over time, rather than stabilizing at some working-set size, usually has a genuine file descriptor leak (files or sockets opened but never closed) — raising the limit delays the eventual crash without fixing the underlying bug.
Why identifying EMFILE vs. ENFILE first saves real time
Raising a per-process limit does nothing if the actual constraint is the system-wide ceiling, and vice versa — confirming which specific error and which specific limit is actually being hit, before changing any configuration, avoids the common mistake of raising the wrong limit and concluding (incorrectly) that the fix “didn’t work.”