Grunt watch error - Waiting… Fatal error: watch ENOSPC

524

Pourquoi est-ce que j'obtiens le Waiting...Fatal error: watch ENOSPClorsque j'exécute la tâche de surveillance? Comment résoudre ce problème?

node.js gruntjs kds
la source
13
Pour tous ceux qui le consultent, ce n'est pas spécifique à grunttout programme utilisant inotify en dessous. Il y a une bonne explication sur unix.stackexchange.com/questions/13751/… .
Jesse Good

Réponses:

1359

Après avoir fait quelques recherches, j'ai trouvé la solution. Exécutez la commande ci-dessous.

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

Pour Arch Linux, ajoutez cette ligne à /etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288
kds
la source
45
Eh bien, il semble avoir résolu mon problème ... Mais comment? Pourquoi? Avez-vous des sources qui expliquent ce qui se passe (ou se passait). Ou pouvez-vous le faire vous-même? Quoi qu'il en soit, merci ...
slacktracer
116
Le système a une limite au nombre de fichiers pouvant être regardés par un utilisateur. Vous pouvez manquer de montres assez rapidement si vous utilisez Grunt avec d'autres programmes comme Dropbox. Cette commande augmente le nombre maximum de montres qu'un utilisateur peut avoir.
Benjamin Manns le
62
Pour Arch Linux ajouter fs.inotify.max_user_watches=524288à /etc/sysctl.d/99-sysctl.confpuis exécuter sysctl --system. Cela persistera également lors des redémarrages. Pour plus de détails: wiki.archlinux.org/index.php/Sysctl
tnajdek
38
npm dedupeéclairci pour moi. question
reergymerej
25
explication: echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf écrit à la fin du fichier /etc/sysctl.conf la ligne "fs.inotify.max_user_watches = 524288" sudo sysctl -p reconfigure le noyau au moment de l'exécution, en chargeant le fichier /etc/sysctl.conf comme paramètre
kds
186

Chaque fois que vous devez exécuter sudo something ...pour réparer quelque chose, vous devez vous arrêter pour réfléchir à ce qui se passe. Bien que la réponse acceptée ici soit parfaitement valable, elle traite le symptôme plutôt que le problème. Sorta l'équivalent d'acheter de plus grandes sacoches pour résoudre le problème de: erreur, ne peut pas charger plus de déchets sur le poney. Le poney a tellement de déchets déjà chargés, que le poney s'évanouit d'épuisement.

Une alternative (peut-être comparable à retirer les déchets excédentaires du poney et à les mettre dans la décharge) est de lancer:

npm dedupe

Ensuite, allez vous féliciter d'avoir rendu le poney heureux.

grenade
la source
42
Merci d'avoir rendu le poney heureux.
Christian
2
Que fait-il exactement? Cela a certainement résolu mon problème. Merci @grenade
Arjun KR
4
La commande 'npm dedupe' parcourt votre arborescence de modules npm et déplace autant que possible chaque paquet dans l'arborescence. Le résultat est un arbre plat. Il déplace un package même s'il n'est pas dupliqué. Vous pouvez en savoir plus sur ce qui arrive aux différentes versions de modules dans ce cas, à docs.npmjs.com/cli/dedupe
Arun Reddy
1
ça n'a pas aidé, j'ai essayé avec sudoet maintenant ça marche pour moi.
asedsami
6
Dans mon cas, mon problème semble être d'avoir Dropbox installé qui semble utiliser beaucoup de montres. J'ai donc dû utiliser: fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pcomme dans la réponse acceptée, mais +1 pour m'apprendrenpm dedupe
Johann Echavarria
36

Après avoir essayé la réponse de grenade, vous pouvez utiliser une correction temporaire:

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

Cela fait la même chose que la réponse de kds , mais sans persister les changements. Ceci est utile si l'erreur se produit juste après une certaine disponibilité de votre système.

Arne L.
la source
3
Cela devrait être la réponse acceptée car le problème est naturellement causé par ce qui fonctionne en ce moment et non par une mauvaise configuration (voir l'exemple "pony").
arielnmz
7

Pour savoir qui crée des instances inotify , essayez cette commande ( source ):

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

Le mien ressemblait à ceci:

 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

En utilisant ps -p 2857, j'ai pu identifier le processus 2857 comme sublime_text. Ce n'est qu'après avoir fermé toutes les fenêtres sublimes que j'ai pu exécuter mon script de nœud.

Michael Lewis
la source
la même chose avec moi pour vscode mais je pense que cela est également lié aux montres de fichiers
pcnate
3

J'ai rencontré cette erreur après le crash de mon PC client, la jest --watchcommande que j'exécutais sur le serveur a persisté et j'ai essayé de relancer jest --watch.

L'ajout /etc/sysctl.confdécrit dans les réponses ci-dessus a fonctionné autour de ce problème, mais il était également important de trouver mon ancien processus via ps aux | grep nodeet kill.

Aaron
la source
0

Dans mon cas, c'était lié au vs-code exécuté sur ma machine Linux. J'ai ignoré un avertissement qui est apparu à propos de l'observateur de fichiers bla bla. La solution se trouve sur la page des documents vs-code pour linux https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in- this-large-workspace-error-enospc

La solution est presque la même (sinon la même) que les réponses acceptées, a juste plus d'explications pour quiconque arrive ici après avoir rencontré les problèmes de vs-code.

azeez
la source
0

Dans mon cas, j'ai trouvé que j'avais un plugin agressif pour Vim, je viens de le redémarrer.

Vitaly Zdanevich
la source