Grunt watch error - Ожидание ... Неустранимая ошибка: смотреть ENOSPC

Почему я получаю, Waiting...Fatal error: watch ENOSPCкогда я запускаю задачу наблюдения? Как мне решить эту проблему?

После некоторых исследований нашли решение. Запустите приведенную ниже команду.

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

Каждый раз, когда вам нужно бежать, sudo something ...чтобы что-то исправить, вы должны остановиться, чтобы подумать о том, что происходит. Несмотря на то, что принятый здесь ответ является совершенно верным, он рассматривает скорее симптом, чем проблему. Сорта, эквивалентная покупке больших седельных сумок для решения проблемы: ошибка, не может загрузить больше мусора на пони. У Пони уже столько мусора, что пони теряет сознание от истощения.

Альтернативой (возможно, сравнимой с удалением лишнего мусора с пони и размещением на свалке) является запуск:

npm dedupe

Тогда иди поздравляй себя с тем, чтобы сделать пони счастливым.

После попытки ответа на гранату вы можете использовать временное исправление:

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

Это делает то же самое, что и ответ kds , но без сохранения изменений. Это полезно, если ошибка возникает только после некоторого времени работы вашей системы.

Чтобы узнать, кто создает экземпляры inotify , попробуйте эту команду ( источник ):

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. Только после закрытия всех возвышенных окон я смог запустить скрипт своего узла.

Я столкнулся с этой ошибкой после сбоя моего клиентского ПК, jest --watchкоманда, которую я выполнял на сервере, сохранилась, и я попытался запустить jest --watchснова.

Дополнение к /etc/sysctl.confописанному в ответах выше обошло эту проблему, но было также важно найти мой старый процесс через него ps aux | grep nodeи killего.

В моем случае это было связано с vs-кодом, работающим на моей машине с Linux. Я проигнорировал предупреждение, которое выскочило о наблюдателе файла бла бла. Решение находится на странице документации vs-code для linux https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in- это-большой рабочее пространство ошибок-ENOSPC

Решение почти такое же (если не то же самое), что и принятые ответы, просто есть больше объяснений для тех, кто попадает сюда после столкновения с проблемами из vs-кода.

В моем случае я обнаружил, что у меня есть агрессивный плагин для Vim, просто перезапустил его.