Why do I get the Waiting...Fatal error: watch ENOSPC
when I run the watch task ?
How do I solve this issue?
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
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: wiki.archlinux.org/index.php/Sysctl –
Impressible npm dedupe
cleared it up for me. issue –
Corsetti 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 –
Claudelle grunt serve
started successfully fixed the problem for me. –
Indecent log2 524288
is 19. What is the significance of 19? Why does this number work? –
Indecent sysctl: cannot stat /proc/sys/fs/inotify/max_user_watches: No such file or directory
–
Wrestling 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.
grunt --force
before I found this –
Digestible sudo
and now it's working for me. –
Troytroyer 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
–
Soap npm
can't be right. This answer should be accepted. –
Hankhanke 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.
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.
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.
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.
In my case I found that I have an aggressive plugin for Vim, just restarted it.
© 2022 - 2024 — McMap. All rights reserved.
grunt
but any program using inotify underneath. There is a good explanation at unix.stackexchange.com/questions/13751/…. – Reprehensible