EMFILE error during directory monitoring in nodemon
0 reputation · 01 Jun 2022, 17:58 UTC
0 reputation · 01 Jun 2022, 17:58 UTC
When using nodemon to monitor large project structures with a high volume of dependencies or assets, the process may encounter system-level limits regarding open file handles. This typically occurs when the native file watcher attempts to track more directories than the operating system allows.
The goal is to maintain automatic restarts without exceeding the OS file descriptor limit. While the --legacy-watch flag provides a polling-based alternative to native events, it may introduce latency in restart triggers or increase CPU overhead.
Does nodemon provide a configuration to ignore specific high-volume subdirectories to prevent EMFILE errors? If not, is --legacy-watch the only documented method to bypass native OS file handle constraints?
35775 reputation · 01 Jun 2022, 18:55 UTC
Yes – nodemon lets you exclude directories that generate many file‑watch events, so you don’t have to rely solely on the --legacy-watch polling mode.
fs.watch) which consumes one file descriptor per watched file or directory.ulimit -n) is exceeded, the OS returns EMFILE.ulimit -n (on Linux/macOS) or the equivalent fs.nr_open on your system.nodemon.json file:
nodemon --ignore "node_modules/**" --ignore "build/**" --ignore "dist/**" your-app.js
or in nodemon.json:
{
"ignore": ["node_modules/**", "build/**", "dist/**"]
}EMFILE message disappears from the startup log.ulimit -n 4096 && nodemon your-app.js
(choose a value safely above the current usage but not excessively high).
nodemon --legacy-watch your-app.js
This avoids native descriptors but may increase CPU usage and latency.Please provide the output of ulimit -n (or the equivalent limit on your system) so we can tell whether raising the limit is necessary or if the ignore patterns alone will suffice.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 01 Jun 2022, 22:31 UTC
While adjusting ulimit -n addresses the EMFILE error by increasing the per-process file descriptor limit, it is important to distinguish this from ENOSPC errors on Linux systems. Even if the process limit is raised, the kernel's fs.inotify.max_user_watches limit may still be exceeded when monitoring massive directory trees.
To verify if the bottleneck is the process limit (EMFILE) or the kernel watch limit (ENOSPC), you can check the current kernel limit:
cat /proc/sys/fs/inotify/max_user_watches
If you are using a nodemon.json configuration, you can further reduce descriptor pressure by using the "watch" property to target only specific source directories (e.g., ["src"]) rather than ignoring folders from the project root. This prevents the watcher from traversing high-volume subtrees entirely, which is more efficient than filtering them out after the initial scan.