Skip to main content
“Too many open files” means a program reached its limit of file descriptors: open files, network connections and pipes all count. On most systemd distributions, services start with a soft limit of 1024. Check the real limit with grep 'open files' /proc/<PID>/limits, then raise it for a service with LimitNOFILE=65535 in a systemd override, or for login sessions with nofile in /etc/security/limits.conf.

​
Before you start

  • A file descriptor is a number a program uses for each open file or connection. Busy web servers, databases and game servers with many players need thousands.
  • Each process has a soft limit (what applies now) and a hard limit (the most the soft limit may be raised to).
  • Commands use sudo. As root, leave it out.

​
Step 1: Check the limit and the usage

Find the process ID (PID), for example of Nginx:
Then show its limit and how many descriptors it has open (replace 812 with your PID):
The first number is the soft limit, the second the hard limit. If the count is close to the soft limit, raise it (Causes 1 and 2). If the count keeps climbing however high the limit is, see Cause 3.

​
Cause 1: A systemd service has a low limit

Services started by systemd ignore ulimit and limits.conf. They take the limit from their unit, which defaults to 1024 soft and 524288 hard. Fix: open an override for the service:
Add:
Save, then restart:
For Nginx, also let the workers use it: in /etc/nginx/nginx.conf, at the top level, add worker_rlimit_nofile 65535;, check with sudo nginx -t and reload. For MariaDB/MySQL, raise LimitNOFILE the same way on the mariadb or mysql unit.

​
Cause 2: A program started from your shell or a login has a low limit

Programs you start by hand, in tmux or screen, or from cron get the limit of your login session. Check:
Fix for the current shell (up to the hard limit):
Fix permanently for a user: add these lines to /etc/security/limits.conf (or a new file in /etc/security/limits.d/), then log out and back in:
Fix a process that is already running without a restart:
This lasts until the process stops. Make the permanent change too.

​
Cause 3: A program leaks file descriptors

If the count from Step 1 grows all day and never drops, the program opens files or connections and doesn’t close them. A higher limit only delays the error. Check what it keeps open:
Many socket:[...] entries point to unclosed connections; the same file name many times points to a file opened in a loop. Fix: update the program or report the bug to its developer. Until then, restart it on a schedule.

​
Cause 4: inotify limits (file watchers)

Tools that watch files (tail -f, Node.js dev servers, sync tools, some game panels) use inotify, which has its own per-user limits. They report the same error, for example tail: inotify cannot be used, reverting to polling: Too many open files. Check:
Fix: raise them permanently:

​
How to check it worked

Repeat Step 1 after the restart:

​
Frequently asked questions

​
I set limits.conf but my service still has 1024. Why?

limits.conf only applies to login sessions through PAM. systemd services need LimitNOFILE in their unit (Cause 1).

​
What value should I use?

65535 is plenty for most web servers, databases and game servers. Some vendors recommend more; follow their documentation for that program.

​
What does “Too many open files in system” mean?

That is the system-wide limit (fs.file-max), not a per-process one. It is rare on current kernels; check with cat /proc/sys/fs/file-nr, and look for a leak (Cause 3) before raising it.

VPS and dedicated server guides

Every guide in this section.

Manage services with systemctl

Overrides, restarts and status.

Kernel settings with sysctl

Make kernel settings permanent.

Tune Linux for game servers

Limits and settings for busy servers.

High load on a Linux server

Find what slows the server down.
Checked against the official systemd systemd.exec and systemd-system.conf manuals, the limits.conf and prlimit manuals and the nginx core module documentation on 4 November 2026; the error (Python and Bash), /proc/PID/limits, ulimit, prlimit and the inotify sysctl values were tested on Ubuntu 24.04 LTS. The systemd override was not tested, because systemd doesn’t run in our test container.

​
Need Extra Help?

If you encounter any issues, our support team is ready to assist:

​
Save on Your Hosting

Ready to upgrade your hosting? Use code KB20 at checkout for 20% off your first order!
Last Updated: November 2026