Version des Knotens?

Können Sie auch ein einfaches Testfallskript bereitstellen, das Sie verwenden (zum Testen).

Verwenden Sie Knoten 0.10.21. Generiert bei jedem Skript einen Fehler.

Ist das das gleiche Problem wie #144? Ich kann dies nicht auf meinem Mac replizieren (obwohl ich nicht gefragt habe, welches Betriebssystem Sie haben, sondern basierend auf dem Pfad in Ihrer obigen Paste * nix-Typ angenommen habe).

Nicht das Gleiche, sind hier anders läuft ein einzelner Prozessor. In der anderen läuft auf mehreren Prozessoren, nicht in der Cloud

Habe diesen Fehler heute mit mehreren Apps erlebt (express, restify).

NodeJS: v0.10.21
ElementaryOS-Version: 0.2 "Luna" (64-Bit)
Aufgebaut auf: Ubuntu 12.04 ( "Präzise")
Kernel 3.5.0-43-generisch

11 Nov 17:32:38 - [nodemon] v0.7.10
11 Nov 17:32:38 - [nodemon] to restart at any time, enter `rs`
...
11 Nov 17:32:38 - [nodemon] exception in nodemon killing node
Error: watch ENOSPC
    at errnoException (fs.js:1019:11)
    at FSWatcher.start (fs.js:1051:11)
    at Object.fs.watch (fs.js:1076:11)
    at Object.watchFileChecker.check (/home/.../node_modules/nodemon/nodemon.js:160:6)
    at ready (/home/.../node_modules/nodemon/nodemon.js:49:22)
    at /home/.../node_modules/nodemon/nodemon.js:63:11
    at ChildProcess.exithandler (child_process.js:641:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)

reproduzieren:

npm install nodemon
./node_modules/.bin/nodemon app.js

app.js (von http://nodejs.org/)

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

Ich habe den gleichen Fehler mit CoffeeScript erhalten --watch ./node_modules/.bin/coffee --watch app/

/home/.../node_modules/coffee-script/lib/coffee-script/command.js:334
        throw e;
              ^
Error: watch ENOSPC
    at errnoException (fs.js:1019:11)
    at FSWatcher.start (fs.js:1051:11)
    at Object.fs.watch (fs.js:1076:11)
    at watchDir (/home/.../node_modules/coffee-script/lib/coffee-script/command.js:299:27)
    at /home/.../node_modules/coffee-script/lib/coffee-script/command.js:102:11
    at Object.oncomplete (fs.js:107:15)

Ich habe den gleichen Fehler bei einem Compound.js-Projekt mit Coffeescript unter Ubuntu 13.10 mit dem Knoten 0.10.21 erhalten

$ nodemon server.coffee

27 Nov 21:40:14 - [nodemon] v0.7.10
27 Nov 21:40:14 - [nodemon] to restart at any time, enter `rs`
27 Nov 21:40:14 - [nodemon] watching: /home/chok/work/edf/bluetic/src
27 Nov 21:40:14 - [nodemon] exception in nodemon killing node
Error: watch ENOSPC
    at errnoException (fs.js:1019:11)
    at FSWatcher.start (fs.js:1051:11)
    at Object.fs.watch (fs.js:1076:11)
    at Object.watchFileChecker.check (/usr/local/lib/node_modules/nodemon/nodemon.js:160:6)
    at ready (/usr/local/lib/node_modules/nodemon/nodemon.js:49:22)
    at /usr/local/lib/node_modules/nodemon/nodemon.js:63:11
    at ChildProcess.exithandler (child_process.js:641:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)

Kann das jemand mit der Dev-Version von Nodemon versuchen? Ich habe viele Änderungen vorgenommen und versuche, mich darauf zu konzentrieren, sicherzustellen, dass die neue Version all diese Probleme beseitigt.

Sie können mit npm install -g nodemon@dev installieren

Funktioniert bei mir jetzt keine Ahnung warum. Verwenden der neuesten stabilen Nodemon npm-Version. Hatte auch das gleiche Problem mit Coffeescript --watch und das funktioniert jetzt auch. Kein Node-Update, nur npm-Installationsmodule und Distributions-Updates.

Ich habe den gleichen Fehler, aber der Prozess stoppt:

$ nodemon server.coffee 
3 Dec 15:32:42 - [nodemon] v0.9.10
[nodemon] exception in nodemon killing node
[nodemon] Error: watch ENOSPC
    at errnoException (fs.js:1019:11)
    at FSWatcher.start (fs.js:1051:11)
    at Object.fs.watch (fs.js:1076:11)
    at Function.check (/usr/local/lib/node_modules/nodemon/lib/config/watchable.js:34:6)
    at alternativeCheck (/usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:18:15)
    at /usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:36:11
    at ChildProcess.exithandler (child_process.js:641:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)

@chok können Sie Folgendes für mich ausführen (und das Ergebnis einfügen) in das gleiche Verzeichnis, in dem Sie nodemon ausführen:

find . | wc

Ich versuche, eine Idee zu bekommen, was dieses Problem tatsächlich verursacht.

Hier ist das Ergebnis:

$ find . | wc
   7677    7677  542965

Okay, das sind 7600 Dateien, die auch Uhren zu binden versuchen.

Können Sie tree ausführen und das Ergebnis in http://pastie.org/ einfügen (nur weil es massiv sein wird).

Pastie sagte, es sei zu groß (mehr als 64kb) und schließlich mag ich den Text unten nicht :p (Alle deine Pasten gehören uns. ). Ich habe einige Teile entfernt, die für meine Projekte spezifisch sind. Übrigens befinden sich die meisten Dateien natürlich in node_modules.

Sie finden es auf gist: https://gist.github.com/chok/7774318

Okay, ich _glaube_, dass dies ein Problem ist, das ausschließlich mit der Anzahl der überwachten Dateien zusammenhängt (da Sie an jede einzelne Datei binden müssen). Ich habe darüber nachgedacht, node_modules und .git-Verzeichnisse standardmäßig zu ignorieren, aber können Sie es mit dem Befehl ignore versuchen (vorausgesetzt, Sie verwenden noch 0.9.x):

nodemon -i node_modules

Natürlich sollte dies nicht jedes Mal getan werden müssen, ich versuche nur zu bestätigen, dass dies das Problem ist.

Es geht nicht :(

$ nodemon -i node_modules/ server.coffee 
3 Dec 20:52:32 - [nodemon] v0.9.10
[nodemon] exception in nodemon killing node
[nodemon] Error: watch ENOSPC
    at errnoException (fs.js:1019:11)
    at FSWatcher.start (fs.js:1051:11)
    at Object.fs.watch (fs.js:1076:11)
    at Function.check (/usr/local/lib/node_modules/nodemon/lib/config/watchable.js:34:6)
    at alternativeCheck (/usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:18:15)
    at /usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:36:11
    at ChildProcess.exithandler (child_process.js:641:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)

Ich versuche auch:

$ nodemon -w app/* server.coffee 
3 Dec 20:53:32 - [nodemon] v0.9.10
[nodemon] exception in nodemon killing node
[nodemon] Error: watch ENOSPC
    at errnoException (fs.js:1019:11)
    at FSWatcher.start (fs.js:1051:11)
    at Object.fs.watch (fs.js:1076:11)
    at Function.check (/usr/local/lib/node_modules/nodemon/lib/config/watchable.js:34:6)
    at alternativeCheck (/usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:18:15)
    at /usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:36:11
    at ChildProcess.exithandler (child_process.js:641:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)

Können Sie genau den gleichen Befehl ausführen, aber --dump hinzufügen und mir die Antwort senden (wenn Sie die Ignorieren-Version ausführen).

Es gibt keinen Wechsel :

$ nodemon -i node_modules/ server.coffee  --dump
3 Dec 21:17:18 - [nodemon] v0.9.10
[nodemon] exception in nodemon killing node
[nodemon] Error: watch ENOSPC
    at errnoException (fs.js:1019:11)
    at FSWatcher.start (fs.js:1051:11)
    at Object.fs.watch (fs.js:1076:11)
    at Function.check (/usr/local/lib/node_modules/nodemon/lib/config/watchable.js:34:6)
    at alternativeCheck (/usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:18:15)
    at /usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:36:11
    at ChildProcess.exithandler (child_process.js:641:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)

Hmm, Entschuldigung, können Sie --dump vor Ihr Skript stecken, es sollte mir einen Dump der Konfiguration geben.

Ich habe beides schon probiert :(

$ nodemon -i node_modules/ --dump server.coffee 
3 Dec 21:25:35 - [nodemon] v0.9.10
[nodemon] exception in nodemon killing node
[nodemon] Error: watch ENOSPC
    at errnoException (fs.js:1019:11)
    at FSWatcher.start (fs.js:1051:11)
    at Object.fs.watch (fs.js:1076:11)
    at Function.check (/usr/local/lib/node_modules/nodemon/lib/config/watchable.js:34:6)
    at alternativeCheck (/usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:18:15)
    at /usr/local/lib/node_modules/nodemon/lib/config/checkWatchSupport.js:36:11
    at ChildProcess.exithandler (child_process.js:641:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)

Hi. Ich möchte nicht stumpf klingen, aber als ich auf diesen Fehler gestoßen bin, habe ich ihn behoben, indem ich max_user_watches auf meinem System erhöht habe. Ich habe diesen Thread beobachtet, um zu sehen, ob noch etwas passiert ist.

@taylorjbrennan ja, ich weiß, dass das das Problem beheben wird, aber während @chok konsistent replizieren kann, bin ich auf der Suche nach einer Änderung, die Nodemon behebt, ohne dass der Benutzer die max_user_watches io-Magie ausführen muss.

@remy super , ich freue mich darauf.

@chok kannst du es mit [email protected] noch einmal standardmäßig .git und node_modules/**/node_modules, daher sollte die Anzahl der Watches deutlich geringer sein (ich werde wieder öffnen, wenn dies immer noch ein Problem ist) .

Ich werde auch versuchen, den Fehler watch ENOSPC zu erkennen und eine Nachricht über die Erhöhung von max_user_watches . Nicht ideal, aber mehr kann ich nicht wirklich tun.

Ich habe diese Nachricht nicht mehr :) aber jetzt habe ich das Problem in #245 erklärt

Ich hatte gerade dieses Problem und es war ein Problem von zu vielen geöffneten Dateien auf dem System. (Sublime Text liebt es, viele Dateien zu öffnen, wenn Sie es zulassen)

Sobald ich in Sublime 2 ein Verzeichnis mit vielen Dateien öffne, funktioniert nodemon nicht mehr und spuckt den referenzierten Fehler aus. Ich konnte das nur umgehen, indem ich die Funktion "Ordner öffnen" von Sublimes nicht verwendet habe. Danke für den Hinweis @eyce9000.

@timtips dasselbe mit sublimetext3 und nodemon v1.3.1

@baio kannst du das überprüfen. Es gibt kein [email protected] - es gibt eine Vorabversion @1.3.0-1 - aber das ist in npm nicht in Produktion (können Sie auch Ihre npm-Version bestätigen)?

Er kann diesen Fehler schließen? Als neue Versionen von nodemon und nodejs wurde dieses Problem gelöst, obwohl ich nicht sagen konnte, dass es vollständig gelöst ist. Man kann sagen, dass es nicht mehr häufig vorkommt.

@alejonext kannst du es mit npm install -g nodemon@dev versuchen - ich habe einige Änderungen vorgenommen, die nicht in 1.2.1 enthalten sind.

Der Fehler bedeutet eigentlich "Error NO disk SPaCe" - aber ich denke, er hängt mit der Anzahl der überwachten Dateien zusammen, die durch Änderungen am Überwachungscode reduziert werden sollten ...

@remy Funktioniert perfekt :) danke für deine Arbeit!!!!

Süss. Es wird wahrscheinlich diese Woche eine stabile Version von 1.3.0 bis npm mit einer Reihe von Fehlerbehebungen geben.

@remy erstaunt über die Reaktionszeit. Vielen Dank!

@remy
Ausnahme in Nodemon Killing Node
Fehler: ENOSPC ansehen
bei errnoException (fs.js:1030:11)
bei FSWatcher.start (fs.js:1062:11)
bei Object.fs.watch (fs.js:1087:11)

Knoten v0.10.33
Betriebssystem: Linux Ubuntu

Ich habe dies mit diesem Befehl behoben https://github.com/ember-cli/ember-cli/issues/1240#issuecomment -47855317

aber ist die Aktualisierung des Pakets der empfohlene Weg?

Ich frage mich, warum es überhaupt so war. Ich verwende den Knotenversionsmanager mit
Knoten 0.12.0
npm 2.7.0
Glut 0.2.0

@ahnbizcad
Vielleicht wegen
https://github.com/joyent/node/wiki/API-changes-between-v0.10-and-v0.12#resource -management ?

Das System hat ein Limit für die Anzahl der Dateien, die von einem Benutzer angezeigt werden können. Wenn Sie Grunt mit anderen Programmen wie Dropbox laufen lassen, können Ihnen die Uhren ziemlich schnell ausgehen.

Der Beitrag schlägt vor, dies auszuführen, um die Anzahl der verfügbaren Uhren zu erhöhen.

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

Ich habe dieses Problem mit "nodemon": "^1.4.1" und "node": "0.12.7" :enttäuscht:

Bitte versuchen Sie es mit #625

Am Dienstag, 8. September 2015, 16:20 Uhr schrieb Wesley Queiroz [email protected] :

Ich habe dieses Problem mit "nodemon": "^1.4.1" und "node": "0.12.7" [Bild:
:enttäuscht:]

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/remy/nodemon/issues/214#issuecomment -138598438.

Habe es mit alpha versucht, bekomme aber immer noch ENOSPC ...
Mein sysctl.conf hat fs.inotify.max_user_watches=10000 .
Wenn ich es in 524288 ändere, funktioniert es, aber in meinem "Dev-Server" kann ich es nicht ändern.

Wie viele Dateien möchten Sie ansehen? dh wie viele sind unter deinem
Arbeitsverzeichnis?

Am Dienstag, den 8. September 2015 um 17:37 Uhr schrieb Wesley Queiroz [email protected] :

Habe es mit Alpha versucht, bekomme aber immer noch ENOSPC...
Meine sysctl.conf hat fs.inotify.max_user_watches=10000.
Wenn ich es auf 524288 ändere, funktioniert es, aber in meinem "dev-server" werde ich es nicht können
um es zu ändern.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/remy/nodemon/issues/214#issuecomment -138624285.

Nicht viele, 30 bei max.
Aber ich denke, Nodemon versucht, node_modules an der Wurzel des Projekts zu beobachten.
Unten ist die an nodemon übergebene Konfiguration (ich verwende sie als Knotenmodul):

nodemon({
    script: 'server/server.js',
    watch: [
        'server/',
        'common/'
    ],
    ext: 'js json coffee'
});

Der Serverordner hat:
7 Kaffeedateien
5 json-Dateien
und der gemeinsame Ordner hat nur 1 json-Datei ...

Ja... also laufe find . | wc -l und was gibt dir diese Zahl? Obwohl es standardmäßig node_modules ignorieren soll, ist es möglich, dass es nicht berücksichtigt wird.

Das Ausführen von find . | wc -l im Stammverzeichnis des Projekts gibt mir 18266 aber wenn ich node_modules und bower_components entferne, ergibt sich nur 320 .

Okay, ich denke also, dass die Uhr das node_modules _ist_ - das ist Teil des #625 Refactoring und muss repariert werden.

@wesleycoder können Sie mit dem neuesten nodemon@dev versuchen (es sollte Version 1.5.0-alpha4 ) und mit DEBUG=nodemon <your normal nodemon command> ausführen und dann die vollständige Ausgabe einfügen.

Whoa!
Es klappt!
Keine Fehler!
Vielen Dank!

Dies kann daran liegen, dass Ihr System keine Zugriffsberechtigung für Dateien hat. Sie können die folgende Befehlszeile in Ubuntu verwenden
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
oder Versuche
npm dedupe

Verweis auf

@ankibalyan @uttampanara

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

funktioniert bei mir auch!
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Hier gilt das gleiche ! :+1:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Führen Sie diesen Befehl aus

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

Eine andere mögliche Lösung besteht darin, eine nodemon.json Konfigurationsdatei in Ihrem Stammordner hinzuzufügen und zum Beispiel Ignoriermuster anzugeben:
nodemon.json

{
  "ignore": [
    "*.test.js", 
    "dist/*"
  ]
}

• Beachten Sie, dass standardmäßig .git , node_modules , bower_components , .nyc_output , coverage und .sass-cache ignoriert werden Sie müssen sie nicht zu Ihrer Konfiguration hinzufügen.

Der fs-Notify-Trick scheint bei einem Docker-Container nicht zu funktionieren ... zumindest nicht bei Alpine 3.8, erhalte ich den gleichen ENOSPC-Fehler. Es wird immer wichtiger, da Tools veraltet sind und wir weiterhin alte Produkte pflegen müssen