Respuestas:
Después de investigar un poco encontró la solución. Ejecute el siguiente comando.
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pPara Arch Linux, agregue esta línea a /etc/sysctl.d/99-sysctl.conf:
fs.inotify.max_user_watches=524288fs.inotify.max_user_watches=524288a /etc/sysctl.d/99-sysctl.confy luego ejecutar sysctl --system. Esto también persistirá en todos los reinicios. Para más detalles: wiki.archlinux.org/index.php/Sysctl
npm dedupeLo aclaró para mí. problema
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf escribe al final del archivo /etc/sysctl.conf la línea "fs.inotify.max_user_watches = 524288" sudo sysctl -p reconfigura el kernel en tiempo de ejecución, cargando el archivo /etc/sysctl.conf como parámetro
Cada vez que necesites correr sudo something ...para arreglar algo, deberías hacer una pausa para pensar en lo que está sucediendo. Si bien la respuesta aceptada aquí es perfectamente válida, trata el síntoma en lugar del problema. Ordena el equivalente de comprar alforjas más grandes para resolver el problema de: error, no se puede cargar más basura en el pony. Pony ya tiene tanta basura cargada, que el pony se desmaya por el agotamiento.
Una alternativa (quizás comparable a quitar el exceso de basura del pony y colocarlo en el basurero) es ejecutar:
npm dedupeEntonces felicítate por hacer feliz a Pony.
sudoy ahora está funcionando para mí.
fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pcomo en la respuesta aceptada, pero +1 para enseñarmenpm dedupe
Después de probar la respuesta de la granada, puede usar una solución temporal:
sudo bash -c 'echo 524288 > /proc/sys/fs/inotify/max_user_watches'Esto hace lo mismo que la respuesta de kds , pero sin persistir en los cambios. Esto es útil si el error solo ocurre después de un tiempo de actividad de su sistema.
Para averiguar quién está haciendo instancias de inotify , pruebe este comando ( fuente ):
for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nrEl mío se veía así:
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:inotifyUtilizando ps -p 2857, pude identificar el proceso 2857 como sublime_text. Solo después de cerrar todas las ventanas sublimes pude ejecutar mi script de nodo.
Me encontré con este error después de que mi PC cliente se bloqueó, el jest --watchcomando que estaba ejecutando en el servidor persistió e intenté ejecutarlo jest --watchnuevamente.
La adición al /etc/sysctl.confdescrito en las respuestas anteriores dio evitar este problema, sino que también era importante encontrar mi antiguo proceso a través ps aux | grep nodey killél.
En mi caso, estaba relacionado con el código vs que se ejecuta en mi máquina Linux. Ignoré una advertencia que apareció sobre el observador de archivos bla bla. La solución está en la página de documentos vs-code para 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 solución es casi la misma (si no la misma) que las respuestas aceptadas, solo tiene más explicaciones para cualquiera que llegue aquí después de encontrarse con los problemas del código vs.
En mi caso, descubrí que tengo un complemento agresivo para Vim, simplemente lo reinicié.
gruntningún programa que use inotify debajo. Hay una buena explicación en unix.stackexchange.com/questions/13751/… .