Pourquoi est-ce que je reçois le Waiting...Fatal error: watch ENOSPC lorsque j'exécute la tâche de surveillance ? Comment résoudre ce problème ?
Eh bien, cela semble avoir résolu mon problème... Mais comment ? Pourquoi ? Avez-vous des sources qui expliquent ce qui se passe (ou se passait). Ou bien est-ce vous qui l'avez fait ? En tout cas, merci...
Le système fixe une limite au nombre de fichiers pouvant être surveillés par un utilisateur. Vous pouvez rapidement vous retrouver à court de fichiers à surveiller si vous avez Grunt en cours d'exécution avec d'autres programmes comme Dropbox. Cette commande permet d'augmenter le nombre maximum de fichiers à surveiller par un utilisateur.
Pour Arch Linux, ajouter fs.inotify.max_user_watches=524288 à /etc/sysctl.d/99-sysctl.conf puis exécutez sysctl --system . Elle persistera également lors des redémarrages. Pour plus de détails : wiki.archlinux.org/index.php/Sysctl
Chaque fois que vous devez exécuter sudo something ... pour réparer quelque chose, vous devriez faire une pause 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. C'est un peu l'équivalent d'acheter des sacoches plus grandes pour résoudre le problème suivant : erreur, impossible de charger plus de déchets sur le poney. Le poney a déjà chargé tellement de déchets qu'il s'évanouit d'épuisement.
Une autre solution (peut-être comparable à celle qui consiste à retirer les déchets excédentaires du poney et à les mettre à la décharge) consiste à courir :
npm dedupeEnsuite, félicitez-vous d'avoir rendu le poney heureux.
Après avoir essayé réponse de la grenade vous pouvez utiliser une solution temporaire :
sudo bash -c 'echo 524288 > /proc/sys/fs/inotify/max_user_watches'Cela fait la même chose que Réponse de kds mais sans persister dans les changements. Ceci est utile si l'erreur survient après un certain temps de fonctionnement de votre système.
Pour savoir qui fabrique inotify instances essayez cette commande ( source ) :
for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nrLa mienne se présentait comme suit :
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:inotifyUtilisation ps -p 2857 J'ai pu identifier le processus 2857 comme étant sublime_text . Seulement après la fermeture tous sublime Windows, j'ai pu exécuter mon node script.
J'ai rencontré cette erreur après que le PC de mon client soit tombé en panne. jest --watch que j'exécutais sur le serveur a persisté, et j'ai essayé d'exécuter la commande jest --watch encore une fois.
L'ajout de /etc/sysctl.conf décrite dans les réponses ci-dessus a permis de contourner ce problème, mais il était également important de retrouver mon ancien processus via ps aux | grep node y kill il.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
13 votes
Pour tous ceux qui consultent ce document, il ne s'agit pas d'une question spécifique aux
gruntmais tout programme utilisant inotifier en dessous. Une bonne explication est disponible à l'adresse suivante unix.stackexchange.com/questions/13751/ .