就我而言，这与在Linux机器上运行的vs代码有关。我忽略了有关文件监视程序bla bla的警告。该解决方案位于Linux的vs-code docs页面上，网址为https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-这个大工作区错误enospc

解决方案与接受的答案几乎相同（如果不同），只是为遇到vs代码问题后到达这里的任何人提供了更多解释。

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

/etc/sysctl.conf上面的答案中描述的其他内容都可以解决此问题，但是通过ps aux | grep node和找到我的旧流程也很重要kill。

要找出谁在制作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。只有关闭所有崇高窗口后，我才能运行我的节点脚本。

每当您需要运行sudo something ...以修复某些问题时，您都应该暂停思考正在发生的事情。虽然这里公认的答案是完全正确的，但它是在治疗症状而不是问题。Sorta相当于购买更大的鞍袋来解决以下问题：错误，无法将更多垃圾装载到小马上。小马已经装了太多垃圾，以至于小马精疲力尽。

一种替代方法（也许相当于从小马身上去除多余的垃圾并放入转储中）是运行：

npm dedupe

然后祝贺自己使小马快乐。

经过研究后找到了解决方案。运行以下命令。

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