Deploy Error Decoder

EMFILE: too many open files — how to fix it

Q: How do I raise the open-files limit?

Set LimitNOFILE in the systemd service unit, or nofile in /etc/security/limits.conf. Check the running process's effective limit in /proc/ /limits.

Quick answer: EMFILE: too many open files means your process hit its file-descriptor limit — every socket, open file, and pipe counts toward it. Either the limit is too low (ulimit -n) or you're leaking descriptors by not closing connections and streams. Raise the limit for genuine load, but if it climbs forever under steady traffic, find the leak.

What the error looks like

A file or socket open fails once the descriptor table is full:

Error: EMFILE: too many open files, open '/app/uploads/x.tmp'
    at Object.openSync (node:fs:600:3)

# or, accepting connections:
Error: accept EMFILE

Descriptors aren't just files — TCP sockets, pipes, and watches all consume them. A leak in any of those eventually exhausts the table.

Why it happens

The ulimit is too low

The default open-files limit is below what your concurrency needs at peak.

A descriptor leak

Sockets, file handles, or streams opened but never closed accumulate until the table is full.

Too many concurrent connections

A burst of clients or unpooled outbound connections opens more sockets than the limit allows.

Watching too many files

A tool recursively watching a huge tree opens a descriptor per watch.

Diagnose it in three steps

1

Check the current limit

ulimit -n                 # soft limit for this shell
cat /proc/$(pgrep -f node | head -1)/limits | grep 'open files'

2

Count open descriptors

lsof -p <PID> | wc -l
# Watch it under load — does it keep climbing and never drop?

3

Raise the limit (for real load)

# systemd unit
[Service]
LimitNOFILE=65536
# or /etc/security/limits.conf
*  soft  nofile  65536
*  hard  nofile  65536

The real fix

Close what you open; pool what you reuse

If descriptors climb without bound under steady traffic, the limit isn't the problem — a leak is. Close streams and responses, pool outbound connections instead of opening one per request, and for fs-heavy tooling consider graceful-fs. Raise the ulimit only for genuinely high concurrency.

How Infraveil handles this

Resource exhaustion you can see and survive

Infraveil surfaces resource problems instead of letting them fail silently. Running on your own servers, its agent health-checks your services, restarts one that's exhausted its descriptors, and shows the failure in one log + status view — so a slow descriptor leak is visible early, not at 3am when accepts start failing.

Health checks and automatic restart keep an exhausted service available

Failures surface in one status + log view, on servers you control

One-click rollback to the last healthy release while you fix the leak

See how it works More deploy fixes

Frequently asked questions

What does EMFILE mean?

Your process reached its limit on open file descriptors. Files, TCP sockets, pipes, and file watches all count toward this limit.

How do I raise the open-files limit?

Set LimitNOFILE in the systemd service unit, or nofile in /etc/security/limits.conf. Check the running process's effective limit in /proc/<pid>/limits.

Is EMFILE a leak or just a low limit?

If open descriptors climb without bound under steady load, it's a leak — close sockets/streams and pool connections. If it only spikes at genuine peak concurrency, raise the limit.

Why does EMFILE happen in development?

Often a build tool or dev server watching a large directory tree opens a descriptor per watched file. Reduce the watch scope or raise the limit.