Node.js: ¿qué es el error ENOSPC y cómo resolverlo?

Tengo un problema con Node.js y al subir archivos al servidor. Para subir archivos al servidor, uso este complemento . Al iniciar la carga de archivos al servidor, el proceso Node.js se bloqueó y mostró un error:

Error: ENOSPC.

El código del servidor no se ejecuta.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.9G  4.1G  3.5G  55% /
udev            288M  8.0K  288M   1% /dev
tmpfs           119M  168K  118M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            296M     0  296M   0% /run/shm
/dev/xvdf       9.9G  3.0G  6.5G  32% /vol
overflow        1.0M  1.0M     0 100% /tmp

Ejecute el siguiente comando para evitar ENOSPC:

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

Luego ejecuta:

sysctl --system

Esto también persistirá en todos los reinicios. Fuente de detalles técnicos

ENOSPC significa que no hay espacio en el disco.

Quizás /tmpestá lleno? Puede configurar npmpara usar una carpeta temporal diferente configurando npm config set tmp /path/to/some/other/dir, o tal vez eliminar todo de la /tmpcarpeta.

Fuente: npm 1.1.21 no puede escribir, ENOSPC en el repositorio de npm en github.

Tenga en cuenta que resolví mi problema de la manera que se describe en la fuente anterior. Sin embargo, vea la respuesta de Murali Krishna a continuación, que es más completa.

No puedo dar crédito por esto, pero @grenade señaló que npm dedupesolucionará la causa (demasiados archivos) y no el síntoma.

Fuente: Error de reloj de Grunt - Esperando ... Error fatal: reloj de ENOSPC .

Una forma simple de resolver mi problema fue:

npm cache clear

npm o un proceso controlado por él está viendo demasiados archivos. Actualizar max_user_watches en el nodo de compilación puede solucionarlo para siempre. Para debian ponga lo siguiente en la terminal:

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

Si quieres saber cómo aumentar la cantidad de observadores de inotify solo haz clic en el enlace.

Reiniciar la máquina resolvió el problema para mí. Primero intenté limpiar, /tmp/pero el nodo aún se quejaba.

En Linux, es probable que esto sea un límite en la cantidad de archivos observados.

El servidor de desarrollo usa inotify para implementar la recarga en caliente. La API de inotify permite que el servidor de desarrollo vea archivos y reciba notificaciones cuando cambien.

El límite predeterminado de observación del archivo inotify varía de una distribución a otra (8192 en Fedora). Las necesidades del servidor de desarrollo a menudo exceden este límite.

El mejor enfoque es intentar aumentar el límite de observación de archivos temporalmente, luego hacer un cambio de configuración permanente si está satisfecho con él. Sin embargo, tenga en cuenta que esto cambia la configuración de todo su sistema, no solo el nodo.

Para ver su límite actual:

sysctl fs.inotify.max_user_watches

Para establecer temporalmente un nuevo límite:

# this limit will revert after reset
sudo sysctl fs.inotify.max_user_watches=524288
sudo sysctl -p
# now restart the server and see if it works

Para establecer un límite permanente:

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

En Ubuntu 18.04, probé un truco que usé para reactivar el archivo mirando por ionic / node, y también funciona aquí. Esto podría ser útil para aquellos que no tienen acceso a los archivos conf del sistema.

CHOKIDAR_USEPOLLING=1 npm start

Resolví mi problema eliminando todos los procesos de control de rastreadores (podría intentarlo si usa GDM, obviamente no es su caso si el script se ejecuta en un servidor)

tracker-control -r

Mi configuración: Arch con GNOME 3

Si su /tmpmontaje en un sistema de archivos de Linux se monta como desbordamiento (a menudo con un tamaño de 1 MB), esto probablemente se deba a que no especificó /tmpcomo su propia partición y su sistema de archivos raíz se llenó y /tmpse volvió a montar como respaldo.

Para solucionar esto después de que haya despejado el espacio, simplemente desmonte el respaldo y debería volver a montar en su punto original:

sudo umount overflow

Si encuentra este error al intentar ejecutar el ember servercomando, realice un rm -rf tmpdirectorio. Luego corre de ember snuevo. Me ayudó.

Estaba teniendo el mismo error. Mientras ejecuto la aplicación Reactjs. Lo que hago es eliminar la carpeta node_modules y escribir e instalar node_modules nuevamente. Esto elimina el error.

Para mí, había alcanzado el número máximo de archivos que un usuario puede tener

Verifique sus números con quota -sy que el número debajo de los archivos no esté demasiado cerca de la cuota

Esto suena muy extraño, pero sí, un reinicio del sistema o me killall noderesuelve el problema.

En mi caso, en Linux, sudoing solucionó el problema.

Ejemplo:

sudo gulp dev