Grunt watch 错误 - 等待...致命错误：观看 ENOSPC

Posted 2023-03-07

【中文标题】Grunt watch 错误 - 等待...致命错误：观看 ENOSPC

【英文标题】：Grunt watch error - Waiting...Fatal error: watch ENOSPC

【发布时间】：2013-05-20 20:49:27

【问题描述】：

为什么我在运行监视任务时得到Waiting...Fatal error: watch ENOSPC？ 我该如何解决这个问题？

【问题讨论】：

对于查看此内容的任何人，这不是特定于grunt，而是任何使用inotify 的程序。 unix.stackexchange.com/questions/13751/… 有很好的解释。

【参考方案1】：

在做了一些研究后找到了解决方案。运行以下命令。

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 作为参数

【参考方案2】：

任何时候你需要运行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

【参考方案3】：

尝试grenade's answer 后，您可以使用临时修复：

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

这与kds's answer 的作用相同，但不会持久化更改。如果错误只是在系统正常运行一段时间后发生，这很有用。

【讨论】：

这应该是公认的答案，因为问题自然是由当前正在运行的东西引起的，而不是由错误的配置引起的（参见“小马”示例）。

【参考方案4】：

要找出谁在制作 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 和我一样，但我认为它也与文件监视有关

【参考方案5】：

我在客户端 PC 崩溃后遇到了这个错误，我在服务器上运行的 jest --watch 命令仍然存在，我尝试再次运行 jest --watch。

上述答案中描述的对/etc/sysctl.conf 的补充解决了这个问题，但通过ps aux | grep node 和kill 找到我的旧流程也很重要。

【参考方案6】：

就我而言，它与在我的 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 的问题后到达这里的任何人都有更多解释。

【参考方案7】：

就我而言，我发现我有一个针对 Vim 的激进插件，只是重新启动它。