Fix: too many open files

Error: EMFILE: too many open files, open '/app/public/index.html'
OSError: [Errno 24] Too many open files: 'data/part-0931.csv'
accept: too many open files
nginx: [alert] socket() failed (24: Too many open files)
ENOSPC: System limit for number of file watchers reached
tail: inotify cannot be used, reverting to polling: Too many open files

Every open file, socket, pipe and directory listing costs a file descriptor, and each process has a limit on how many it may hold at once. Most Linux distributions default to 1024 per process (the soft limit), which a busy web server, database or build tool exhausts quickly. There is also a system-wide limit, and a separate limit for inotify watches that file-watching tools hit.

Step 1: see which limit you hit and who is using them

ulimit -n                      # soft limit for this shell and its children
ulimit -Hn                     # hard limit, the most a user may raise it to

# For a running process
cat /proc/48213/limits | grep 'open files'
ls /proc/48213/fd | wc -l      # how many it has open right now
sudo lsof -p 48213 | awk '{print $5}' | sort | uniq -c | sort -rn | head   # by type: REG, IPv4, unix, ...

# System-wide
cat /proc/sys/fs/file-nr       # allocated, free, maximum
sysctl fs.file-max

Cause 1: the per-process limit is simply too low

For the current shell session, raise the soft limit up to the hard limit. This is enough for a one-off command or a build.

ulimit -n 65536
npm run build          # or whatever failed

For login sessions, set the limit in /etc/security/limits.conf or a file in /etc/security/limits.d/; it applies after the next login.

# /etc/security/limits.d/90-nofile.conf
*        soft    nofile    65536
*        hard    nofile    524288
appuser  soft    nofile    262144
appuser  hard    nofile    524288

Cause 2: a systemd service ignores limits.conf

Services started by systemd do not go through PAM, so limits.conf has no effect on them. Set the limit in the unit.

sudo systemctl edit nginx.service
# add:
[Service]
LimitNOFILE=65536

sudo systemctl daemon-reload
sudo systemctl restart nginx.service
cat /proc/$(systemctl show -p MainPID --value nginx.service)/limits | grep 'open files'

Some daemons have their own setting on top: nginx worker_rlimit_nofile 65536; in nginx.conf, PostgreSQL max_files_per_process, MySQL open_files_limit, Elasticsearch requires 65536 and refuses to start below it. Docker containers inherit the daemon’s default; set --ulimit nofile=65536:65536 on docker run or ulimits: in Compose.

Cause 3: the application leaks descriptors

If ls /proc/PID/fd | wc -l grows steadily while traffic is flat, the program opens files or connections and never closes them. Raising the limit only delays the crash. Look at what the descriptors are: hundreds of the same log file means a logger opened per request; thousands of sockets in CLOSE_WAIT (ss -tanp | grep CLOSE-WAIT) means HTTP responses are not consumed or closed. Use with open(...) in Python, try/finally with close(), connection pools with limits, and stream.destroy() in Node.

Cause 4: inotify watches, not file descriptors

Webpack, Vite, nodemon, VS Code, tail -f, Syncthing and IDE indexers watch directories with inotify. The kernel limits watches per user, and the error says ENOSPC or mentions watchers even though no disk is full. Raise the limits and persist them.

sysctl fs.inotify.max_user_watches fs.inotify.max_user_instances

sudo sysctl fs.inotify.max_user_watches=524288
sudo sysctl fs.inotify.max_user_instances=512

# Persist
echo 'fs.inotify.max_user_watches=524288' | sudo tee /etc/sysctl.d/90-inotify.conf
echo 'fs.inotify.max_user_instances=512' | sudo tee -a /etc/sysctl.d/90-inotify.conf
sudo sysctl --system

# Who uses the watches
find /proc/*/fd -lname 'anon_inode:inotify' -printf '%h\n' 2>/dev/null | cut -d/ -f3 | sort | uniq -c | sort -rn | head

Also exclude node_modules, .git and build output from the watcher’s configuration; a watcher that follows a 200,000-file dependency tree is the usual reason the default is not enough.

Check that it is fixed

ulimit -n                                    # new shell shows the new value
cat /proc/PID/limits | grep 'open files'     # the service shows LimitNOFILE
watch -n5 'ls /proc/PID/fd | wc -l'          # stable, not climbing

When it is not what you think

• ENFILE (Too many open files in system) is the system-wide limit fs.file-max, hit only when the whole machine is in trouble, often because one process leaked millions.
• ENOSPC: no space left on device from a file watcher is the inotify limit (Cause 4), not a full disk; df -h will look fine.
• On macOS the default soft limit is 256; ulimit -n 65536 works per shell, and launchctl limit maxfiles shows the system values. Node and Docker Desktop hit this on large projects.
• A hard limit you cannot raise as a normal user (ulimit -Hn small) must be raised by root in limits.conf or via systemd’s DefaultLimitNOFILE in /etc/systemd/system.conf and user.conf.

Official documentation

• getrlimit(2): RLIMIT_NOFILE and limits.conf(5)
• systemd.exec: LimitNOFILE=
• inotify(7): /proc interfaces and limits