Відповіді:
Провівши деякі дослідження знайшов рішення. Виконайте команду нижче.
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=524288fs.inotify.max_user_watches=524288до /etc/sysctl.d/99-sysctl.confі потім виконати sysctl --system. Це також буде зберігатися через перезавантаження. Детальніше: wiki.archlinux.org/index.php/Sysctl
npm dedupeочистив це для мене. випуск
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Тоді йдіть, вітайте себе за те, що зробили поні щасливим.
sudoі зараз це працює на мене.
fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pяк у прийнятій відповіді, але +1 для того, щоб навчити менеnpm dedupe
Спробувавши відповідь гранати, ви можете використовувати тимчасове виправлення:
sudo bash -c 'echo 524288 > /proc/sys/fs/inotify/max_user_watches'Це робить те саме, що відповідь kds , але не зберігаючи зміни. Це корисно, якщо помилка виникає лише через деякий час роботи вашої системи.
Щоб дізнатися, хто створює ініціативні екземпляри , спробуйте цю команду ( джерело ):
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-коду для Linux https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in- це велика робоча область-помилка-enospc
Рішення майже таке ж (якщо не таке), як прийняті відповіді, просто має більше пояснень для тих, хто потрапляє сюди після наткнення на проблеми з vs-кодом.
У моєму випадку я виявив, що у мене агресивний плагін для Vim, просто перезапустив його.
gruntбудь-якої програми, яка використовує інотифікувати під ним. На unix.stackexchange.com/questions/13751/… є гарне пояснення .