【发布时间】：2013-05-20 20:49:27
【问题描述】：
为什么我在运行监视任务时得到Waiting...Fatal error: watch ENOSPC？
我该如何解决这个问题？
【问题讨论】：
-
对于查看此内容的任何人，这不是特定于
grunt，而是任何使用inotify 的程序。 unix.stackexchange.com/questions/13751/… 有很好的解释。
【发布时间】：2013-05-20 20:49:27
【问题描述】：
在做了一些研究后找到了解决方案。运行以下命令。
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
对于 Arch Linux，将此行添加到 /etc/sysctl.d/99-sysctl.conf：
fs.inotify.max_user_watches=524288
【讨论】：
-
嗯，它似乎已经解决了我的问题......但是如何？为什么？您是否有任何来源可以解释正在发生的事情（或正在发生的事情）。或者你可以自己做吗？无论如何，谢谢...
-
系统对用户可以观看的文件数量有限制。如果您让 Grunt 与 Dropbox 等其他程序一起运行，您的手表很快就会用完。此命令会增加用户可以拥有的最大手表数量。
-
对于 Arch Linux，将
fs.inotify.max_user_watches=524288添加到/etc/sysctl.d/99-sysctl.conf，然后执行sysctl --system。这也将在重新启动后持续存在。更多详情：wiki.archlinux.org/index.php/Sysctl -
npm dedupe为我清除了它。 issue -
解释：
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf在文件 /etc/sysctl.conf 的末尾写入“fs.inotify.max_user_watches=524288”行"sudo sysctl -p在运行时重新配置内核，加载文件 /etc/sysctl.conf 作为参数
任何时候你需要运行sudo something ... 来修复某些东西，你应该停下来想想发生了什么。虽然这里接受的答案是完全有效的，但它正在治疗症状而不是问题。相当于购买更大的马鞍包来解决以下问题：错误，无法将更多垃圾装载到小马身上。小马已经装了这么多垃圾，小马累得要晕倒了。
另一种选择（可能类似于从小马身上取出多余的垃圾并放入垃圾场）是运行：
npm dedupe
那就恭喜你让小马开心了。
【讨论】：
-
感谢您让小马开心。
-
它到底是做什么的？它肯定解决了我的问题。谢谢@grenade
-
'npm dedupe' 命令遍历你的 npm 模块树，并尽可能地将树中的每个包向上移动。结果是一棵扁平的树。即使没有复制，它也会移动一个包。您可以在docs.npmjs.com/cli/dedupe 阅读更多关于在这种情况下不同版本的模块会发生什么的信息
-
它没有帮助，我尝试使用
sudo，现在它对我有用。 -
就我而言，我的问题似乎是安装了 Dropbox，这似乎使用了很多手表。所以我不得不在接受的答案中使用：
fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p，但 +1 用于教我npm dedupe
尝试grenade's answer 后，您可以使用临时修复：
sudo bash -c 'echo 524288 > /proc/sys/fs/inotify/max_user_watches'
这与kds's answer 的作用相同，但不会持久化更改。如果错误只是在系统正常运行一段时间后发生，这很有用。
【讨论】：
-
这应该是公认的答案，因为问题自然是由当前正在运行的东西引起的，而不是由错误的配置引起的（参见“小马”示例）。
要找出谁在制作 inotify 实例，请尝试以下命令 (source)：
for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr
我的看起来像这样：
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
使用ps -p 2857，我能够将进程2857 识别为sublime_text。只有在关闭 所有 崇高的窗口后，我才能运行我的节点脚本。
【讨论】：
-
vscode 和我一样，但我认为它也与文件监视有关
我在客户端 PC 崩溃后遇到了这个错误，我在服务器上运行的 jest --watch 命令仍然存在，我尝试再次运行 jest --watch。
上述答案中描述的对/etc/sysctl.conf 的补充解决了这个问题，但通过ps aux | grep node 和kill 找到我的旧流程也很重要。
【讨论】：
就我而言，它与在我的 Linux 机器上运行的 vs-code 有关。我忽略了一个关于文件观察器 bla bla 的警告。解决方案在 linux 的 vs-code 文档页面上https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc
解决方案与接受的答案几乎相同（如果不相同），只是对遇到来自 vs-code 的问题后到达这里的任何人都有更多解释。
【讨论】：
就我而言，我发现我有一个针对 Vim 的激进插件，只是重新启动它。
【讨论】：