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

349

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

node.js

— Giffo
fuente

1

"ENOSPC" significa que no hay espacio en la unidad, entonces, ¿dónde guarda su archivo? o tal vez / tmp está lleno?

— Jacob A.

Guardo archivos en / dev / xvda1. ¿Puedo hacer rm -rf / tmp / *?

— Giffo

1

sí, pero no creo que 1mb sea suficiente para cargar archivos, así que cambie el tmp-dir a otra ubicación como en la respuesta de Blu Angel

— Jacob A.

3

Parece que su caso de uso puede ser diferente, pero aquí hay una gran solución a este problema con otra pregunta SO.

— Isaac Gregson

Para cualquiera que se encuentre con esto, vea también esta respuesta . Usar gruñido y trago puede usar muchos relojes, por lo que esta respuesta detalla cómo aumentar eso.

— Seiyria

1273

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

— Murali Krishna
fuente

24

Aquí está lo que hace. github.com/guard/listen/wiki/…

— Agus Syahputra

2

No es un número aleatorio. Cada reloj inotify utilizado ocupa 540 bytes (sistema de 32 bits) o 1 kB (doble en 64 bits). Esto sale de la memoria del núcleo, que no se puede cambiar. Entonces, suponiendo que establezca el máximo en 524288, y que todos se hayan usado (improbable), estaría usando aprox. 256 MB / 512 MB de memoria de kernel de 32 bits / 64 bits.

— Murali Krishna

Teóricamente no hay un valor máximo, siempre que tenga suficiente RAM. En la práctica, 524288 ha sido oficialmente recomendado por las aplicaciones, y la gente lo ha estado configurando en 2 millones, con el uso de memoria que lo acompaña.

— Murali Krishna el

Esto me ha ayudado a resolver el problema, también este enlace github.com/guard/listen/wiki/… tiene todos los detalles. Gracias

— amitsin6h

¿Alguien más encuentra extraño que el error que sale es simplemente ENOSPC? ¿Por qué no tener una descripción justo después de la salida ENOSPC - no space on drive? Claro, el código de error tiene sentido una vez que sabes lo que significa ( E rror NO SP un C e), pero ¿por qué no ofrecer a los usuarios información de que en la delantera?

— Shadoninja

73

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.

— Blu
fuente

Limpié la carpeta / tmp y cambié la carpeta npm temp, pero tengo el mismo problema. npm config get tmpshow / vol / deploy / tmp

— Giffo

¿Puedes mostrar tu salida otra vez? salida que obtienes después de cambiar el directorio

— Blu

events.js:71 throw arguments[1]; // Unhandled 'error' event Error: ENOSPC, write

— Giffo

1

¿tienes error de escucha? si no, entonces escriba uno y luego verifique la salida resultante

— Blu

72

mal, este error ocurre a menudo en los espacios de trabajo del desarrollador cuando se miran archivos (a través de grunt / gulp). Esto tiene que ver con un límite de Unix de cuántos archivos puede ver un proceso (observación nativa). La otra respuesta (echo fs.inotify.max_user_watches = 524288) es la solución en esos casos.

— cancerbero

26

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 .

— orbiteleven
fuente

no funciona :(

— JRichardsz

20

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.

— Danrley Willyan
fuente

2

Tengo ese problema forever,solucionado cuando creo el archivo .foreverignorey lo agrego a la carpetanode_modules.

— Vilintritenmert

7

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

— Bjorn Reppen
fuente

El problema volvió después de reiniciar. Hacer dedupeayudado.

— Parnab Sanyal

4

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

— Woodrow Barlow
fuente

Gracias, esto resolvió mi problema.

— Josh

¡¡Gracias!! ¡su solución temporal funciona!

— JRichardsz

3

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

— Manolo de la Vega
fuente

2

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

— Denys Vitali
fuente

1

Olvidé especificarlo, sí, estaba en la misma situación: Arch + GNOME

— Denys Vitali

2

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

— Pradeep Kumar
fuente

2

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

— Daniel Kmak
fuente

2

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.

— Ghayyas Mubashir
fuente

esto realmente funciona, ¿por qué es rechazado? Es la pregunta. Pero resuelve el problema, entonces, ¿qué necesitas más?

— AlexNikonov

1

No sé, puede que las personas tengan algún problema personal conmigo. jajaja

— Ghayyas Mubashir

1

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

— nérico
fuente

1

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

— Aram Paronikyan
fuente

-15

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

Ejemplo:

sudo gulp dev

— Sebastien Chartier
fuente

55

¡Esto es peligroso! Probablemente tuvo éxito porque un cierto porcentaje de espacio en disco está reservado para la raíz, lo que no resuelve el problema central: no hay espacio disponible como usuario sin privilegios (en la ubicación de destino).

— Liam Dawson

Usar sudo es una excelente manera de hacer que las cosas sucedan, pero la mayoría de las personas no comprenden todo lo que sucede cuando se usa sudo. Particularmente con los módulos npm y npm, el uso de sudo puede provocar que root realice cosas que el usuario no desea que se realicen por root, como la creación de archivos o el uso de puertos protegidos. Básicamente, el consejo de "usar sudo" cae de bruces (quizás después de tropezar y mirar al sol por un momento) en lo que respecta a nvm / npm / node.

— bschlueter