Node.js: qu'est-ce qu'une erreur ENOSPC et comment résoudre?

J'ai un problème avec Node.js et le téléchargement de fichiers sur le serveur. Pour télécharger des fichiers sur le serveur, j'utilise ce plugin . Lors du démarrage du téléchargement de fichiers sur le serveur, le processus Node.js s'est bloqué et affiche une erreur:

Erreur: ENOSPC.

Le code du serveur ne s'exécute pas.

$ 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

Exécutez la commande ci-dessous pour éviter ENOSPC:

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

Pour Arch Linux, ajoutez cette ligne à /etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288

Exécutez ensuite:

sysctl --system

Cela persistera également lors des redémarrages. Détails techniques Source

ENOSPC signifie qu'il n'y a pas d'espace sur le lecteur.

Peut /tmp- être est plein? Vous pouvez configurer npmpour utiliser un dossier temporaire différent en définissant npm config set tmp /path/to/some/other/dir, ou peut-être tout supprimer du /tmpdossier.

Source: npm 1.1.21 ne peut pas écrire, ENOSPC dans le référentiel de npm dans github.

Remarque J'ai résolu mon problème de la manière décrite dans la source ci-dessus. Cependant, voir la réponse de Murali Krishna ci-dessous, qui est plus complète.

Je ne peux pas m'en attribuer le mérite, mais @grenade a souligné que npm dedupecela corrigera la cause (trop de fichiers) et non le symptôme.

Source: Grunt watch error - Waiting… Fatal error: watch ENOSPC .

Un moyen simple de résoudre mon problème était:

npm cache clear

npm ou un processus contrôlé par lui regarde trop de fichiers. La mise à jour de max_user_watches sur le noeud de build peut le réparer pour toujours. Pour debian, mettez ce qui suit sur le terminal:

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

Si vous voulez savoir comment augmenter le nombre d'observateurs inotify, cliquez uniquement sur le lien.

Le redémarrage de la machine a résolu le problème pour moi. J'ai d'abord essayé d'essuyer /tmp/mais le nœud se plaignait toujours.

Sous Linux, cela risque de limiter le nombre de surveillances de fichiers.

Le serveur de développement utilise inotify pour implémenter le rechargement à chaud. L'API inotify permet au serveur de développement de surveiller les fichiers et d'être averti lorsqu'ils changent.

La limite de surveillance des fichiers inotify par défaut varie d'une distribution à l'autre (8192 sur Fedora). Les besoins du serveur de développement dépassent souvent cette limite.

La meilleure approche consiste à essayer d'augmenter temporairement la limite de surveillance des fichiers, puis à en faire un changement de configuration permanent si vous en êtes satisfait. Notez, cependant, que cela modifie la configuration de l'ensemble de votre système, pas seulement le nœud.

Pour afficher votre limite actuelle:

sysctl fs.inotify.max_user_watches

Pour définir temporairement une nouvelle 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

Pour définir une limite permanente:

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

Sur Ubuntu 18.04, j'ai essayé une astuce que j'ai utilisée pour réactiver le fichier en regardant par ionic / node, et cela fonctionne également ici. Cela pourrait être utile pour ceux qui n'ont pas accès aux fichiers de configuration du système.

CHOKIDAR_USEPOLLING=1 npm start

J'ai résolu mon problème en tuant tous les processus de contrôle du tracker (vous pouvez essayer si vous utilisez GDM, évidemment pas votre cas si le script s'exécute sur un serveur)

tracker-control -r

Ma configuration: Arch avec GNOME 3

Si votre /tmpmontage sur un système de fichiers Linux est monté en débordement (souvent de 1 Mo), cela est probablement dû au fait que vous ne spécifiez pas /tmpcomme sa propre partition et que votre système de fichiers racine est rempli et a /tmpété remonté comme solution de secours.

Pour résoudre ce problème après avoir libéré de l'espace, démontez simplement la solution de secours et elle devrait remonter à son point d'origine:

sudo umount overflow

Si vous rencontrez cette erreur lors de la tentative d'exécution de la ember servercommande, veuillez rm -rf tmprépertoire. Ensuite, exécutez à ember snouveau. Ça m'a aidé.

J'avais la même erreur. Pendant que je lance l'application Reactjs. Ce que je fais, c'est simplement supprimer le dossier node_modules et taper et réinstaller node_modules. Cela supprime l'erreur.

Pour moi, j'avais atteint le nombre maximum de fichiers qu'un utilisateur peut posséder

Vérifiez vos numéros avec quota -set que le nombre sous fichiers n'est pas trop proche du quota

Cela semble très étrange, mais oui, un redémarrage du système ou killall noderésout le problème pour moi.

Dans mon cas, sur linux, sudoing a résolu le problème.

Exemple:

sudo gulp dev