jest: Bug: Watch mode on Linux causes a ENOSPC Node.js error

From my findings its not related to Jest at all. On Linux (or Mac) we have a max number of system watchers we can place at an IO level (from my understanding). So for large projects, it seems that Jest is trying to watch just way to many files.

To fix:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source: Node.JS Error: ENOSPC

This means there is no space on your drive. Please cleanup your disk.

Just recently switched from Windows 7 to Ubuntu 16.04.2 LTS and Jest was working great in Windows but failed to run under Linux for the same reasons listed above. It only seems to fail if you add the --watch flag.

Firstly I took @cpojer advice and installed watchmen as per docs and ran the jest --watch again and I got the following errors:

jest --watch

events.js:163
      throw er; // Unhandled 'error' event
      ^

Error: A non-recoverable condition has triggered.  Watchman needs your help!
The triggering condition was at timestamp=1493335106: inotify-add-watch(/home/username/project_name/node_modules/browser-resolve/node_modules/resolve/example) -> The user limit on the total number of inotify watches was reached; increase the fs.inotify.max_user_watches sysctl
All requests will continue to fail with this message until you resolve
the underlying problem.  You will find more information on fixing this at
https://facebook.github.io/watchman/docs/troubleshooting.html#poison-inotify-add-watch

    at ChildProcess.<anonymous> (/home/username/project_name/node_modules/sane/node_modules/fb-watchman/index.js:207:21)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:194:7)
    at maybeClose (internal/child_process.js:899:16)
    at Socket.<anonymous> (internal/child_process.js:342:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at Pipe._handle.close [as _onclose] (net.js:510:12)
npm ERR! Test failed.  See above for more details.

This was useful as it tells you what to do, so I then used the fix from @maraisr and jest is now working on Ubuntu 🎉 🍻

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Thank you for figuring this out @maraisr @cpojer 👍 Do you think something should be added to the Jest website?

Unfortunately we do not have resources to debug this on Linux. If you have time and you could take a look and help us with a pull request to fix it, that would be greatly appreciated.

@cpojer not sure if you read the issue, but;

Disk free space: df -h / (11% used)

was mentioned in there - disk space although reported as the issue, is actually not the issue.

I am having the same issue, and there’s definitely free disk space

I fixed it excluding node_modules with the modulePathIgnorePatterns setting.

Add this to your package.json:

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

Getting this on ubuntu 18.10 when i run “npm start” on my untouched virgin create-react-app WORKED!!! SOLUTION echo fs.inotify.max_user_watches=2048000 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

For future visitors, @pomber’s solution is objectively vastly better than increasing the watch limit:

Add this to your package.json:

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

This should be the top answer. People - please bump this. Why would you simply say “oh, out of memory/resources - give it more memory/resources” without examining the cause?

@maraisr Great, echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p worked for me on Ubuntu 18.04.1 LTS

I don’t see why this bug is “Closed.” Forcing the user to sudo for a mundane task is certainly a bug.

It’s a bug unique to Jest: mocha, guard, etc. all watch specific subdirectories, not ., to avoid this problem. (The list of subdirectories could be optional.)

@cpojer I’ll take a look - but I also believe it is not limited to the Linux OS. Regardless, do you mind re-opening this issue?

I fixed it excluding node_modules with the modulePathIgnorePatterns setting.

Add this to your package.json:

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

after that, just remove node_modules folder and run npm install again.

Thanks for investigating, if you install watchman, it should work.

I was getting this issue, when I had two VSCode instances opened.

In jest 21 i never had this problem. vscode is competing with jest for watching the files. when i close vscode, jest starts to work correctly.

"modulePathIgnorePatterns": [
      "node_modules"
    ]

this is the real answer

IMO, it’s unacceptable that there should be a watch on node_modules

To get away from this bug just use sublime/atom/gedit. Or you can close VSCode while building/debugging.

Future visitors and @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG, for my sanity please stop propagating the watch limit fix.

For future visitors, @pomber’s solution is objectively vastly better than increasing the watch limit:

Add this to your package.json:

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

This should be the top answer. People - please bump this. Why would you simply say “oh, out of memory/resources - give it more memory/resources” without examining the cause?

From my findings its not related to Jest at all. On Linux (or Mac) we have a max number of system watchers we can place at an IO level (from my understanding). So for large projects, it seems that Jest is trying to watch just way to many files.

To fix:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source: Node.JS Error: ENOSPC

Perfectly solved my problem, thank you very much!

@vspedr not sure - I can take a look!

But we are touching system files there, so for security you kinda need elevated permissions. If you can make yourself a sudoer i believe you can run those commands without sudo.

But yeah - i’ll take a look and see what I can come up with.

For future visitors, @pomber’s solution is objectively vastly better than increasing the watch limit:

Add this to your package.json:

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

I got this error when I update the project dependencies. To solve I just removed the and install the node_modules

This took me SO long to find and finally fix. I started doing workarounds again and again. Thank you @samit4me !

Since the last few comments have been suggesting the earlier workaround, and the later fix is starting to get buried, I feel it is necessary to reiterate for future readers (and @pradeepsrawat029 @karsa87 @igorgoiis ) that you should first try the later fix if applicable, which was originally not possible because of a jest bug:

For future visitors, @pomber’s solution is objectively vastly better than increasing the watch limit:

Add this to your package.json:

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

This should be the top answer. People - please bump this. Why would you simply say “oh, out of memory/resources - give it more memory/resources” without examining the cause?

From my findings its not related to Jest at all. On Linux (or Mac) we have a max number of system watchers we can place at an IO level (from my understanding). So for large projects, it seems that Jest is trying to watch just way to many files.

To fix:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source: Node.JS Error: ENOSPC

Thanks resovel o problema já tava procurando a horas o que era esse rro

Funny thing about fs.inotify.max_user_watches=524288 In my case it seems the project is large enough that 524288 isn’t big enough of a number. So… well fs.inotify.max_user_watches=2048000 helped. Might also be related to the matter of opening a lot of stuff in vs code on the side.

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p fixed it for me as well 👍

Please reopen or add the fix to the troubleshooting for testing.

@maraisr

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

this solution does not work on my mac os 10.13.4 it returns the error below

sysctl: illegal option -- p usage: sysctl [-bdehiNnoqx] name[=value] ... sysctl [-bdehNnoqx] -a sysctl: illegal option -- p usage: sysctl [-bdehiNnoqx] name[=value] ... sysctl [-bdehNnoqx] -a

Thanks Bro @maraisr

Thanks @maraisr

From my findings its not related to Jest at all. On Linux (or Mac) we have a max number of system watchers we can place at an IO level (from my understanding). So for large projects, it seems that Jest is trying to watch just way to many files.

To fix:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source: Node.JS Error: ENOSPC

thank yout for you answer it’s work for me

From my findings its not related to Jest at all. On Linux (or Mac) we have a max number of system watchers we can place at an IO level (from my understanding). So for large projects, it seems that Jest is trying to watch just way to many files.

To fix:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source: Node.JS Error: ENOSPC

Thank you for your best answer.

This command will increase the number of allowed watchers: echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p Source

might be there is some permission issues try Sudo npm start

For future visitors, @pomber’s solution is objectively vastly better than increasing the watch limit:

Add this to your package.json:

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

This should be the top answer. People - please bump this. Why would you simply say “oh, out of memory/resources - give it more memory/resources” without examining the cause?

Just a note for the record: the present proper fix didn’t work until #7585 that fixed #7544 .

Oh Hey @scotthovestadt! Hope you’re well!

Your solution worked for me, @maraisr! echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p Thanks!

This was my error for anyone who’s interested: Logs for your project will appear below. Press Ctrl+C to exit. (node:19425) UnhandledPromiseRejectionWarning: Error: ENOSPC: System limit for number of file watchers reached, watch ‘/home/claire/Documents/my-app-name’ at FSWatcher.start (internal/fs/watchers.js:165:26) at Object.watch (fs.js:1274:11) at NodeWatcher.watchdir (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:175:20) at new NodeWatcher (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:45:8) at createWatcher (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:780:23) at Array.map (<anonymous>) at HasteMap._watch (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:936:44) at _buildPromise._buildFileMap.then.then.hasteMap (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:355:23) at processTicksAndRejections (internal/process/next_tick.js:81:5) (node:19425) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:19425) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. ENOSPC: System limit for number of file watchers reached, watch ‘/home/claire/Documents/my-app-name’ ENOSPC: System limit for number of file watchers reached, watch ‘/home/claire/Documents/my-app-name’

I run with sudo … and it works to me

Be aware that /etc/sysctl.conf is typically overwritten when upgrading (eg from Ubuntu 16 to 18 LTS) and will remove the higher limit. I was warned about this, but it’s easy to miss in a sea of other similar warnings. Even though I saw the max_user_watches diff, I was still thrown for a loop this morning when I first hit the error, as it is not obvious that these things are connected. However, once I landed on this issue page it was clear what I needed to fix.

Hooray for re-solving an issue I had fixed two years ago 😆

Cheers for the point in the right direction on this. I had the same issue with watch failing, but in this case only one instance of VSCode running. Closing that, then running my project and reopning, resolved it.