Grunt ver error – Esperando … Error fatal: ver ENOSPC

¿Por qué obtengo el Waiting...Fatal error: watch ENOSPC cuando ejecuto la tarea del reloj? ¿Cómo resuelvo este problema?

Después de investigar, encontré la solución. Ejecute el siguiente comando.

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

Para Arch Linux, agregue esta línea a /etc/sysctl.d/99-sysctl.conf:

 fs.inotify.max_user_watches=524288 

Cada vez que necesite ejecutar sudo something ... para arreglar algo, debería hacer una pausa para pensar en lo que está sucediendo. Si bien la respuesta aceptada aquí es perfectamente válida, es tratar el síntoma en lugar del problema. Sorta el equivalente de comprar alforjas más grandes para resolver el problema de: error, no se puede cargar más basura en poni. Pony tiene mucha basura ya cargada, ese pony se está desmayando de cansancio.

Una alternativa (tal vez comparable con quitar la basura en exceso del poni y colocarla en el basurero) es ejecutar:

 npm dedupe 

Entonces ve a felicitarte por hacer feliz a Pony.

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 simplemente ocurre después de algún tiempo de actividad de su sistema.

Para saber 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 -nr 

El 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:inotify 

Usando 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 la PC de mi cliente se bloqueó, el comando jest --watch que estaba ejecutando en el servidor persistió e intenté ejecutar jest --watch nuevamente–.

La adición a /etc/sysctl.conf descrita en las respuestas anteriores solucionó este problema, pero también fue importante encontrar mi antiguo proceso a través de ps aux | grep node ps aux | grep node y kill .

En Linux, corrige esto con el comando:

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