Grunt watch error - Waiting...Fatal error: watch ENOSPC

Question

Why do I get the Waiting...Fatal error: watch ENOSPC when I run the watch task ? How do I solve this issue?

For anyone viewing this, this is not specific to `grunt` but any program using [inotify](http://man7.org/linux/man-pages/man7/inotify.7.html) underneath. There is a good explanation at http://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached. — Jesse Good, Aug 29 '15 at 22:54

score 1374 · Accepted Answer · edited May 31 '18 at 14:00

1374

After doing some research found the solution. Run the below command.

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

For Arch Linux add this line to /etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288

edited May 31 '18 at 14:00

Zoe

27,060
21
118
148

answered Jul 02 '13 at 23:49

kds

28,155
9
38
55

47

Well, it seems to have solved my problem... But how? Why? Do you have any sources that explain what is happening (or was happening). Or may you yourself do it? Anyway, thanks... – slacktracer Aug 07 '13 at 01:10
116

The system has a limit to how many files can be watched by a user. You can run out of watches pretty quickly if you have Grunt running with other programs like Dropbox. This command increases the maximum amount of watches a user can have. – Benjamin Manns Sep 03 '13 at 19:28
62

For Arch Linux add `fs.inotify.max_user_watches=524288` to `/etc/sysctl.d/99-sysctl.conf` and then execute `sysctl --system`. This will also persist across reboots. For more details: https://wiki.archlinux.org/index.php/Sysctl – tnajdek Sep 27 '13 at 09:20
Is the posted answer for MacOSX? – grumplet Jan 14 '14 at 17:16
This seems to have worked for others, but I get an error on OSX...sysctl: illegal option -- p – kindasimple Jan 19 '14 at 03:45
38

`npm dedupe` cleared it up for me. [issue](https://github.com/gruntjs/grunt-contrib-watch/issues/236) – reergymerej Mar 04 '14 at 02:05
1

or just htop kill the multiple spawns of same process you may have. – knutole Apr 30 '14 at 11:09
@blurd So why would npm dedupe fix this? – chrisjlee Jun 22 '14 at 08:46
Ha! Killing dropbox also fixed it :) – Stop Slandering Monica Cellio Jul 03 '14 at 20:11
2

Arch #2: in response to tnajdek, i had to add that to the file /usr/lib/sysctl.d/50-default.conf instead – sqram Sep 21 '14 at 16:23
25

**explanation:** **`echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf`** writes at the end of the file /etc/sysctl.conf the line "fs.inotify.max_user_watches=524288" **`sudo sysctl -p`** reconfigures the kernel at runtime, loading the file /etc/sysctl.conf as a parameter – kds Oct 11 '14 at 07:26
I never got this problem until very recently, only think I know of that has changed is that nodejs was updated. I am not satisfied with the expatiation of this. What is the default limit? Are watches the number of files? I am only watching for .less and .php files cant be that many and I do not run dropbox or anything else just grunt-contrib-watch – redanimalwar Nov 13 '14 at 03:59
2

In my case, the villains were Grunt using LiveReload and Compass, and Sublime watching the files... Thanks a lot! – ViniciusPires Dec 11 '14 at 11:57
1

Thanks for mentioning that @ViniciusPires, re-opening Sublime *after* `grunt serve` started successfully fixed the problem for me. – Aditya M P Dec 30 '14 at 11:00
2

So `log2 524288` is 19. What is the significance of 19? Why does this number work? – Aditya M P Jan 03 '15 at 22:20
for the record: same problem with Brunch, same solution :) – maxlath Jan 18 '15 at 12:40
2

For the curious: I had this problem running Grunt from a Docker container. It took me a while to realize that I needed to execute the command from the host OS instead of from the container itself. – Adam Brown Feb 17 '15 at 06:43
It's working here for Ubuntu 14.04. Thank you very much! you've saved my day. – RobertoAllende Apr 08 '15 at 18:35
Worked for me in Fedora. – Luis Crespo Apr 17 '15 at 16:36
I honestly have no idea why this works for me and not Extazystas, but it did! Ubuntu 14.04 running foreman with grunt scripts – slackbot39243 Jun 18 '15 at 17:53
Worked for me with gulp/browserSync on ubuntu 14.04.02 – ceram1 Jun 25 '15 at 04:19
This is also the solution to another question here on Stack : [nextTick error](http://stackoverflow.com/questions/22285942/grunt-throw-recursive-process-nexttick-detected) When using Ubuntu (14.04 in my case) – Michiel Aug 03 '15 at 15:24
Worked like a charm in Fedora 22. – Fabiano Moraes Nov 05 '15 at 13:35
@mohammed-ramadan I have already given the explanation on one of the answers. Please find the section "explanation: " that has the detailed level explanation. – kds Jan 04 '16 at 04:35
Wonders shall never end! I thought the command was more of sorcery, but makes sense now. – KhoPhi Mar 27 '16 at 22:15
Worked for me on Ubuntu 15.10. – Hinrich May 01 '16 at 16:29
2

@AdityaMP I just found the reason for the "magic" number. To quote "Assuming you set the max at 524288 and all were used (improbable), you'd be using approximately 256MB/512MB of 32-bit/64-bit kernel memory." - from http://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached – Jason O'Neil Oct 04 '16 at 02:34
Arch linux ([deprecated sysctl.conf][1]): echo fs.inotify.max_user_watches=524288 | sudo tee /etc/sysctl.d/40-max-user-watches.conf && sudo sysctl --system [1]: https://www.archlinux.org/news/deprecation-of-etcsysctlconf/ – useless Oct 11 '16 at 23:37
Caveat: this will increase unswappable memory usage up to 256 or 512 MB, see https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached – That Brazilian Guy Apr 19 '17 at 20:07
This happens to me on boot. Without any Dropbox (or anything that watch files) installed. Any idea how to check what is watching files, or what is the actual limit? – dievardump Aug 10 '17 at 17:30
Getting this error on ubuntu 16.04 `sysctl: cannot stat /proc/sys/fs/inotify/max_user_watches: No such file or directory` – MD. Khairul Basar May 31 '18 at 15:26

grenade · Answer 2 · 2016-11-05T00:47:31.310

190

Any time you need to run sudo something ... to fix something, you should be pausing to think about what's going on. While the accepted answer here is perfectly valid, it's treating the symptom rather than the problem. Sorta the equivalent of buying bigger saddlebags to solve the problem of: error, cannot load more garbage onto pony. Pony has so much garbage already loaded, that pony is fainting with exhaustion.

An alternative (perhaps comparable to taking excess garbage off of pony and placing in the dump), is to run:

npm dedupe

Then go congratulate yourself for making pony happy.

edited Nov 05 '16 at 00:47

answered Aug 10 '15 at 18:19

grenade

31,451
23
97
126

44

Thanks for making the pony happy. – Christian Aug 11 '15 at 12:13
Talking about treating the symptom...I used to do a `grunt --force` before I found this – nthapa Sep 07 '15 at 17:57
2

What exactly it does ? It solved my problem for sure. Thanks @grenade – Arjun K R Nov 05 '15 at 05:26
4

'npm dedupe' command walks through your npm module tree and moves every package up in the tree as much as possible. The result is a flat tree. It moves a package even when it is not duplicated. You can read more about what happens to different versions of modules in this case, at https://docs.npmjs.com/cli/dedupe – Arun Reddy Nov 18 '15 at 04:19
1

it didn't help, i tried with `sudo` and now it's working for me. – asedsami Jan 19 '16 at 01:19
6

In my case my problem seems to be to have Dropbox installed which seems to use a lot of watches. So I had to use: `fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p` as in the accepted answer, but +1 for teach me `npm dedupe` – Johann Echavarria Apr 06 '16 at 15:22
I was getting error on running "npm install grunt". The message was "(node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.". This solved my problem. – dreamerkumar Jun 18 '16 at 21:15
some more info produced by phpstorm: https://confluence.jetbrains.com/display/IDEADEV/Inotify+Watches+Limit – Galvani Nov 21 '16 at 08:14
1

Changing something on the Filesystem for `npm` can't be right. This answer should be accepted. – kiltek May 24 '18 at 09:51
Here's more context around vscode- "Visual Studio Code is unable to watch for file changes in this large workspace" (error ENOSPC): https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc – Meetai.com Jan 06 '19 at 17:18

score 38 · Answer 3 · edited May 23 '17 at 12:18

38

After trying grenade's answer you may use a temporary fix:

sudo bash -c 'echo 524288 > /proc/sys/fs/inotify/max_user_watches'

This does the same thing as kds's answer, but without persisting the changes. This is useful if the error just occurs after some uptime of your system.

edited May 23 '17 at 12:18

Community

1
1

answered Jan 09 '17 at 14:41

Arne L.

2,194
19
19

3

This should be the accepted answer as the problem is naturally caused by what's running at the moment and not by a bad configuration (see the "pony" example). – arielnmz Feb 11 '17 at 16:25

score 8 · Answer 4 · answered Oct 09 '17 at 15:29

To find out who's making inotify instances, try this command (source):

for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr

Mine looked like this:

 25 /proc/2857/fd/anon_inode:inotify
  9 /proc/2880/fd/anon_inode:inotify
  4 /proc/1375/fd/anon_inode:inotify
  3 /proc/1851/fd/anon_inode:inotify
  2 /proc/2611/fd/anon_inode:inotify
  2 /proc/2414/fd/anon_inode:inotify
  1 /proc/2992/fd/anon_inode:inotify

Using ps -p 2857, I was able to identify process 2857 as sublime_text. Only after closing all sublime windows was I able to run my node script.

the same with me for vscode but i think it is related to file watches as well — pcnate, Feb 13 '18 at 21:45

score 3 · Answer 5 · answered Apr 18 '17 at 16:15

I ran into this error after my client PC crashed, the jest --watch command I was running on the server persisted, and I tried to run jest --watch again.

The addition to /etc/sysctl.conf described in the answers above worked around this issue, but it was also important to find my old process via ps aux | grep node and kill it.

score 0 · Answer 6 · answered Jun 16 '19 at 07:29

In my case it was related to vs-code running on my Linux machine. I ignored a warning which popped up about file watcher bla bla. The solution is on the vs-code docs page for linux https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc

The solution is almost same (if not same) as the accepted answers, just has more explanation for anyone who gets here after running into the issues from vs-code.

score 0 · Answer 7 · answered Apr 28 '20 at 08:48

0

In my case I found that I have an aggressive plugin for Vim, just restarted it.

answered Apr 28 '20 at 08:48

Vitaly Zdanevich

13,032
8
47
81

Grunt watch error - Waiting...Fatal error: watch ENOSPC

7 Answers7

Linked

Related