Risposte:
Dopo aver fatto qualche ricerca, ho trovato la soluzione. Esegui il comando seguente.
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pPer Arch Linux aggiungi questa riga a /etc/sysctl.d/99-sysctl.conf:
fs.inotify.max_user_watches=524288fs.inotify.max_user_watches=524288ai /etc/sysctl.d/99-sysctl.confe quindi eseguire sysctl --system. Ciò persisterà anche durante i riavvii. Per maggiori dettagli: wiki.archlinux.org/index.php/Sysctl
npm dedupechiarito per me. problema
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf scrive alla fine del file /etc/sysctl.conf la riga "fs.inotify.max_user_watches = 524288" sudo sysctl -p riconfigura il kernel in fase di esecuzione, caricando il file /etc/sysctl.conf come parametro
Ogni volta che devi correre sudo something ...per riparare qualcosa, dovresti fare una pausa per pensare a cosa sta succedendo. Mentre la risposta accettata qui è perfettamente valida, tratta il sintomo piuttosto che il problema. Sorta l'equivalente dell'acquisto di bisacce più grandi per risolvere il problema di: errore, non è possibile caricare più immondizia sul pony. Pony ha già tanta spazzatura già caricata, che il pony sta svenendo per la stanchezza.
Un'alternativa (forse paragonabile a rimuovere la spazzatura in eccesso dal pony e metterla nella discarica), è quella di eseguire:
npm dedupeQuindi congratulati con te stesso per aver reso felice Pony.
sudoe ora funziona per me.
fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pcome nella risposta accettata, ma +1 per insegnarminpm dedupe
Dopo aver provato la risposta di granata puoi usare una soluzione temporanea:
sudo bash -c 'echo 524288 > /proc/sys/fs/inotify/max_user_watches'Questo fa la stessa cosa della risposta di kds , ma senza persistere nelle modifiche. Ciò è utile se l'errore si verifica solo dopo un periodo di attività del sistema.
Per scoprire chi sta creando istanze inotify , prova questo comando ( fonte ):
for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nrIl mio sembrava così:
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:inotifyUtilizzando ps -p 2857, sono stato in grado di identificare il processo 2857 come sublime_text. Solo dopo aver chiuso tutte le finestre sublimi sono stato in grado di eseguire il mio script del nodo.
Ho riscontrato questo errore dopo l'arresto anomalo del mio PC client, il jest --watchcomando che stavo eseguendo sul server ha persistito e ho provato a eseguirlo di jest --watchnuovo.
L'aggiunta /etc/sysctl.confdescritto nelle risposte sopra lavorato a questo problema, ma era anche importante trovare il mio vecchio processo tramite ps aux | grep nodee killesso.
Nel mio caso era correlato al vs-code in esecuzione sulla mia macchina Linux. Ho ignorato un avviso che è spuntato sul file watcher bla bla. La soluzione è nella pagina dei documenti vs-code per linux https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in- questo-grande-lavoro-error-ENOSPC
La soluzione è quasi la stessa (se non la stessa) delle risposte accettate, ha solo più spiegazioni per chiunque arrivi qui dopo aver incontrato i problemi di vs-code.
Nel mio caso ho scoperto di avere un plug-in aggressivo per Vim, appena riavviato.
gruntma sotto qualsiasi programma che utilizza inotify . C'è una buona spiegazione su unix.stackexchange.com/questions/13751/… .