Réponses:
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 -pPour Arch Linux, ajoutez cette ligne à /etc/sysctl.d/99-sysctl.conf:
fs.inotify.max_user_watches=524288fs.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
npm dedupeéclairci pour moi. question
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
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 dedupeEnsuite, allez vous féliciter d'avoir rendu le poney heureux.
sudoet maintenant ça marche pour moi.
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
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.
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 -nrLe 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.
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.
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.
Dans mon cas, j'ai trouvé que j'avais un plugin agressif pour Vim, je viens de le redémarrer.
grunttout programme utilisant inotify en dessous. Il y a une bonne explication sur unix.stackexchange.com/questions/13751/… .