Fix "Too many open files" on Linux

# current shell (up to the hard limit)
ulimit -n 65536
# a systemd service
sudo systemctl edit myapp.service
#   [Service]
#   LimitNOFILE=65536
sudo systemctl restart myapp.service

The message comes in several forms, often wrapped in an application error:

Too many open files
accept4: too many open files
socket: too many open files
OSError: [Errno 24] Too many open files
Failed to create inotify instance: Too many open files

What the error means

Every open file, socket, pipe and inotify instance uses a file descriptor. Each process has a limit on how many it can hold at once, the RLIMIT_NOFILE, with a soft value (what applies now) and a hard value (the ceiling the soft value can be raised to without root). When a process tries to open one more, the kernel returns EMFILE, shown as "Too many open files" (errno 24).

The default soft limit is low for historical reasons: 1024 on most distros, because some old programs break with larger numbers. systemd sets the hard limit much higher (524288 on current releases), so most programs can raise their own soft limit if they ask.

ulimit -Sn
ulimit -Hn
# for a running process:
grep 'open files' /proc/$(pidof -s nginx)/limits

Example output:

Max open files            1024                 524288               files

Step 1: is it a leak or a real need?

Before raising limits, check how many descriptors the process actually holds and what they are:

PID=$(pidof -s myapp)
ls /proc/$PID/fd | wc -l
sudo lsof -p $PID | awk '{print $5}' | sort | uniq -c | sort -rn

Run it a few times. A count that climbs steadily while load stays the same is a leak (files or sockets never closed, often connections in CLOSE_WAIT, visible with ss -tanp). Raising the limit only delays the crash; the application needs fixing or a restart schedule. A count that matches the number of clients or open data files is a genuine need, and raising the limit is the right fix.

Cause 1: a systemd service with the default limit

This is the most common case on servers: web servers, databases, proxies, Node.js or Java apps under heavy load. Services get their limits from the unit file, not from your shell or limits.conf. Add a drop-in:

sudo systemctl edit myapp.service

Enter:

[Service]
LimitNOFILE=65536

sudo systemctl restart myapp.service
grep 'open files' /proc/$(systemctl show -p MainPID --value myapp)/limits

A drop-in survives package upgrades, unlike edits to the unit file in /usr/lib/systemd/system/. To change the default for all services, set DefaultLimitNOFILE= in a file under /etc/systemd/system.conf.d/ and run sudo systemctl daemon-reexec, but per-service limits are cleaner. See systemd basics for drop-ins, and Job for service failed if the service no longer starts.

For Docker containers, set the limit per container with --ulimit nofile=65536:65536 or ulimits: in Compose; the daemon's own LimitNOFILE sets the default.

Cause 2: your login shell has a low limit

Build tools, test runners and scripts started from a terminal inherit your session's limit. Raise it for the current shell (up to the hard limit):

ulimit -n 65536

To make it permanent for logins (SSH, console, desktop), add a file under /etc/security/limits.d/:

# /etc/security/limits.d/90-nofile.conf
alice  soft  nofile  65536
alice  hard  nofile  524288

Log out and back in. This works because pam_limits applies it at login. Graphical sessions are started through systemd's user manager, so for desktop apps you may also need DefaultLimitNOFILE= in /etc/systemd/user.conf.d/*.conf.

Cause 3: inotify limits (file watchers)

IDEs, webpack, vite, Syncthing, Dropbox and tail -f use inotify. Creating an inotify instance beyond fs.inotify.max_user_instances also returns "Too many open files", even though your descriptor limit is fine. Watching too many files (max_user_watches) gives "No space left on device" instead, which confuses people; see No space left on device.

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

Cause 4: the system-wide limit (Too many open files in system)

"Too many open files in system" (ENFILE) means the kernel-wide table is full. On modern kernels the default fs.file-max is huge, so this usually signals a runaway process. Check usage:

cat /proc/sys/fs/file-nr     # allocated  unused  maximum

Find the offender with sudo lsof -n | awk '{print $2}' | sort | uniq -c | sort -rn | head, then raise fs.file-max in /etc/sysctl.d/ only if usage is legitimate.

Distro notes

• The same mechanisms apply on Ubuntu, Debian, Fedora, Arch and openSUSE: systemd for services, pam_limits for logins, sysctl for kernel tunables.
• Some packages ship their own limit: check systemctl cat nginx or systemctl cat mariadb before adding yours.
• Whether sudo and su sessions pick up limits.conf depends on their PAM configuration, which varies by distro and release; test with sudo bash -c 'ulimit -n' instead of assuming.

How to prevent it

• Set LimitNOFILE deliberately for every network service you run, sized to expected connections.
• Monitor descriptor counts (/proc/PID/fd) so leaks show up before they cause outages.
• In your own code, close files and sockets (use with in Python, try-with-resources in Java, defer f.Close() in Go).

Useful commands for this kind of investigation are collected in essential Linux commands and the systemctl cheat sheet.

Frequently asked questions