Błąd zegarka Grunt - Oczekiwanie… Błąd krytyczny: obejrzyj ENOSPC

524

Dlaczego dostaję czas, Waiting...Fatal error: watch ENOSPCgdy uruchamiam zadanie zegarka? Jak rozwiązać ten problem?

node.js gruntjs

— kds
źródło

13

Dla każdego, kto to ogląda, nie dotyczy to gruntżadnego programu używającego inotify poniżej. Istnieje dobre wytłumaczenie na stronie unix.stackexchange.com/questions/13751/… .

— Jesse Good

1359

Po przeprowadzeniu niektórych badań znalazłem rozwiązanie. Uruchom poniższe polecenie.

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

W przypadku Arch Linux dodaj tę linię do /etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288

— kds
źródło

45

Cóż, wydaje się, że rozwiązało to mój problem ... Ale jak? Dlaczego? Czy masz jakieś źródła, które wyjaśniają, co się dzieje (lub co się dzieje). A może sam to zrobisz? W każdym razie dzięki ...

— slacktracer,

116

System ma ograniczenie liczby plików, które użytkownik może oglądać. Możesz szybko skończyć zegarki, jeśli Grunt działa z innymi programami, takimi jak Dropbox. To polecenie zwiększa maksymalną liczbę zegarków, jakie może mieć użytkownik.

— Benjamin Manns

62

Dla Arch Linux dodać fs.inotify.max_user_watches=524288do /etc/sysctl.d/99-sysctl.conf, a następnie wykonać sysctl --system. Będzie to również obowiązywać podczas ponownego uruchamiania. Aby uzyskać więcej informacji: wiki.archlinux.org/index.php/Sysctl

— tnajdek

38

npm dedupewyjaśniono mi to. problem

— reergymerej

25

wyjaśnienie: echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf zapisuje na końcu pliku /etc/sysctl.conf wiersz „fs.inotify.max_user_watches = 524288” sudo sysctl -p rekonfiguruje jądro w czasie wykonywania, ładując plik /etc/sysctl.conf jako parametr

— kds

186

Za każdym razem, gdy musisz pobiec, sudo something ...aby coś naprawić, zatrzymaj się, aby pomyśleć o tym, co się dzieje. Chociaż przyjęta tutaj odpowiedź jest całkowicie poprawna, to raczej leczenie objawu niż problemu. Sortuj odpowiednik kupowania większych sakw, aby rozwiązać problem: błąd, nie można załadować więcej śmieci na kucyka. Kucyk ma już tyle śmieci, że kucyk zemdlał z wyczerpania.

Alternatywą (być może porównywalną do usuwania nadmiaru śmieci z kucyka i umieszczania go w śmietniku) jest uruchomienie:

npm dedupe

Następnie pogratuluj sobie szczęścia.

— granat
źródło

42

Dzięki za uszczęśliwienie kucyka.

— Christian

2

Co to dokładnie robi? Z pewnością rozwiązało to mój problem. Dzięki @ granat

— Arjun KR

4

Polecenie „npm dedupe” przechodzi przez drzewo modułów npm i przenosi każdy pakiet w górę drzewa tak bardzo, jak to możliwe. Rezultatem jest płaskie drzewo. Przenosi pakiet, nawet jeśli nie jest duplikowany. Możesz przeczytać więcej o tym, co dzieje się z różnymi wersjami modułów w tym przypadku, na docs.npmjs.com/cli/dedupe

— Arun Reddy

1

to nie pomogło, próbowałem sudoi teraz działa dla mnie.

— asedsami,

6

W moim przypadku moim problemem jest zainstalowanie Dropboksa, który wydaje się używać wielu zegarków. Musiałem więc użyć: fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pjak w zaakceptowanej odpowiedzi, ale +1 za nauczenie mnienpm dedupe

— Johann Echavarria

36

Po wypróbowaniu odpowiedzi granatu możesz użyć tymczasowej poprawki:

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

To robi to samo co odpowiedź kds , ale bez utrwalania zmian. Jest to przydatne, jeśli błąd pojawia się po pewnym czasie przestoju systemu.

— Arne L.
źródło

3

To powinna być zaakceptowana odpowiedź, ponieważ problem jest naturalnie spowodowany tym, co się dzieje w tej chwili, a nie złą konfiguracją (patrz przykład „kucyka”).

— arielnmz

7

Aby dowiedzieć się, kto tworzy instancje inotify , wypróbuj to polecenie ( źródło ):

for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr

Mój wyglądał tak:

 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

Używając ps -p 2857, byłem w stanie zidentyfikować proces 2857 jako sublime_text. Dopiero po zamknięciu wszystkich wysublimowanych okien mogłem uruchomić skrypt węzła.

— Michael Lewis
źródło

to samo dotyczy mnie dla vscode, ale myślę, że jest to również związane z zegarkami do plików

— PCLUT

3

Wystąpił ten błąd po awarii komputera klienckiego, jest --watchpolecenie, które uruchomiłem na serwerze, pozostało i próbowałem uruchomić jest --watchponownie.

Dodatek /etc/sysctl.confopisany w powyższych odpowiedziach dotyczył tego problemu, ale ważne było również, aby znaleźć mój stary proces za pośrednictwem ps aux | grep nodei killto.

— Aaron
źródło

0

W moim przypadku było to związane z działaniem kodu vs na moim komputerze z systemem Linux. Zignorowałem ostrzeżenie, które pojawiło się na temat obserwatora plików bla bla. Rozwiązanie znajduje się na stronie dokumentacji vs-code dla systemu Linux https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in- this-large-workspace-error-enospc

Rozwiązanie jest prawie takie samo (jeśli nie takie samo) jak zaakceptowane odpowiedzi, po prostu ma więcej wyjaśnień dla każdego, kto pojawi się tutaj po napotkaniu problemów z vs-code.

— azeez
źródło

0

W moim przypadku stwierdziłem, że mam agresywną wtyczkę do Vima, właśnie ją ponownie uruchomiłem.

— Witalij Zdanevich
źródło