Node.js: cos'è l'errore ENOSPC e come risolverlo?

349

Ho un problema con Node.js e il caricamento di file sul server. Per caricare file sul server uso questo plugin . Quando si avvia il caricamento del file sul server, il processo Node.js si è arrestato in modo anomalo e mostra errore:

Errore: ENOSPC.

Il codice del server non viene eseguito.

$ 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
fonte

1

"ENOSPC" significa che non c'è spazio sull'unità, quindi dove salvi il tuo file? o forse / tmp è pieno?

— Jacob A.

Salvo i file in / dev / xvda1. Posso creare rm -rf / tmp / *?

— Giffo,

1

sì, ma non credo che 1mb sia sufficiente per i fileuploads, quindi cambia la directory tmp in un'altra posizione come nella risposta di Blu Angel

— Jacob A.

3

Sembra che il tuo caso d'uso potrebbe essere diverso, ma ecco un'ottima soluzione a questo problema da un'altra domanda SO.

— Isaac Gregson,

Per chiunque si imbatta in questo, controlla anche questa risposta . L'uso di grunt e gulp può usare molti orologi, quindi questa risposta spiega come aumentarlo.

— Seiyria,

1273

Eseguire il comando seguente per evitare ENOSPC:

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

Per Arch Linux aggiungi questa riga a /etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288

Quindi eseguire:

sysctl --system

Ciò persisterà anche durante i riavvii. Fonte dei dettagli tecnici

— Murali Krishna
fonte

24

Ecco cosa fa. github.com/guard/listen/wiki/…

— Agus Syahputra,

2

Non è un numero casuale. Ogni orologio inotify utilizzato occupa 540 byte (sistema a 32 bit) o 1 kB (doppio - su 64 bit). Questo viene fuori dalla memoria del kernel, che non è sostituibile. Quindi, supponendo che tu abbia impostato il massimo a 524288 e che tutti fossero usati (improbabile), useresti ca. 256 MB / 512 MB di memoria del kernel a 32 bit / 64 bit.

— Murali Krishna,

Teoricamente non esiste un valore massimo, purché si disponga di RAM sufficiente. In pratica, 524288 è stato ufficialmente raccomandato dalle app e le persone lo hanno impostato su 2 milioni, con l'utilizzo della memoria di accompagnamento.

— Murali Krishna,

Questo mi ha aiutato a risolvere il problema anche questo link github.com/guard/listen/wiki/… ha tutti i dettagli. Grazie

— amitsin6h

Qualcun altro trova strano che l'errore che viene fuori è semplicemente ENOSPC? Perché non avere una descrizione subito dopo l'output ENOSPC - no space on drive? Certo, il codice di errore ha senso una volta che sai cosa significa ( E rror NO SP a C e), ma perché non dare agli utenti queste informazioni in anticipo?

— Shadoninja,

73

ENOSPC significa che non c'è spazio sull'unità.

Forse /tmpè pieno? È possibile configurare npml'utilizzo di una cartella temporanea diversa impostando npm config set tmp /path/to/some/other/diro forse eliminare tutto dalla /tmpcartella.

Fonte: npm 1.1.21 impossibile scrivere, ENOSPC nel repository npm in github.

Nota ho risolto il mio problema nel modo descritto nella fonte sopra. Tuttavia, vedi la risposta di Murali Krishna di seguito, che è più completa.

— Blu
fonte

Ho pulito la cartella / tmp e ho cambiato la cartella npm temp, ma ho lo stesso problema. npm config get tmpshow / vol / deploy / tmp

— Giffo

puoi mostrare di nuovo il tuo out messo? output che ottieni Dopo aver cambiato dir

— Blu

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

— Giffo,

1

hai ascoltatore di errori? se non scrivere uno e quindi controllare l'output risultante

— Blu

72

sbagliato, questo errore si verifica spesso nelle aree di lavoro degli sviluppatori durante la visione dei file (tramite grunt / gulp). Ciò ha a che fare con un limite unix di quanti file può guardare un processo (controllo nativo). L'altra risposta (echo fs.inotify.max_user_watches = 524288) è la soluzione in questi casi.

— cancerbero,

26

Non posso crederci , ma @grenade ha sottolineato che npm deduperisolverà la causa (troppi file) e non il sintomo.

Fonte: errore Grunt Watch - In attesa ... Errore irreversibile: watch ENOSPC .

— orbiteleven
fonte

non funziona :(

— JRichardsz,

20

Un modo semplice per risolvere il mio problema era:

npm cache clear

npm o un processo controllato da esso sta guardando troppi file. L'aggiornamento di max_user_watches sul nodo build può risolverlo per sempre. Per debian mettere quanto segue sul terminale:

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

Se vuoi sapere come aumentare la quantità di inotify watcher, fai clic sul link.

— Danrley Willyan
fonte

2

Ho forever,risolto questo problema quando creo il file .foreverignoree lo aggiungo alla cartellanode_modules.

— Vilintritenmert

7

Il riavvio della macchina ha risolto il problema per me. Prima ho provato a pulire /tmp/ma il nodo si stava ancora lamentando.

— Bjorn Reppen
fonte

Il problema è tornato dopo il riavvio. Fare dedupeaiutato.

— Parnab Sanyal,

4

Su Linux, questo è probabilmente un limite al numero di file watch.

Il server di sviluppo utilizza inotify per implementare il hot-ricaricamento. L'API inotify consente al server di sviluppo di guardare i file e ricevere una notifica quando cambiano.

Il limite predefinito di controllo dei file inotify varia da distribuzione a distribuzione (8192 su Fedora). Le esigenze del server di sviluppo spesso superano questo limite.

L'approccio migliore è provare ad aumentare temporaneamente il limite di controllo file, quindi apportare una modifica permanente alla configurazione se ne sei soddisfatto. Si noti, tuttavia, che ciò modifica la configurazione dell'intero sistema, non solo il nodo.

Per visualizzare il limite corrente:

sysctl fs.inotify.max_user_watches

Per impostare temporaneamente un nuovo limite:

# 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

Per impostare un limite permanente:

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

— Woodrow Barlow
fonte

Grazie per aver risolto il mio problema.

— Josh

Grazie!! la tua soluzione temporanea funziona!

— JRichardsz,

3

Su Ubuntu 18.04, ho provato un trucco che ho usato per riattivare la visione dei file tramite ionic / node, e funziona anche qui. Questo potrebbe essere utile per coloro che non hanno accesso ai file di configurazione del sistema.

CHOKIDAR_USEPOLLING=1 npm start

— Manolo de la Vega
fonte

2

Ho risolto il mio problema uccidendo tutti i processi di controllo del tracker (potresti provare se usi GDM, ovviamente non il tuo caso se lo script è in esecuzione su un server)

tracker-control -r

La mia configurazione: Arch con GNOME 3

— Denys Vitali
fonte

1

Ho dimenticato di specificarlo, sì, ero nella stessa situazione: Arch + GNOME

— Denys Vitali

2

Se il tuo /tmpmount su un filesystem linux è montato come overflow (spesso dimensionato a 1 MB), ciò è probabilmente dovuto al fatto che non hai specificato /tmpcome partizione propria e il tuo filesystem di root è stato riempito ed è /tmpstato rimontato come fallback.

Per risolvere questo problema dopo aver liberato spazio, basta smontare il fallback e dovrebbe rimontarlo nel punto originale:

sudo umount overflow

— Pradeep Kumar
fonte

2

Se si verifica questo errore durante il tentativo di eseguire il ember servercomando, rm -rf tmpdirectory. Quindi corri di ember snuovo. Mi ha aiutato

— Daniel Kmak
fonte

2

Stavo avendo lo stesso errore. Mentre eseguo l'app Reactjs. Quello che faccio è semplicemente rimuovere la cartella node_modules e digitare e installare nuovamente node_modules. Questo rimuove l'errore.

— Ghayyas Mubashir
fonte

funziona davvero, perché è sottoposto a downgrade - è la domanda. Ma risolve il problema, quindi cosa ti serve altro?

— AlexNikonov,

1

Non lo so, forse i popoli hanno dei problemi personali con me. hahaha

— Ghayyas Mubashir,

1

Per me avevo raggiunto il numero massimo di file che un utente può possedere

Controlla i tuoi numeri con quota -se che il numero sotto i file non sia troppo vicino alla quota

— Neric
fonte

1

Sembra strano, ma sì, un riavvio del sistema o killall noderisolve il problema per me.

— Aram Paronikyan
fonte

-15

Nel mio caso, su Linux, il sudoing ha risolto il problema.

Esempio:

sudo gulp dev

— Sebastien Chartier
fonte

5

Questo è pericoloso! Probabilmente ha avuto successo perché una certa percentuale di spazio su disco è riservata a root, che non risolve il problema principale - nessuno spazio disponibile come utente non privilegiato (nella posizione di destinazione).

— Liam Dawson,

L'uso di sudo è un ottimo modo per far accadere le cose, ma molte persone trascurano di capire tutto ciò che accade quando si usa sudo. Soprattutto con i moduli npm e npm, l'uso di sudo può comportare l'esecuzione di root da parte dell'utente che l'utente non vorrebbe essere eseguito da root, come la creazione di file o l'uso di porte protette. Fondamentalmente, il consiglio "usa sudo" ricade sulla sua faccia (forse dopo aver inciampato e fissare il sole per un momento) per quanto riguarda nvm / npm / node.

— bschlueter,