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

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

@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.

Bump @cpojer

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

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 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?

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 for investigating, if you install watchman, it should work.

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 :tada: :beers:

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

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

Thanks Bro @maraisr

@maraisr do you know if there's a sudo-less version of that solution, by any chance?

@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.

May be I am missing something... but why does jest need to watch anything in my node_modules directory?
How can I configure it so it skips node_modules?

https://facebook.github.io/jest/docs/en/configuration.html#watchpathignorepatterns-array-string might help?

@SimenB, as I see watchPathIgnorePatterns skips files only after watch itself is up and running, that's why the start of the watch can take a long time and sometimes can throw ENOSPC

Ah, ok. A PR respecting watchPathIgnorePatterns when setting up watchers would be nice :)

@SimenB can you please point me on the place in the source code where it directly starts watch? I have a hard time to find this place

Find out that watcher is using HasteMap as a source of all files that should be watched, and the question right now in process of building HasteMap.
HasteMap respects modulePathIgnorePatterns option, but it's not logical to use this option based on the description from the docs:

An array of regexp pattern strings that are matched against all module paths before those paths are to be considered 'visible' to the module loader. If a given module's path matches any of the patterns, it will not be require()-able in the test environment.

am I right?

@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

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.)

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.

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

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

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

I had this with 2 instances of VSCode open, which makes complete sense.

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

lsof | wc -l
can shed light on source of problem.
Any program, whether it's a browser or builded with web engine inside (i.e. VS code), drasticaly raising number of opened file descriptors (about 30 000 and more per program).
I do not see a reliable workaround, because. web technology become ubiquitous

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.

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

It's mainly working (and bunch of deleted) files from web engine, but not from node_modules, that blocking free nodes for watcher.

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

thank you very much

@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

@maraisr Thank you for you fix works perfectly on ubuntu 18 like @xameeramir says

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

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 :laughing:

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.

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 what it's worth: Maybe it's related to the environment (module X vs module Y).

I have 2 ReactNative applications that have 2 different configurations. Mostly because one of them use React-Native-Camera that is not yet ready for the latest RN versions (ie : latest Gradle and such environment). The other one is a demo to test latest RN version and environment.

The application using React-Native-Camera compile flawlessly (--variant=release) on Linux. The other one got the ENOSPC error. The "fs.inotify.max_user_watches" fix did work. I was like "huh?". As described by other I have tons of gigabytes on the NAS...

Here are the "package.json" of both app.

Maybe you'll find something useful.
App 1 (Camera) :

{
  "name": "********************",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "jest"
  },
  "dependencies": {
    "i18n-js": "^3.0.11",
    "react": "16.4.1",
    "react-native": "0.56.0",
    "react-native-camera": "^1.2.0",
    "react-native-languages": "^3.0.1",
    "react-navigation": "^2.16.0"
  },
  "devDependencies": {
    "babel-jest": "23.4.2",
    "babel-preset-react-native": "5.0.2",
    "jest": "23.5.0",
    "react-test-renderer": "16.4.1"
  },
  "jest": {
    "preset": "react-native"
  }
}

App 2 (test demo):

{
  "name": "DemoReactNative",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "jest"
  },
  "dependencies": {
    "i18n-js": "^3.0.11",
    "react": "16.6.0-alpha.8af6728",
    "react-native": "0.57.3",
    "react-native-languages": "^3.0.1",
    "react-navigation": "^2.18.0"
  },
  "devDependencies": {
    "babel-jest": "23.6.0",
    "jest": "23.6.0",
    "metro-react-native-babel-preset": "0.48.1",
    "react-test-renderer": "16.6.0-alpha.8af6728"
  },
  "jest": {
    "preset": "react-native"
  }
}

maraisr,
thanks works !!!

just running as sudo worked for me

@4E71-NOP I saw the same thing. Once we updated from RN 0.51 to 0.57, we started running into this issue. Increasing the inotify limit helped

I run with sudo ... and it works to me

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
This helped me for UBUNTU 18.10

Many thanks. But just as @adamhooper mentioned before, Forcing the user to sudo for a mundane task is certainly a bug.

Any ideas for regular user?

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p This fixed it.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

Perfectly solved my problem, thank you very much!

I fixed it excluding node_modules with the modulePathIgnorePatterns setting.

Add this to your package.json:

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

Worked like a charm. Thanks @maraisr !

[hayesmaker64@gohan hype-layer]$ npm test

> [email protected] test /home/hayesmaker64/Workspace/twitch/hype-layer
> react-scripts test

internal/fs/watchers.js:173
    throw error;
    ^

Error: ENOSPC: System limit for number of file watchers reached, watch '/home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/get-stream'
    at FSWatcher.start (internal/fs/watchers.js:165:26)
    at Object.watch (fs.js:1254:11)
    at NodeWatcher.watchdir (/home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/sane/src/node_watcher.js:175:20)
    at Walker.<anonymous> (/home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/sane/src/common.js:116:12)
    at Walker.emit (events.js:182:13)
    at /home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/walker/lib/walker.js:69:16
    at go$readdir$cb (/home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/graceful-fs/graceful-fs.js:162:14)
    at FSReqWrap.oncomplete (fs.js:141:20)
npm ERR! Test failed.  See above for more details.
[hayesmaker64@gohan hype-layer]$ ^C
[hayesmaker64@gohan hype-layer]$ ^C
[hayesmaker64@gohan hype-layer]$ npm test

> [email protected] test /home/hayesmaker64/Workspace/twitch/hype-layer
> react-scripts test


Out of the box, Create React App only supports overriding these Jest options:

  • collectCoverageFrom
  • coverageReporters
  • coverageThreshold
  • globalSetup
  • globalTeardown
  • resetMocks
  • resetModules
  • snapshotSerializers
  • watchPathIgnorePatterns.

These options in your package.json Jest configuration are not currently supported by Create React App:

  • modulePathIgnorePatterns

If you wish to override other Jest options, you need to eject from the default setup. You can do so by running npm run eject but remember that this is a one-way operation. You may also file an issue with Create React App to discuss supporting more options out of the box.

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"
    ]
  }

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 fixed an issue I was experiencing with Vue when running npm run serve Thank you for the suggestion @maraisr

@pomber Thank you, it solve my problem on Fedora without increasing any system limit.

Thank you @maraisr, it solve my problem :)

Many thanks! @maraisr

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 ()
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 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.

"modulePathIgnorePatterns": [
      "node_modules"
    ]

this is the real answer

If you run into this issue consistently and cannot ignore node_modules, installing Watchman will help:
https://facebook.github.io/watchman/

There are Watchman-specific optimizations within Jest, so it will also improve your startup time for large projects significantly.

Going forward, I'll look into not automatically watching node_modules when doing so would cause this type of error (eg: no Watchman and not on Darwin so cannot use fsevents).

Oh Hey @scotthovestadt! Hope you're well!

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?

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.

Linux is de-facto standard for all professional developers, are you really care more about Windows and Mac users? That is shame

@maraisr thanks. I resolved problem. :dancer:

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 .

might be there is some permission issues try Sudo npm start

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

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

@maraisr Thanks, your solution worked perfectly on Ubuntu 18.04

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, this resolved my issue.

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?

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?

Create React App limits the keys that can be used within the package jest config - has anyone found a way to solve this in a CRA app?

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

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

Just a note for improvement, you may be better off instructing users to check that flag/value doesn't already exist so they don't get duplicate instances of it. That or use some kind of tool for with this in mind.

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.

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

Thanks @maraisr

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?

I was able to fix this issue with sudo react-native start