Too Many Open Files Linux: 8 FAQ [Solved]

What does 'too many open files' mean on Linux?

Linux assigns a small integer called a file descriptor to every open file, socket, and pipe. Each process has a limit on how many descriptors it can hold at once.

When a process tries to open one more than allowed, the kernel returns EMFILE (error 24). You'll see it in application logs as 'Too many open files'. The default limit is often 1024, which sounds like a lot until you run a busy web server that opens a socket per connection.

There's also a system-wide limit in /proc/sys/fs/file-max. Hit that and you get ENFILE instead, which affects every process on the machine. Most production systems never hit the system limit if per-process limits are set correctly.

How do I check my current file descriptor limit?

Run ulimit -n in your shell. That's the soft limit for your current session.

The hard limit acts as a ceiling. Check it with ulimit -Hn. A regular user can raise the soft limit up to the hard limit but can't exceed it without root privileges.

For a running process, read /proc/PID/limits and look for the 'Max open files' line. Replace PID with the actual process ID. You'll see both soft and hard values.

The system-wide limit lives in /proc/sys/fs/file-max. Read it with cat /proc/sys/fs/file-max. Track current usage across all processes with cat /proc/sys/fs/file-nr; the first number is descriptors in use, the third is the maximum.

How do I temporarily raise the limit for testing?

Run ulimit -n 4096 in your shell before starting the application. That change lasts only for the current session and any child processes.

If you're testing a systemd service, edit the unit file temporarily. Add LimitNOFILE=4096 under the [Service] section, run systemctl daemon-reload, then systemctl restart yourservice. The service picks up the new limit immediately.

• ulimit changes don't propagate to already-running processes
• Systemd ignores shell ulimit settings; use LimitNOFILE in the unit file
• Test with a value like 4096 first; jumping straight to 65535 can mask leaks

How do I make the limit permanent?

The asterisk applies to all users. Replace it with a username to target a specific account. Changes take effect on the next login, so log out and back in or start a new shell with su - username.

Systemd services ignore limits.conf. Open the service unit file with systemctl edit yourservice --full or edit /etc/systemd/system/yourservice.service directly. Add LimitNOFILE=8192 in the [Service] block. Run systemctl daemon-reload, then systemctl restart yourservice.

For system-wide capacity, edit /etc/sysctl.conf and add fs.file-max = 200000. Apply it with sysctl -p. I've never needed to touch this on a standard VPS; the default is usually several hundred thousand.

• * soft nofile 4096
• * hard nofile 8192
• www-data soft nofile 8192
• www-data hard nofile 16384

How do I find which process is leaking descriptors?

List open files for a process with lsof -p PID. Pipe it to wc -l to count them. If the number keeps climbing over time, you've got a leak.

Check all processes at once with lsof | awk '{print $2}' | sort | uniq -c | sort -rn | head. That shows the top descriptor consumers by process ID.

Inside the application, look for file or socket handles opened in a loop without a matching close. Database connection pools that never release connections are a common cause. So are HTTP clients that don't close response bodies.

What's the difference between EMFILE and ENFILE?

EMFILE means one process hit its own limit. Fix it by raising ulimit or LimitNOFILE for that process.

ENFILE means the system ran out of file descriptors globally. Every process on the machine competes for the pool in /proc/sys/fs/file-max. This is rare unless you're running hundreds of services or someone wrote a fork bomb.

Check /proc/sys/fs/file-nr to see current usage. If the first number approaches the third, raise fs.file-max in sysctl.conf.

So what if the port is open but the service still fails?

A process that hits the descriptor limit can't accept new connections even if the listening socket is open. The accept() system call fails with EMFILE and the client sees a timeout or connection refused.

Check the service logs first. You'll usually see the exact error. Then check ulimit -n in the context where the service runs. For systemd, that's systemctl show yourservice | grep LimitNOFILE.

If the limit looks fine, count actual open descriptors with lsof. Sometimes the leak is in a library or a subprocess the main process spawned.

What's a safe limit to set?

Start with 4096 for most web services. That handles a few thousand concurrent connections with room for log files and database handles.

High-traffic services like Nginx or a message queue might need 16384 or 32768. I've seen PostgreSQL instances set to 65536 under heavy load.

Setting it to 1048576 (the common maximum) won't hurt, but it can hide leaks. If your process genuinely needs a million open files, you've probably got an architecture problem.

• Test the new limit under load before deploying it
• Monitor descriptor usage with lsof or /proc/PID/fd over a few days
• Document the reason for the limit in the unit file or limits.conf comment

Quick Reference: Commands and Files

Always test changes in a non-production environment first if you can. If that's not an option, make the change during a maintenance window and keep a terminal open with the old configuration ready to revert.

The descriptor limit is one of those things you set once and forget until something breaks. Keep a note of what you changed and why, especially if you're handing the system off to another engineer later.

• Check current soft limit: ulimit -n
• Check hard limit: ulimit -Hn
• Temporary raise for shell: ulimit -n 4096
• Per-process limit: /proc/PID/limits
• Count open files for PID: lsof -p PID | wc -l
• System-wide max: cat /proc/sys/fs/file-max
• System-wide usage: cat /proc/sys/fs/file-nr
• Permanent user limit: /etc/security/limits.conf
• Systemd service limit: LimitNOFILE=8192 in unit file
• Reload systemd: systemctl daemon-reload
• Apply sysctl changes: sysctl -p