解决方法
在终端中输入
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
gulp watch error (ENOSPC)
这周在工作的时候，需要同时启动两个项目。都是用 gulp 做自动化监控，自然不可避免的需要使用到 gulp 的 watch 方法。结果就报标题所示的错误
gulp watch error (ENOSPC)
谷歌一番发现倒也是个挺常见的问题，官方 github 的issues历里也有相关的问题。
原因：
讲道理，这是倒不是 gulp 的问题，而是 linux 系统的问题。与系统的文件系统有关。
一开始我以为跟文件描述符有关， 简单来说，就是每个文件打开的时候都会有一个文件描述符，而 liunx 中操作文件依赖文件描述符，理论上，文件描述符应该随着文件打开而增加，上限应当与内存大小有关。
但实际上 linux 会对文件描述符的数量做限制，总的数量上一般限制为系统内存的10%，在单个进程上也会限制默认值一番是1024。这是为了保证这一资源不会被单个进程消耗殆尽。
在 gulp watch 执行过程中涉及大量的文件操作。比如 scss，babel 对 css，js 文件的预处理编译，输出到开发文件夹中，监控文件的改动等等。随着开发文件的增加，所需的描述符也会增加。
不过实际上并不是，或者说并不直接是。一方面，gulp watch 那小小数量的文件并不足以引起默认的文件描述符的上限；另一方面，看回解决方法，我发现问题不是在文件描述符，而是更高一层的抽象，fs.inotify。
fs.inotify
是 linux 中专门处理文件监控的文件系统事件监控框架。即为文件的增删改查提供响应事件，就像gulp watch 所做那样。但是 inotify 更底层提供比gulp watch 更丰富的事件响应。实际上 node 的 fs 包内相关的方法就依赖 inotify 来实现。而 gulp watch 无疑依赖于 fs 包。inotify 设定文件监控数量的默认值要远比文件描述符要小，更关键的一点是：
inotify 不像 文件描述符，按文件数量计算。inotify 中监控文件增删改查都会导致计数的增加，所以当我们频繁的进行开发的时候，gulp watch 不断监控响应，inotify 就被快速消耗了
end
所以说修改 fs.inotify.max_user_watches 的上限就好了……