Node.js: co to jest błąd ENOSPC i jak go rozwiązać?

349

Mam problem z Node.js i przesyłaniem plików na serwer. Do przesyłania plików na serwer używam tej wtyczki . Podczas uruchamiania przesyłania pliku na serwer proces Node.js ulegał awarii i wyświetlał błąd:

Błąd: ENOSPC.

Kod serwera nie działa.

$ 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
źródło

1

„ENOSPC” oznacza, że na dysku nie ma miejsca, więc gdzie zapisujesz plik? a może / tmp jest pełny?

— Jacob A.,

Zapisuję pliki w / dev / xvda1. Czy mogę zrobić rm -rf / tmp / *?

— Giffo

1

tak, ale nie sądzę, że 1 MB wystarcza na ładowanie plików, więc zmień tmp-dir w inne miejsce, jak w odpowiedzi Blu Angel

— Jacob A.

3

Wygląda na to, że Twój przypadek użycia może być inny, ale oto świetne rozwiązanie tego problemu z innego pytania SO.

— Isaac Gregson

Dla każdego, kto natknie się na to, sprawdź również tę odpowiedź . Używanie chrząkania i przełykania może używać wielu zegarków, więc w tej odpowiedzi szczegółowo opisano, jak to zwiększyć.

— Seiyria

1273

Uruchom poniższe polecenie, aby uniknąć ENOSPC:

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

W przypadku Arch Linux dodaj tę linię do /etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288

Następnie wykonaj:

sysctl --system

Będzie to również obowiązywać podczas ponownego uruchamiania. Dane techniczne Źródło

— Murali Krishna
źródło

25

Oto co robi. github.com/guard/listen/wiki/…

— Agus Syahputra

2

To nie jest liczba losowa. Każdy używany zegarek inotify zajmuje 540 bajtów (system 32-bitowy) lub 1 kB (podwójnie - w wersji 64-bitowej). Wynika to z pamięci jądra, której nie można zamienić. Zakładając, że ustawiłeś maksimum na 524288 i wszystkie były używane (nieprawdopodobne), będziesz używał ok. 256 MB / 512 MB 32-bitowej / 64-bitowej pamięci jądra.

— Murali Krishna

Teoretycznie nie ma wartości maksymalnej, o ile masz wystarczającą ilość pamięci RAM. W praktyce 524288 jest oficjalnie zalecane przez aplikacje, a ludzie ustawiają go na 2 miliony, przy towarzyszącym użyciu pamięci.

— Murali Krishna

Pomogło mi to rozwiązać problem, również ten link github.com/guard/listen/wiki/… zawiera wszystkie szczegóły. Dzięki

— amitsin6h,

Czy ktoś inny uważa za dziwne, że błąd, który się pojawia, jest po prostu ENOSPC? Dlaczego nie ma opisu zaraz po wyjściu jak ENOSPC - no space on drive? Jasne, kod błędu ma sens, gdy wiesz, co to znaczy ( E rror NO SP a C e), ale dlaczego nie po prostu dać użytkownikom tych informacji z góry?

— Shadoninja

73

ENOSPC oznacza, że na dysku nie ma miejsca.

Być może /tmpjest pełny? Możesz skonfigurować npmużywanie innego folderu tymczasowego przez ustawienie npm config set tmp /path/to/some/other/dir, a może usunięcie wszystkiego z tego /tmpfolderu.

Źródło: npm 1.1.21 nie może pisać, ENOSPC w repozytorium npm w github.

Uwaga: Rozwiązałem swój problem w sposób opisany w powyższym źródle. Zobacz jednak odpowiedź Murali Kryszny poniżej, która jest bardziej wyczerpująca.

— Blu
źródło

Wyczyściłem folder / tmp i zmieniłem folder temp npm, ale mam ten sam problem. npm config get tmpshow / vol / deploy / tmp

— Giffo

czy możesz ponownie pokazać swoje wyjście? wyjście, które otrzymujesz Po zmianie reż

— Blu

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

— Giffo

1

masz detektor błędów? jeśli nie, to napisz jeden, a następnie sprawdź wynik

— Blu

72

źle, ten błąd występuje często w obszarach roboczych programistów podczas oglądania plików (przez chrząknięcie / gulp). Ma to związek z limitem uniksowym liczby plików, które proces może oglądać (zegarek natywny). Druga odpowiedź (echo fs.inotify.max_user_watches = 524288) jest rozwiązaniem w tych przypadkach.

— cancerbero

26

Nie mogę tego przypisać, ale @ granat wskazał, że npm dedupenaprawi przyczynę (zbyt wiele plików), a nie symptom.

Źródło: Błąd oglądania Grunt - Oczekiwanie… Błąd krytyczny: obejrzyj ENOSPC .

— orbiteleven
źródło

20

Prostym sposobem rozwiązania mojego problemu było:

npm cache clear

npm lub kontrolowany przez niego proces ogląda zbyt wiele plików. Aktualizacja max_user_watches w węźle kompilacji może to naprawić na zawsze. Dla debiana umieść na terminalu:

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

Jeśli chcesz wiedzieć, jak zwiększyć liczbę obserwatorów inotify, kliknij tylko link.

— Danrley Willyan
źródło

2

Mam problem z forever,.foreverignorenode_modules.

— naprawieniem

7

Ponowne uruchomienie maszyny rozwiązało problem. Najpierw próbowałem wycierać, /tmp/ale węzeł wciąż narzekał.

— Bjorn Reppen
źródło

Problem powrócił po ponownym uruchomieniu. Robienie dedupepomogło.

— Parnab Sanyal

4

W systemie Linux może to być ograniczenie liczby zegarków plików.

Serwer programistyczny używa inotify do wdrożenia ponownego ładowania na gorąco. Interfejs API inotify pozwala serwerowi programistycznemu oglądać pliki i otrzymywać powiadomienia o ich zmianie.

Domyślny limit obserwacji pliku inotify różni się w zależności od dystrybucji (8192 w Fedorze). Potrzeby serwera programistycznego często przekraczają ten limit.

Najlepszym rozwiązaniem jest tymczasowe zwiększenie limitu czasu oglądania pliku, a następnie wprowadzenie stałej zmiany konfiguracji, jeśli jesteś z niego zadowolony. Pamiętaj jednak, że zmienia to konfigurację całego systemu, a nie tylko węzła.

Aby wyświetlić aktualny limit:

sysctl fs.inotify.max_user_watches

Aby tymczasowo ustawić nowy limit:

# 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

Aby ustawić stały limit:

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

— Woodrow Barlow
źródło

3

Na Ubuntu 18.04 wypróbowałem sztuczkę, której użyłem, aby ponownie aktywować oglądanie pliku przez ionic / node, i działa również tutaj. Może to być przydatne dla tych, którzy nie mają dostępu do plików conf systemu.

CHOKIDAR_USEPOLLING=1 npm start

— Manolo de la Vega
źródło

2

Rozwiązałem problem polegający na zabiciu wszystkich procesów kontrolujących moduł śledzący (możesz spróbować, jeśli używasz GDM, oczywiście nie w przypadku, gdy skrypt działa na serwerze)

tracker-control -r

Moja konfiguracja: Arch z GNOME 3

— Denys Vitali
źródło

1

Zapomniałem podać, tak, byłem w tej samej sytuacji: Arch + GNOME

— Denys Vitali

2

Jeśli twoje /tmpmontowanie w systemie plików Linux jest montowane jako przepełnienie (często ma rozmiar 1 MB), jest to prawdopodobnie spowodowane tym, że nie określiłeś /tmpswojej własnej partycji, a główny system plików został zapełniony i /tmpzostał ponownie zamontowany jako rezerwowy.

Aby to naprawić po wyczyszczeniu miejsca, wystarczy odmontować awarię i powinno zostać ponownie zamontowane w pierwotnym punkcie:

sudo umount overflow

— Pradeep Kumar
źródło

2

Jeśli napotkasz ten błąd podczas próby uruchomienia ember serverpolecenia, prosimy o rm -rf tmpkatalog. Następnie uruchom ember sponownie. Pomogło mi to.

— Daniel Kmak
źródło

2

Miałem ten sam błąd. Podczas gdy uruchamiam aplikację Reactjs. To, co robię, to po prostu usuń folder node_modules i wpisz i zainstaluj ponownie node_modules. To usunie błąd.

— Ghayyas Mubashir
źródło

to naprawdę działa, dlaczego jest przegłosowane - to jest pytanie. Ale to rozwiązuje problem, więc czego potrzebujesz jeszcze?

— AlexNikonov

1

Nie wiem, ludzie mogą mieć ze mną osobisty problem. hahaha

— Ghayyas Mubashir

1

Dla mnie osiągnąłem maksymalną liczbę plików, które użytkownik może posiadać

Sprawdź swoje liczby za pomocą quota -si czy liczba w plikach nie jest zbyt blisko limitu

— nerwowy
źródło

1

Brzmi to bardzo dziwnie, ale tak, system ponownie się uruchamia lub killall noderozwiązuje problem.

— Aram Paronikyan
źródło

-15

W moim przypadku na Linuksie sudoing naprawił problem.

Przykład:

sudo gulp dev

— Sebastien Chartier
źródło

5

To jest niebezpieczne! Prawdopodobnie się udało, ponieważ pewien procent miejsca na dysku jest zarezerwowany dla użytkownika root, co nie rozwiązuje podstawowego problemu - brak miejsca jako użytkownik nieuprzywilejowany (w lokalizacji docelowej).

— Liam Dawson,

Korzystanie z sudo to świetny sposób, aby coś się stało, ale większość ludzi nie rozumie wszystkiego, co się dzieje, gdy używa się sudo. W szczególności w przypadku modułów npm i npm korzystanie z sudo może powodować wykonywanie przez roota rzeczy, których użytkownik nie chce, aby był wykonywany przez root, takich jak tworzenie plików lub korzystanie z chronionych portów. Zasadniczo rada „użyj sudo” pada płasko na twarz (być może po potknięciu się i wpatrzeniu w słońce przez chwilę), gdy chodzi o nvm / npm / node.

— bschlueter