CI "Too many open files" (EMFILE) - Raise the nofile Limit

A process tried to open another file, socket, or pipe and the kernel refused with EMFILE - it had hit the per-process open file-descriptor limit. File watchers, bundlers, and high-concurrency network code trip this most.

What this error means

A tool fails with Too many open files, EMFILE, or ENFILE. Bundlers, test runners, and watchers that hold many descriptors at once are common offenders. Raising the descriptor limit, or closing leaked handles, resolves it.

CI log

Error: EMFILE: too many open files, open '/app/node_modules/.../index.js'
# or
OSError: [Errno 24] Too many open files

Common causes

The open-file (nofile) limit is too low for the workload

Many runners default to a modest ulimit -n (e.g. 1024). A bundler or test runner opening thousands of files concurrently exceeds it and gets EMFILE.

Leaked file descriptors

Code that opens files, sockets, or pipes without closing them accumulates descriptors until it hits the cap - a genuine leak rather than a too-low limit.

How to fix it

Inspect and raise the descriptor limit

See the current soft limit and raise it for the step that needs it.

Terminal

ulimit -n               # current soft limit
ulimit -n 65535         # raise it for this shell/step
cat /proc/sys/fs/file-max   # system-wide ceiling

Find leaks if raising the limit does not help

Count open descriptors for the process (ls /proc/<pid>/fd | wc -l) to confirm a leak.
Close files/sockets/streams promptly; use context managers or defer/finally.
Lower concurrency so fewer descriptors are open at once.

How to prevent it

Set a generous nofile limit on runners for FD-heavy tooling.
Close descriptors deterministically rather than relying on GC.
Bound concurrency so peak open-file count stays under the limit.