本文共 2878 字，大约阅读时间需要 9 分钟。
本文翻译自：
Why do I get the Waiting...Fatal error: watch ENOSPC when I run the watch task ? 为什么我得到Waiting...Fatal error: watch ENOSPC在我运行监视任务时Waiting...Fatal error: watch ENOSPC ？ 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: 对于Arch Linux，将此行添加到/etc/sysctl.d/99-sysctl.conf：
fs.inotify.max_user_watches=524288
Any time you need to run sudo something ... to fix something, you should be pausing to think about what's going on. 任何时候你需要运行sudo something ...来修复某些东西，你应该暂停思考发生了什么。 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. Sorta相当于购买更大的马鞍袋来解决问题：错误，无法将更多的垃圾装到小马上。 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. 然后祝贺自己让小马开心。
After trying you may use a temporary fix: 在尝试您可以使用临时修复：
sudo bash -c 'echo 524288 > /proc/sys/fs/inotify/max_user_watches'
This does the same thing as , but without persisting the changes. 这与完全相同，但没有坚持更改。 This is useful if the error just occurs after some uptime of your system. 如果在系统正常运行一段时间后发生错误，这将非常有用。
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. 我的客户端PC崩溃后，我遇到了这个错误，我在服务器上运行的jest --watch命令持续存在，我试图再次运行jest --watch 。
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 上面的答案中描述的/etc/sysctl.conf的添加解决了这个问题，但通过ps aux | grep node找到我的旧进程也很重要ps aux | grep node ps aux | grep node and kill it. ps aux | grep node并kill它。
To find out who's making inotify instances , try this command ( ): 要找出谁正在创建inotify 实例 ，请尝试此命令（ ）：
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 . 使用ps -p 2857 ，我能够将进程2857识别为sublime_text 。 Only after closing all sublime windows was I able to run my node script. 只有在关闭所有 sublime窗口后，我才能运行我的节点脚本。
转载地址：http://pscnb.baihongyu.com/