Nodemon: Nodemon lässt den untergeordneten Prozess häufig laufen (getrennt)

Seltsamerweise habe ich hier das gleiche Problem. Ich habe dies vorher nicht erlebt, und ich bin mir nicht sicher, was ich aktualisiert habe, um dieses Problem zu haben.

OS X El Capitan
Knoten v6.9.1
Nodemon v1.11.0

Auch hier erhalte ich einen EADDRINUSE-Fehler in meinem Express-Server

OS X Sierra
Knoten v6.10.3
Nodemon v1.11.0

31960 ttys005    0:00.41 node /Users/harman.goei/.nvm/versions/node/v7.10.0/bin/nodemon -e ts --verbose --exec ts-node  lib/server.ts
31962 ttys005    0:00.10 node /Users/harman.goei/.nvm/versions/node/v7.10.0/bin/ts-node lib/server.ts
31963 ttys005    0:01.10 /Users/harman.goei/.nvm/versions/node/v7.10.0/bin/node /Users/harman.goei/.nvm/versions/node/v7.10.0/lib/node_modules/ts-node/d
ist/_bin.js lib/server.ts

nodemon erzeugt 31962, aber 31963 bleibt immer noch stehen (ich denke, 31963 ist ein untergeordneter Prozess von 31962). Dies verursacht dann beim Neustart ein Problem, da der Server bei 31963 noch läuft.

Aktualisieren:
Bei der Suche sieht es so aus, als ob SIGUSR2 nicht gut genug ist, um den untergeordneten Prozess zu beenden. SIGHUP war erforderlich.

Ich habe das gleiche Problem. Hat schon jemand eine Lösung gefunden?

Ich hatte das gleiche Problem und es schien aus dem Nichts aufzutauchen. Ich begann, dies am Ende meiner js-Eintragsdatei hinzuzufügen, sodass es die letzten ausgeführten Zeilen meines Skripts waren, und es schien das Problem für mich zu klären. Ich hoffe es hilft!

Ich beende meinen Nodemon-Prozess in iTerm mit STRG+C und auf einem Mac mit OSX Sierra 10.12.5.

process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); });

Das gleiche Problem, es ist in Ordnung, wenn ich STRG + C ausschließe und npm start erneut starte.

$ npm start

> [email protected] start ter
> npm run build:live


> [email protected] build:live ter
> nodemon --exec ./node_modules/.bin/ts-node -- ./index.ts

[nodemon] 1.11.0
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`
NodeJS server started...
[nodemon] restarting due to changes...
[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`
[nodemon] restarting due to changes...
[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`
NodeJS server started...
NodeJS server started...
Error: listen EADDRINUSE :::3000
    at Object.exports._errnoException (util.js:1016:11)
    at exports._exceptionWithHostPort (util.js:1039:20)
    at Server.setupListenHandle [as _listen2] (net.js:1307:14)
    at listenInCluster (net.js:1355:12)
    at Server.listen (net.js:1455:7)
    at Application.listen (/ter/node_modules/koa/lib/application.js:64:19)
    at Object.<anonymous> (/er/index.ts:9:5)
    at Module._compile (module.js:569:30)
    at Module.m._compile (ter/node_modules/ts-node/src/index.ts:379:23)
    at Module._extensions..js (module.js:580:10)
[nodemon] app crashed - waiting for file changes before starting...
^C
$ npm start

> [email protected] start ter
> npm run build:live


> [email protected] build:live ter
> nodemon --exec ./node_modules/.bin/ts-node -- ./index.ts

[nodemon] 1.11.0
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`
NodeJS server started...

Gleiches Problem, wie kann man es lösen?

[[16:13:36] [nodemon] restarting due to changes...
[16:13:36] [nodemon] starting `node test/phantomFlow/test/test.js --delay 2.5 --ignore test/`
Parallelising 1 test files on 1 processes.

Picking up job: flows\carepilotweb.test.js
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE :::9001
    at Object.exports._errnoException (util.js:1026:11)
    at exports._exceptionWithHostPort (util.js:1049:20)
    at Server._listen2 (net.js:1257:14)
    at listen (net.js:1293:10)
    at Server.listen (net.js:1389:5)
    at Function.app.listen (C:\workspace\deleteme_0420\carepilot-web\test\phantomFlow\node_modules\connect\lib\proto.js:232:24)
    at Object.<anonymous> (C:\workspace\deleteme_0420\carepilot-web\test\phantomFlow\test\test.js:46:4)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
[16:13:36] [nodemon] app crashed - waiting for file changes before starting...
](url)

Bearbeiten:
Wenn ich die gulp-Datei so bearbeite, funktioniert es

gulp.task('report-debug', /*['clean-build-app-dev', 'validate-devserver-scripts'],*/ function(){
    // start nodemon to load test.js
    plugins.nodemon({ script: 'server/server.js', ext: 'js', watch: ['server/'], args:['--ignore', 'test/'], env: { NODE_ENV: 'development' } })
        .on('start', function () {
            plugins.nodemon({ script: 'test/phantomFlow/test/test.js', watch: ['server/'], args:['debug', '--ignore', 'test/'], stdout: false })
            .on('readable', function() {
                this.stdout.on('data', function(chunk) {
                    if (/Completed /.test(chunk)) {
                        const { exec } = require('child_process');
                        exec('node test/phantomFlow/test/test.js report', ['--ignore', 'test/']);
                    }
                    process.stdout.write(chunk);
                });
                this.stderr.pipe(process.stderr);
            });
        });
});

Habe hier genau das gleiche Problem.

Tut mir leid, das einzige, was ich nach mehreren Tests gefunden habe, ist eine saubere OS-Installation, die dies für mich unter Linux behoben hat. Natürlich werde ich nicht jedes Mal eine Neuinstallation durchführen, ich habe nur herumgespielt.

Das gleiche hier auf OSX. Alle Knotenprozesse am Laufen halten (1.12.0)

Irgendeine Lösung für dieses Problem?

Nein, das Problem hatte ich noch nicht. Ich weiß nicht, was dazu führt, dass Nodemon den Prozess verliert.

Irgendwelche Lösungen?

Ich habe dieses Problem auch unter Ubuntu 16.04, Nodemon 1.12.1 und Node v8. Habe keine Lösung gefunden, außer den Prozess manuell zu beenden.

Um weiter zu erläutern, was ich in meinem vorherigen Kommentar getan habe - das Signal ( SIGUSR2 ), das an mein Programm gesendet wurde, führte nicht dazu, dass es beendet wurde. Ich musste das Signal stattdessen auf SIGHUP ändern.

Ich habe eine Datei namens nodemon.json :

{
  "signal": "SIGHUP",
  "env": {
    "NODE_ENV": "development"
  },
  "ext": "ts",
  "exec": "ts-node --inspect ./lib/server.ts"
}

und in meiner package.json, da ich npm-Skripte verwende, sollte das Ausführen von nodemon ausreichen:

"dev": "nodemon",

Das Problem liegt bei ts-node selbst: https://github.com/TypeStrong/ts-node/pull/458

Um Ihre App/Ihr Programm unter Windows von diesem Fehler zu befreien, müssen Sie den PID-Prozess an Port 3000 beenden.

Das eigentliche Problem dabei ist, dass nodemon child_process.spawn anstelle von child_process.fork , um untergeordnete Prozesse zu erstellen . In diesem Fall tötet das Töten des Elternteils nicht seine Kinder.

Die Lösung hierfür besteht darin, nodemon zu ändern, dass child_process.fork beim Erstellen von untergeordneten Knotenprozessen (und child_process.spawn für Nicht-Knoten-Ausführungsdateien) verwendet wird, damit die Garbage Collection des Knotens ordnungsgemäß (und automatisch) wird kann wirksam werden, wenn der Elternteil stirbt.

Die Verwendung von child_process.fork bietet auch den zusätzlichen Vorteil der Verwendung der IPC-Kanäle für die Kommunikation zwischen übergeordneten und untergeordneten Knotenprozessen, sodass die Methoden process.send und process.on für die Kommunikation zwischen Prozessen verwendet werden können .

Ich habe hier eine einfache PR erstellt, die das Problem anspricht (aber noch keine CI-Tests besteht): https://github.com/remy/nodemon/pull/1134

Hoffentlich kann der Betreuer den Code weiter ausarbeiten, oder wenn ich in Zukunft Zeit finde, um zu helfen, werde ich es tun.

Eine vorübergehende Lösung, die angewendet werden kann, um dies zu beheben, ist:

// NOTE: this ONLY works when using nodemon as a `require` module.
// I don't have a solution for booting nodemon from the CLI. Sorry!

var nodemon = require('nodemon');

process

  // Handle normal exits
  .on('exit', (code) => {
    nodemon.emit('quit');
    process.exit(code);
  })

  // Handle CTRL+C
  .on('SIGINT', () => {
    nodemon.emit('quit');
    process.exit(0);
  });

tl;dr child_process.fork ist die sauberste Lösung, da es untergeordnete Prozesse automatisch bereinigt, wenn der übergeordnete Prozess stirbt. nodemon muss so bearbeitet werden, dass fork statt spawn (nur für ausführbare node ).

Ich erinnere mich, dass ich das ganze Reifenspringen durchgegangen bin, um herauszufinden, welche Methode die richtige ist. IIRC spawn ist die Methode, die ich verwenden muss, um einen Link zu pflegen, der mir von Spawn gegeben wurde, aber fork (et al.) nicht.

Fühlen Sie sich frei, eine PR zu senden, die alle Tests besteht, wenn Sie der Meinung sind, dass dies jedoch funktioniert.

Ah, Entschuldigung, ich habe die PR verpasst, aber ja, es schlägt fehl und ich vermute, es liegt daran, dass Sie sich verzweigen.

Nun ja, wie gesagt, und wie es in der node Dokumentation heißt, ist fork speziell für die Verwendung mit Knotenprozessen gedacht, die untergeordnete Knotenprozesse hervorbringen, während spawn für alle anderen Nicht-Knoten-Prozesse.

Die Methode child_process.fork() ist ein Sonderfall von child_process.spawn(), die speziell zum Generieren neuer Node.js-Prozesse verwendet wird. Wie child_process.spawn() wird ein ChildProcess-Objekt zurückgegeben. Der zurückgegebene ChildProcess verfügt über einen integrierten zusätzlichen Kommunikationskanal, der es ermöglicht, Nachrichten zwischen dem Elternteil und dem Kind hin und her zu übergeben. Weitere Informationen finden Sie unter subprocess.send().
https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

Ich werde sehen, ob ich mit der PR fortfahren kann, aber es kann nicht eine Weile dauern. Das .apply Sie verwenden, um spawn anzurufen, verwende ich nicht regelmäßig, und wir müssen einen Weg finden, mit stdin/out/err umzugehen, was mit silent: true als Option beim Gabeln.

Überprüfen Ihre Tests auf eine untergeordnete PID oder auf stdin/out oder ..?

Wenn Sie davon überzeugt sind, dass spawn die einzige Antwort für Ihr Repo ist, würde ich vorschlagen, zu versuchen, die PID des hervorgebrachten Kindes zu speichern und dieses .on('exit') , .on('SIGINT') töten. usw... obwohl ich immer noch denke, dass es mit fork viel einfacher sein wird.

Gleiche Frage hier, ich denke , es begann vor ein paar Tagen , als ich von NodeJS ging 6.4.0 zu NodeJS 8.90

Es passiert, wenn ich nodemon mit STRG+C anhalte und es dann erneut starten muss.

Jetzt muss ich den Node-Prozess jedes Mal manuell über den Task-Manager herunterfahren [Windows 10]

Gleiches Problem hier.

$ node -v
v8.9.2

$ nodemon -v
1.12.5

Die Arbeit von @heisian hier wurde zusammengeführt und sollte dieses Problem für Sie alle lösen. 👏 Lebe derzeit in [email protected]

suh süss! froh geholfen zu haben.

@heisian ein paar Bits werden hier und da abgespritzt, aber ich habe jetzt eine Änderung vor sich, die das

hmm, vielleicht war mir damals unklar, wie für den untergeordneten Knotenprozess bestimmte Argumente innerhalb von run.js referenziert werden?

Ich hatte vor, alle Argumente, die an den Knoten übergeben werden mussten, um in die Variable forkArgs :

child = fork(options.execOptions.script, forkArgs, {
...
});

Zum Beispiel fork ich einen Prozess zum Transpilieren von Code:

child_process.fork('./', [
      '--out-dir', './dist',
      '--ignore', './coverage,./dist,./docs,./embed,node_modules,shared/cli,' +
      'shared/docker,bin/tools,admin/src,main/src,partner/src,*.swp,*.swo,' +
      'admin/build,main/build,partner/build,**/tests,shared/webpack,./stories',
      '--copy-files',
      // Presets/Plugins are defined in <project_root>/.babelrc
    ], {
      execPath: './node_modules/.bin/babel',
    });

All das sollte das Äquivalent von sein:

 ./node_modules/.bin/babel --out-dir ./dist --ignore ./coverage,./dist,./docs,./embed,node_modules,shared/cli,shared/docker,bin/tools,admin/src,main/src,partner/src,*.swp,*.swo,admin/build,main/build,partner/build,**/tests,shared/webpack,./stories --copy-files

Ja, ich habe das in einem lokalen Test versucht, es gibt das .splice(1) das tatsächlich das --inspect wenn es in den CLI-Argumenten ist, aber es funktioniert auch einfach nicht. Ich _glaube_, dass es den Hauptknotenprozess (der derzeit nodemon.js ausführt) abzweigt, bei dem der Debugger nicht geöffnet ist.

Ich habe vorerst eine Lösung gehackt (siehe die Kommentare in Ihrer PR), und sie behebt die neuesten Probleme, aber ich bin mir nicht 100% sicher, ob sie kugelsicher ist.

hmm okay, ich werde es überprüfen und sehen, ob es eine bessere Lösung gibt. Ja, ich denke, das ist der Fall, --inspect muss im Elternprozess markiert werden, der an das Kind weitergegeben wird.

Aktualisiert von 1.12.1 auf 1.12.7 und wird immer noch

Port xxxx is already in use
[nodemon] app crashed - waiting for file changes before starting...

wenn ich Nodemon nach dem Beenden neu starte (STRG+C).

(Windows 10) & extra :heart: an @remy !

Können Sie ein anderes Thema und genaue Einzelheiten darüber , wie laufen Sie in Windows (git bash, etc.) Datei

@remy sicher, #1164

Betreibe keinen Express-Server, aber einen nodejs-Net-Socket und habe das gleiche Problem mit nodemon -v: 1.14.2
Knoten -v: 9,4
ubuntu/xenial

Vielleicht haben die oben genannten Pr's dies nicht gelöst?

Wenn Nodemon nicht abstürzt, wird es bei Änderungen gut neu gestartet, aber wenn Nodemon abstürzt oder ich es beenden muss, lässt es den Socket laufen und ich muss pkill node bevor Nodemon erneut ausgeführt wird, sonst bekomme ich den Port in Gebrauch Error.

Hinweis: In meinem Modul, das den Net-Socket startet, habe ich Kill-Code eingebaut, so dass, wenn der Prozess abrupt beendet wird, wie bei cntrl-c(SIGUP), der Socket heruntergefahren wird. Zu Ihrer Information, ich benutze das On-Death-Modul.

nicht mit babel, aber mit @std/esm wie in nodemon --require @std/esm

Ich würde versuchen, zuerst zu bestätigen, dass Ihre untergeordneten Prozesse tatsächlich gegabelt und nicht erzeugt werden. Wenn Sie dies von Ihrem untergeordneten Prozess aus tun können:

process.send('some message')
// Should not throw an error

...und in Ihrem Elternteil können Sie erfolgreich die Nachricht empfangen:

process.on('message', function(message) {
  process.stdout.write(message)
})
// Should output 'some message'

...dann wurde Ihr Prozess tatsächlich mit child_process.fork gegabelt und sollte ordnungsgemäß beendet werden, wenn das übergeordnete Element beendet wird. Wenn das oben genannte nicht funktioniert, dann war Ihr untergeordneter Prozess spawned und Sie müssen daher selbst herausfinden, wie Sie mit der Prozessbeendigung umgehen können - entweder bis SIGKILL process.on('exit') oder eine Kombination aus beidem.

Ich erlebe dies auch bei einer der neuesten Versionen von nodemon: 1.17.3

Auch dies mit Nodemon 1.17.3, Node 9.2.0, auf macOS High Sierra v10.13.4, @johnnydimas One-Liner-Lösung oben hat es bisher für mich behoben.

Ich bekomme das auch unter Ubuntu 18.04 und 17.10.

Habe das auch! alle Pakete aktuell.
auf macOS High Sierra v10.13.2

@lukebrewerton @MissAnichka @danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
Ich habe es geschafft, dieses Problem zu beheben.
Es ist eigentlich kein Nodemon, sondern Babel-Node!
npm i kexec -D wird das Problem lösen

Erläuterung:
https://github.com/babel/babel/issues/1062#issuecomment -84526036

Bearbeiten:
Wurde ein wenig begeistert und berücksichtigte andere Anwendungsfälle nicht.
ABER falls Sie babel-node verwenden, sollte dies das Problem jedoch beheben =D

Ich verwende kein Babel, sondern nur den alten Knoten js

Bekomme dies immer noch auf Nodemon 1.17.5 mit Node 9.5.

Leider auch mit node -r ts-node/register index.ts

@Kamshak bitte öffne eine neue Ausgabe und füge deine index.ts ein, die auf ein replizierbares Beispiel reduziert sind

Ich habe dieses Problem immer noch mit Nodemon 1.18.3 und Node 8.11.4 unter macOS 10.13.3.

Gleiches Problem... Nodemon 1.18.3 und Node 8.11.4 auf Ubuntu 18.04 LTS. Habe auch die Nodemon-Konfigurationsroute ausprobiert, indem SIGHUP explizit verwendet wurde, um den Prozess zu beenden und eine zusätzliche Verzögerung von 2500 ms hinzuzufügen ..... Leider keine Freude ....

Wenn Sie Nodemon über das WebStorm-Terminal-Panel starten und EADDRINUSE nach dem Neustart der IDE haben (oder vielleicht nur das Terminal-Panel erneut öffnen), überprüfen Sie, ob in der Prozessliste ein verirrter Nodemon-Prozess übrig ist. Ist mir unter Ubuntu 18.04 passiert.

Danke für den Hinweis @dchekanov . Ich hatte das gleiche Problem mit vscode. Ich würde den EADDRINUSE-Fehler jedes zweite Mal zuverlässig erhalten, wenn Nodemon versuchte, neu zu starten. Es wäre sinnvoll, wenn dies eine Art Race Condition zwischen zwei Nodemon-Prozessen wäre.

Ich habe das gleiche Problem.
Nodemon -v 1.18.4
Knoten -v v8.11.1
macOS Mojave-Version 10.14
VsCode-Terminal

Ich habe das gleiche Problem. Sie können dieses Repo klonen: https://github.com/aecorredor/express-graphql-postgres-starter und yarn und dann yarn start ausführen, eine Änderung vornehmen, speichern und den Fehler sehen . Beachten Sie, dass ich nicht gleichzeitig verwende. Ich laufe gerade nodemon --exec babel-node index.js

Gleicher Fehler. 1.18.6.
Ausführung in Docker unter Ubuntu, Knoten 10.11

Gleiches Problem hier!

Es hat mir geholfen
yarn add --dev kexec

Ich habe vor kurzem auch das gleiche Problem....
Vielleicht wegen des Docker-Upgrades ... ich weiß nicht warum ...
EADDRINUSE...

Hallo @justintien ,

Ich hatte dieses Problem mehrmals mit Nodemon, das ich immer noch für das pm2-Paket (http://pm2.keymetrics.io/) geändert habe, eines, das ich in der Produktion verwende.

Einfach hinzufügen und starten mit: pm2 start src/server.ts --watch --no-daemon
Wenn Sie ES6-Skripte haben, müssen Sie das Typescript-Modul vorinstallieren und können dies in postintall hinzufügen mit:
"postinstall": "$(Garn Bin)/pm2 install typescript"

Ich hoffe das hilft.

Die einzige Möglichkeit, die für mich funktionierte, war "signal": "SIGTERM", in nodemon.json hinzuzufügen.

Ich verwende Yarn, Docker und von Alpine 10.

@lukebrewerton @MissAnichka @danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
Ich habe es geschafft, dieses Problem zu beheben.
Es ist eigentlich kein Nodemon, sondern Babel-Node!
npm i kexec -D wird das Problem lösen

Erläuterung:
babel/babel#1062 (Kommentar)

Bearbeiten:
Wurde ein wenig begeistert und berücksichtigte andere Anwendungsfälle nicht.
ABER falls Sie babel-node verwenden, sollte dies das Problem jedoch beheben =D

Ich habe immer noch das gleiche Problem mit allen Paketen, die auf die neueste Version aktualisiert wurden. Aber durch die Installation von kexec funktioniert es irgendwie. Aber ich bin mir nicht ganz sicher, weil das Paket kexec anscheinend nicht aktiv gepflegt wird.

npmi kexex hat bei mir nicht funktioniert, mit 1.18.6

Leute, dies ist ein geschlossenes und nicht unterstütztes Problem. Wenn Sie im neuesten Nodemon einen Fehler sehen, melden Sie bitte ein neues Problem mit vollständigen Anweisungen zur Replikation.

Beachten Sie, dass ich dies bereits zuvor zum gleichen Thema gesagt habe.

Ansonsten beachten Sie bitte, dass ich keine geschlossenen Issues überwache.

Ich hatte das gleiche Problem und werde es los, indem ich die Version 1.12.6 mit dem folgenden Befehl installiere: yarn global add nodemon@next und dann wählst du in der Liste die Version 1.12.6 aus oder du kannst einfach yarn global add [email protected] ausführen @remy für die Lösung: https://github.com/remy/nodemon/issues/1025#issuecomment -351394591

Docker: Knoten: 10-Alpin
Knoten: v10.6.0
Nodemon: v1.18.7

Grund habe ich gefunden:

PID   USER     TIME   COMMAND
    1 root       0:00 /bin/sh -c npm i npm run dev -- -L
   16 root       0:00 sh
   22 root       0:00 npm
   32 root       0:00 sh -c nodemon ./src --exec babel-node "-L"
   33 root       0:01 node /app/node_modules/.bin/nodemon ./src --exec babel-node -L
   46 root       0:00 sh -c babel-node ./src
   47 root       0:00 node /app/node_modules/.bin/babel-node ./src
   53 root       0:00 /usr/local/bin/node /app/node_modules/babel-cli/lib/_babel-node ./src

# if watch change, restarting due to changes...
# after: it's didn't kill sub child -> 47 & 53
    1 root       0:00 /bin/sh -c npm i npm run dev -- -L
   16 root       0:00 sh
   22 root       0:00 npm
   32 root       0:00 sh -c nodemon ./src --exec babel-node "-L"
   33 root       0:15 node /app/node_modules/.bin/nodemon ./src --exec babel-node -L
   47 root       0:00 node /app/node_modules/.bin/babel-node ./src
   53 root       0:09 /usr/local/bin/node /app/node_modules/babel-cli/lib/_babel-node ./src
   78 root       0:00 sh -c babel-node ./src
   79 root       0:00 node /app/node_modules/.bin/babel-node ./src
   85 root       0:01 /usr/local/bin/node /app/node_modules/babel-cli/lib/_babel-node ./src

Ich versuche schon:

• "signal": "SIGTERM", in nodemon.json.
• npm i -D kexc (ich weiß, dass babel-node zuerst kexec verwendet, aber es ist ein Wurffehler)

app_1    | /app/node_modules/babel-cli/lib/babel-node.js:70
app_1    |     if (err.code !== "MODULE_NOT_FOUND") throw err;
app_1    |                                          ^
app_1    |
app_1    | Error: Error loading shared library /app/node_modules/kexec/build/Release/kexec.node: Exec format error
app_1    |     at Object.Module._extensions..node (internal/modules/cjs/loader.js:718:18)
app_1    |     at Module.load (internal/modules/cjs/loader.js:599:32)
app_1    |     at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
app_1    |     at Function.Module._load (internal/modules/cjs/loader.js:530:3)
app_1    |     at Module.require (internal/modules/cjs/loader.js:637:17)
app_1    |     at require (internal/modules/cjs/helpers.js:20:18)
app_1    |     at Object.<anonymous> (/app/node_modules/kexec/index.js:1:80)
app_1    |     at Module._compile (internal/modules/cjs/loader.js:689:30)
app_1    |     at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
app_1    |     at Module.load (internal/modules/cjs/loader.js:599:32)

@mohamed-badaoui
In der Produktion habe ich Nodemon nicht verwendet, sondern nur für Entwickler...
Ich verwende Docker in der Produktion. :erröten:

Hatte das Problem mit [email protected] ,
musste also Nodemone auf 1.18.8 aktualisieren, funktioniert jetzt

Verwenden Sie TS- und Apollo-Server.

Um zu bestätigen , was

Nachrichten!

Ich aktualisiere auf 1.18.9, es funktioniert einwandfrei!!

groß!!

@mohamed-badaoui

danke kumpel! danke für die Rückmeldung

Um weiter zu erläutern, was ich in meinem vorherigen Kommentar getan habe - das Signal ( SIGUSR2 ), das an mein Programm gesendet wurde, führte nicht dazu, dass es beendet wurde. Ich musste das Signal stattdessen auf SIGHUP ändern.

Ich habe eine Datei namens nodemon.json :

{
  "signal": "SIGHUP",
  "env": {
    "NODE_ENV": "development"
  },
  "ext": "ts",
  "exec": "ts-node --inspect ./lib/server.ts"
}

und in meiner package.json, da ich npm-Skripte verwende, sollte das Ausführen von nodemon ausreichen:

"dev": "nodemon",

Als Workaround hat das Hinzufügen von "signal": "SIGHUP" für mich funktioniert.

@Mutmatt nodemon v1.18.10 sagt mir "Unbekannte oder unerwartete Option: --inspect".

@bennyn Sie können einen beliebigen Befehl vom Typ package.json hinzufügen.

ZB nodemon.json

{
  "signal": "SIGHUP",
  "ext": "ts",
  "exec": "npm run serve",
  "watch": ["src"]
}

Aha! Es ist also ein Flag, das in ts-node . Es tut mir leid. 🙈

Gleiches Problem hier
Error: listen EADDRINUSE
nodemon: 1.18.11
node: 10.14.1

bei mir funktioniert alles nicht :(
mit ts-node + nodemon

Ich habe Visual Studio Terminal, Ubuntu 18, verwendet. Eine Möglichkeit bestand darin, das Terminal zu beenden, den Prozess zu finden und zu beenden
Neues Terminal außerhalb des Visual Studios starten
also das hat bei mir geklappt

Hoch

Überprüfen Sie, ob Sie nodemon global installiert haben. Das Entfernen hat das Problem bei mir behoben.

Ich habe die dotenv-Bibliothek für Umgebungsvariablen verwendet und bin auf das gleiche Problem gestoßen. Für mich war es die '.env'-Datei.

Es war wie:
PORT=3000,

Vergessen Sie nicht, Kommas zu entfernen, wenn Sie aus json kopieren.

das hat das problem bei mir gelöst
npm cache clean -force

Die Option "autoAttachChildProcesses": true für mich gelöst

Die Option "autoAttachChildProcesses": wahr für mich gelöst

Haben Sie es in nodemon.json konfiguriert oder wo sollte diese Option platziert werden?

Ich habe gerade das gleiche Problem. Es wurde versucht, die Ereignisschleife zu debuggen, wenn noch etwas übrig ist, aber es scheint nein zu sein.

"nodemon": "^1.19.1",
node: v10.16.2
npm: 6.9.0

Hat jemand die richtige, saubere Lösung dafür gefunden?

Unter Windows stoppen Sie die Prozesse "node.exe Node.js: Server-side JavaScript".

Fügen Sie am Ende Ihrer js-Datei hinzu, wo Sie den Server starten:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

Gern geschehen!

Nur zu Ihrer Information, wenn Sie immer noch Probleme haben, versuchen Sie es auch:
Ich benutze Garn und ein einfaches yarn cache clean hat die Magie für mich getan.
Für npm-Benutzer versuchen Sie npm cache clean .

Es gibt also keine Möglichkeit, Nodemon zu töten, wenn es ausgeführt wird ???

Gerade auf den neuesten Nodemon aktualisiert und zusammen mit dem NPM-Upgrade von Node 6 auf 10 gestoßen und dabei auf Folgendes gestoßen:
"nodemon": "^1.19.2",
Knoten: 10.16.0
npm: 6.9.0

@doc82 Dieses spezielle Problem ist extrem kompliziert und selten jedes Mal dasselbe.

Sie sollten ein neues Problem mit vollständigen Details zur Replikation ansprechen, da in 9 von 10 Fällen die Art und Weise, wie Nodemon in Ihrem Projekt ausgeführt wird, den "hängenden Unterprozess" verursacht.

Ich hatte einen Fehler mit folgendem:-

[nodemon] wird aufgrund von Änderungen neu gestartet...
[nodemon] ab node server.js
events.js:183
werfen ähm; // Unbehandeltes 'Fehler'-Ereignis
^

Fehler: EADDRINUSE hören :::3000
at Object._errnoException (util.js:1022:11)
at _ExceptionWithHostPort (util.js:1044:20)
at Server.setupListenHandle [as _listen2] (net.js:1367:14)
bei listenInCluster (net.js:1408:12)
bei Server.listen (net.js:1492:7)
bei Objekt.(/home/dg/junesis/server.js:8:8)
bei Module._compile (module.js:652:30)
bei Object.Module._extensions..js (module.js:663:10)
bei Module.load (module.js:565:32)
bei tryModuleLoad (module.js:505:12)
bei Function.Module._load (module.js:497:3)
bei Function.Module.runMain (module.js:693:10)
beim Start (bootstrap_node.js:188:16)
bei bootstrap_node.js:609:3
[nodemon] App abgestürzt - Warten auf Dateiänderungen vor dem Start...
[nodemon] wird aufgrund von Änderungen neu gestartet...
[nodemon] ab node server.js
Abhören auf Port 3000...
[nodemon] wird aufgrund von Änderungen neu gestartet...
[nodemon] ab node server.js
events.js:183
werfen ähm; // Unbehandeltes 'Fehler'-Ereignis
^

Fehler: EADDRINUSE hören :::3000
at Object._errnoException (util.js:1022:11)
at _ExceptionWithHostPort (util.js:1044:20)
at Server.setupListenHandle [as _listen2] (net.js:1367:14)
bei listenInCluster (net.js:1408:12)
bei Server.listen (net.js:1492:7)
bei Objekt.(/home/dg/junesis/server.js:8:8)
bei Module._compile (module.js:652:30)
bei Object.Module._extensions..js (module.js:663:10)
bei Module.load (module.js:565:32)
bei tryModuleLoad (module.js:505:12)
bei Function.Module._load (module.js:497:3)
bei Function.Module.runMain (module.js:693:10)
beim Start (bootstrap_node.js:188:16)
bei bootstrap_node.js:609:3
[nodemon] App abgestürzt - Warten auf Dateiänderungen vor dem Start...
[nodemon] wird aufgrund von Änderungen neu gestartet...
[nodemon] ab node server.js
Abhören auf Port 3000...

Wenn Sie einen Code wie diesen erhalten:

Fehler: Das Modul '/home/dg/junesis/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
wurde mit einer anderen Node.js-Version kompiliert
NODE_MODULE_VERSION 57. Diese Version von Node.js erfordert
NODE_MODULE_VERSION 64. Bitte versuchen Sie es erneut zu kompilieren oder neu zu installieren
das Modul (zum Beispiel mit npm rebuild oder npm install ).
at Object.Module._extensions..node (internal/modules/cjs/loader.js:807:18)
bei Module.load (internal/modules/cjs/loader.js:653:32)
bei tryModuleLoad (internal/modules/cjs/loader.js:593:12)
bei Function.Module._load (internal/modules/cjs/loader.js:585:3)
bei Module.require (internal/modules/cjs/loader.js:692:17)
bei erfordern (internal/modules/cjs/helpers.js:25:18)
bei Objekt.(/home/dg/junesis/node_modules/bcrypt/bcrypt.js:6:16)
at Module._compile (internal/modules/cjs/loader.js:778:30)
bei Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
bei Module.load (internal/modules/cjs/loader.js:653:32)
bei tryModuleLoad (internal/modules/cjs/loader.js:593:12)
bei Function.Module._load (internal/modules/cjs/loader.js:585:3)
bei Module.require (internal/modules/cjs/loader.js:692:17)
bei erfordern (internal/modules/cjs/helpers.js:25:18)
bei Objekt.(/home/dg/junesis/server/controller/userController.js:2:16)
at Module._compile (internal/modules/cjs/loader.js:778:30)
[nodemon] App abgestürzt - Warten auf Dateiänderungen vor dem Start...

Sie müssen die folgenden Befehle ausführen:
rm -rf node_modules/bcrypt
npm installieren

Ich habe das Problem jedoch zufällig mit dem folgenden Code in meiner Eingabedatei gelöst:
Prozess
// Behandeln Sie normale Ausgänge
.on('exit', (code) => {
nodemon.emit('beenden');
process.exit(code);
})

// Handle CTRL+C
.on('SIGINT', () => {
    nodemon.emit('quit');
    process.exit(0);
});

Danke an https://github.com/remy/nodemon/issues/1025#issuecomment -345361918

Unter Windows stoppen Sie die Prozesse "node.exe Node.js: Server-side JavaScript".

Fügen Sie am Ende Ihrer js-Datei hinzu, wo Sie den Server starten:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

Gern geschehen!

Das hat geholfen! Vielen Dank!

process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); }) am Ende meiner js-Datei auf einer debian-basierten Distribution hinzugefügt und das Problem verschwindet.

Ich habe das gleiche Problem und bin mir nicht 100% sicher, warum, aber ich habe gerade meine Startskripts bearbeitet, um einen Kill-Befehl einzuschließen.

Dies sollte funktionieren, wenn Sie nur mac / * nix für die Entwicklung verwenden, wie ich es bin. Ändern Sie Ihr Startskript, um alles zu beenden, was den Port beim Start verwendet, wie folgt:

"scripts": {
    "start": "npm run kill & node ./node_modules/.bin/nodemon ./bin/www",
    "kill": "kill $(lsof -t -i:3000) | exit 0",
}

3000 ist der Port, den Sie verwenden. | exit 0 unterdrückt einen Fehler, wenn der Port nicht verwendet wird. Der Startbefehl ist jetzt npm run kill & , der beendet und wartet, dann kann node ./node_modules/.bin/nodemon ./bin/www durch das ersetzt werden, was Sie normalerweise zum Starten Ihrer App verwenden.

Ich hatte dieses Problem noch nie, aber jetzt habe ich es plötzlich bekommen. Ubuntu 18.04 "nodemon": "^2.0.2" , Knotenversion 13.7.0 .

Ich hatte dieses Problem noch nie, aber jetzt habe ich es plötzlich bekommen. Ubuntu 18.04 "nodemon": "^2.0.2" , Knotenversion 13.7.0 .

Hier bei beiden Tools-Versionen gleich. Es scheint, dass dieses Problem regelmäßig aus einer Vielzahl von Ursachen auftaucht.

Da dieser Thread die beste Informationsquelle zu sein scheint, sollte er meiner Meinung nach wieder geöffnet werden.

Warten Sie, warten Sie, Nodemon läuft immer noch, nachdem ich den Prozess beendet habe! Ich bemerkte, nachdem ich eine Serverdatei optimiert hatte, und plötzlich tauchte die PID wieder auf. Ich führe Nodemon mit gleichzeitig aus, daher weiß ich nicht, ob das einen Unterschied macht.

Ich habe dieses Problem seit der letzten Woche bei einem neuen Hapi-Projekt. In 4 von 5 Fällen erhalte ich den EADDRINUSE-Fehler, wenn Nodemon neu geladen wird.

Aber ich kann diesen Fehler ich mit älteren Projekten arbeite, ältere Versionen von Hapi und dieselbe Version von nodemon ( 2.0.2 ) verwende. Ich kann es auch nicht reproduzieren, wenn ich ein Projekt von Grund auf mit den gleichen Hapi- und Nodemon-Versionen wie mein neues Projekt erstelle. Ich werde versuchen, die Ursache zu untersuchen, aber es ist nicht Hapi oder Nodemon selbst.

Ich hatte dieses Problem noch nie, aber jetzt habe ich es plötzlich bekommen. Ubuntu 18.04 "nodemon": "^2.0.2" , Knotenversion 13.7.0 .

Hier bei beiden Tools-Versionen gleich. Es scheint, dass dieses Problem regelmäßig aus einer Vielzahl von Ursachen auftaucht.

Da dieser Thread die beste Informationsquelle zu sein scheint, sollte er meiner Meinung nach wieder geöffnet werden.

Ja, mit @Ratstail91 - sollte wieder geöffnet werden.

Hi,

Ich habe seit heute das gleiche Problem hier.
Ich verwende Nodemon mit ts-node (Projekt entwickelt mit Typoskript)

Ich habe alles unten versucht und NICHTS hat funktioniert:

1. Node_modules neu installieren
2. Wechseln Sie die Knotenversionen von 10 auf 12 und 13 und auch alpine Tags.
3. Wechsel von Nodemon 2.0.2 auf 1.19
4. Bereinigen Sie Docker-Volumes, Netzwerke, Container, Images
5. Bilder von Grund auf neu erstellen.
6. Beenden Sie alle Knotenprozesse und alles, was auf 3000 läuft, mit allen möglichen Techniken: lsof, pkill, kill, killall ...
7. Port von 3000 auf andere ändern
8. Host von 0.0.0.0 auf andere ändern
9. Starten Sie meinen Computer neu (letzte Lösungssituation)

Das Lustige ist, dass ich Nodemon gestern aktualisiert habe ...
Wenn Sie eine Lösung haben, bin ich immer noch hier.

Meldungsfehler ist =>

yume-api | Error: listen EADDRINUSE: address already in use "3000" yume-api | at Server.setupListenHandle [as _listen2] (net.js:1263:19) yume-api | at listenInCluster (net.js:1328:12) yume-api | at Server.listen (net.js:1426:5) yume-api | at Function.listen (/usr/src/yume-api/node_modules/express/lib/application.js:618:24) yume-api | at Object.<anonymous> (/usr/src/yume-api/src/server.ts:35:5) yume-api | at Module._compile (internal/modules/cjs/loader.js:778:30) yume-api | at Module.m._compile (/usr/src/yume-api/node_modules/ts-node/src/index.ts:814:23) yume-api | at Module._extensions..js (internal/modules/cjs/loader.js:789:10) yume-api | at Object.require.extensions.(anonymous function) [as .ts] (/usr/src/yume-api/node_modules/ts-node/src/index.ts:817:12) yume-api | at Module.load (internal/modules/cjs/loader.js:653:32) yume-api | at tryModuleLoad (internal/modules/cjs/loader.js:593:12) yume-api | at Function.Module._load (internal/modules/cjs/loader.js:585:3) yume-api | at Function.Module.runMain (internal/modules/cjs/loader.js:831:12) yume-api | at main (/usr/src/yume-api/node_modules/ts-node/src/bin.ts:226:14) yume-api | at Object.<anonymous> (/usr/src/yume-api/node_modules/ts-node/src/bin.ts:485:3) yume-api | at Module._compile (internal/modules/cjs/loader.js:778:30) yume-api | at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) yume-api | at Module.load (internal/modules/cjs/loader.js:653:32) yume-api | at tryModuleLoad (internal/modules/cjs/loader.js:593:12) yume-api | at Function.Module._load (internal/modules/cjs/loader.js:585:3) yume-api | at Function.Module.runMain (internal/modules/cjs/loader.js:831:12) yume-api | at startup (internal/bootstrap/node.js:283:19) yume-api | [nodemon] app crashed - waiting for file changes before starting...

Und übrigens, ich habe eine seltsame Socket-Datei "3000", die im Projektverzeichnis erstellt wird, irgendwelche Hinweise, woher das kommt?

Ich hatte dieses Problem noch nie, aber jetzt habe ich es plötzlich bekommen. Ubuntu 18.04 "nodemon": "^2.0.2" , Knotenversion 13.7.0 .

Hier bei beiden Tools-Versionen gleich. Es scheint, dass dieses Problem regelmäßig aus einer Vielzahl von Ursachen auftaucht.

Da dieser Thread die beste Informationsquelle zu sein scheint, sollte er meiner Meinung nach wieder geöffnet werden.

Ich habe dieses Problem auch bei node von Docker Official Images .
Allerdings läuft nur der Docker-Container auf Mac OS , aber nicht auf dem Windows 10 Host.

Ich stehe auch vor dem gleichen Problem, ich muss das Projekt 3/4 Mal hintereinander speichern, damit es funktioniert.

Schließe dieses Problem ab. Es basierte auf 3 Jahre altem Code, hatte einen PR-Merge und behob die Ursache des Problems.

Personen, die in jüngerer Zeit posten, haben ähnliche Symptome, aber nicht die gleiche Quelle (und es gibt nie Informationen zum Replizieren).

Brauche einen PR um diese _neuen_ Probleme zu beheben. Vielen Dank.