Nodemon: Nodemon laisse fréquemment le processus enfant en cours d'exécution (détaché)

Curieusement, j'ai commencé à avoir le même problème ici. Je n'avais pas l'habitude de vivre cela auparavant et je ne sais pas ce que j'ai mis à jour pour commencer à avoir ce problème.

OS X El Capitan
Nœud v6.9.1
nodemon v1.11.0

Idem ici, j'obtiens aussi une erreur EADDRINUSE dans mon serveur express

OS X Sierra
Nœud 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 génère 31962, mais 31963 reste en place (je pense que 31963 est un processus enfant de 31962). Ensuite, lors du redémarrage, cela pose un problème, car 31963 a toujours le serveur en cours d'exécution.

Mettre à jour:
Lors de la recherche, il semble que SIGUSR2 ne soit pas assez bon pour tuer le processus enfant. SIGHUP était nécessaire.

J'ai le même problème. Quelqu'un a-t-il déjà trouvé une solution ?

J'avais le même problème et il semblait surgir de nulle part. J'ai commencé à ajouter ceci au bas de mon fichier d'entrée js afin que ce soit les dernières lignes exécutées de mon script, et cela a semblé résoudre le problème pour moi. J'espère que ça aide!

Je quitte mon processus nodemon dans iTerm avec CTRL+C et sur un mac exécutant OSX Sierra 10.12.5.

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

Même problème, ce n'est pas grave si je CTRL+C hors de celui-ci et relancer npm start .

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

Même problème, comment le résoudre ?

[[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)

Éditer:
quand j'édite le fichier gulp comme ça, c'est du travail

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);
            });
        });
});

J'ai exactement le même problème ici.

Désolé, la seule chose que j'ai trouvée après plusieurs tests est qu'une installation propre du système d'exploitation a résolu ce problème pour moi sous Linux. Bien sûr, je ne nettoierai pas l'installation à chaque fois, je ne faisais que déconner.

Idem ici sur OSX. Maintenir tous les processus de nœud en cours d'exécution (1.12.0)

Une solution à ce problème ?

Non, je n'ai pas encore rencontré le problème. Je ne sais pas pourquoi nodemon a perdu le processus.

Des solutions ?

J'ai également rencontré ce problème sur Ubuntu 16.04, nodemon 1.12.1 et node v8. Je n'ai pas trouvé de solution à part tuer manuellement le processus.

Pour développer davantage ce que j'ai fait sur mon commentaire précédent - le signal ( SIGUSR2 ) qui a été envoyé à mon programme n'a pas provoqué sa sortie. J'ai dû changer le signal en SIGHUP place.

J'ai créé un fichier nommé nodemon.json :

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

et dans mon package.json, puisque j'utilise des scripts npm, l'exécution de nodemon devrait suffire :

"dev": "nodemon",

Le problème est sur ts-node lui-même : https://github.com/TypeStrong/ts-node/pull/458

Pour débarrasser votre application/programme de cette erreur sur Windows, vous devez tuer le processus PID sur le port 3000.

Le vrai problème ici est que nodemon utilise child_process.spawn au lieu de child_process.fork pour créer des processus enfants . Dans ce cas, tuer le parent ne tue pas ses enfants.

La solution consiste à modifier nodemon pour utiliser child_process.fork lors de la création de processus enfants de nœud (et child_process.spawn pour les exécutables non-nœud), afin que ce nœud soit gracieux (et automatique) ramasse-miettes peut entrer en vigueur au décès du parent.

L'utilisation de child_process.fork ajoute également l'avantage supplémentaire d'utiliser les canaux IPC pour la communication entre les processus de nœud parent et enfant, de sorte que les méthodes process.send et process.on peuvent être utilisées pour la communication inter-processus .

J'ai créé un simple PR ici qui résout le problème (mais ne passe pas encore les tests CI): https://github.com/remy/nodemon/pull/1134

J'espère que le mainteneur pourra étoffer davantage le code, ou si je trouve du temps pour aider, je le ferai.

Un correctif temporaire que l'on peut appliquer pour résoudre ce problème est :

// 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 est la solution la plus propre car elle nettoie automatiquement les processus enfants lorsque le parent meurt. nodemon doit être édité pour qu'il utilise fork plutôt que spawn (pour les node exécutables uniquement).

Je me souviens avoir fait tout le saut au cerceau pour déterminer quelle méthode est la bonne. IIRC spawn est la méthode que je dois utiliser pour maintenir un lien que spawn m'a donné mais pas fork (et al).

N'hésitez pas à envoyer un PR qui réussit tous les tests si vous pensez que cela fonctionnera.

Ah, désolé, j'ai raté le PR, mais oui, ça échoue et je soupçonne que c'est parce que vous bifurquez.

Eh bien, oui, comme je l'ai dit, et comme il est indiqué dans la documentation node , fork est spécifiquement destiné à être utilisé avec les processus de nœud engendrant des processus de nœud enfant, tandis que spawn est pour tous les autres processus non-noeuds.

La méthode child_process.fork() est un cas particulier de child_process.spawn() utilisé spécifiquement pour générer de nouveaux processus Node.js. Comme child_process.spawn(), un objet ChildProcess est renvoyé. Le ChildProcess renvoyé aura un canal de communication supplémentaire intégré qui permet aux messages d'être transmis entre le parent et l'enfant. Voir subprocess.send() pour plus de détails.
https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

Je vais voir si je peux continuer avec les relations publiques, mais ce n'est peut-être pas long. Le .apply vous utilisez pour appeler spawn n'est pas quelque chose que j'utilise régulièrement, et nous aurions besoin de trouver un moyen de gérer stdin/out/err qui peut être fait avec silent: true en option lors du bifurcation.

Vos tests vérifient-ils un PID enfant ou vérifient-ils stdin/out, ou .. ?

Si vous êtes convaincu que spawn est la seule réponse pour votre dépôt, alors je suggérerais d'essayer de stocker le PID de l'enfant engendré et de tuer ce .on('exit') , .on('SIGINT') , etc... bien que je pense toujours que ce sera beaucoup plus facile en utilisant fork .

Même problème ici, je suppose que cela a commencé il y a quelques jours lorsque je suis passé de NodeJS 6.4.0 à NodeJS 8.90

Cela se produit lorsque j'arrête pour la première fois nodemon avec CTRL+C, puis je dois le redémarrer.

Maintenant, je dois arrêter manuellement le processus Node via le Gestionnaire des tâches à chaque fois [Windows 10]

Même problème ici.

$ node -v
v8.9.2

$ nodemon -v
1.12.5

Le travail de @heisian ici a été fusionné et devrait résoudre ce problème pour vous tous. 👏 Actuellement en direct dans [email protected]

suh chouette ! heureux d'avoir aidé.

@heisian quelques bits sont arrosés ici et là, mais j'ai un changement en cours qui devrait fonctionner autour de cela (principalement autour de la transmission des arguments de lancement au nœud lui-même).

hmm, peut-être que je n'étais pas clair alors sur la façon dont les arguments destinés au processus de nœud enfant sont référencés dans run.js ?

J'avais l'intention que tous les arguments devant être transmis au nœud soient insérés dans la variable forkArgs :

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

Par exemple, je fork un processus pour transpiler du 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',
    });

Tout cela devrait être l'équivalent de :

 ./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

Oui, j'ai essayé cela dans un test local, il y a le .splice(1) qui supprime en fait le --inspect s'il se trouve dans les arguments CLI, mais aussi, cela ne fonctionne tout simplement pas. Je pense que c'est parce qu'il s'éloigne du processus de nœud principal (celui qui exécute actuellement nodemon.js) qui n'a pas le débogueur ouvert.

J'ai piraté une solution pour l'instant (voir les commentaires dans votre PR), et cela résout les derniers problèmes, mais je ne suis pas sûr à 100% qu'elle soit à l'épreuve des balles.

hmm d'accord, je vais l'examiner et voir si une meilleure solution peut être trouvée. oui, je pense que c'est le cas, --inspect doit être signalé sur le processus parent qui est transmis à l'enfant.

Mis à jour de 1.12.1 à 1.12.7 et toujours en cours

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

lorsque je redémarre Nodemon après l'avoir quitté (CTRL+C).

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

Pouvez-vous déposer un problème séparé et inclure tous les détails sur la façon dont vous exécutez Windows (git bash, etc.)

@remy bien sûr, #1164

Je n'exécute pas de serveur express mais j'exécute un socket net nodejs et j'ai le même problème avec nodemon -v: 1.14.2
nœud -v : 9.4
ubuntu/xenial

alors peut-être que les pr mentionnés ci-dessus n'ont pas résolu ce problème ?

Si nodemon ne plante pas, il redémarrera correctement après les modifications, mais si nodemon plante ou si je dois le terminer, il laisse le socket en cours d'exécution et je dois pkill node avant d'exécuter à nouveau nodemon, sinon je vais utiliser le port Erreur.

Remarque: dans mon module qui démarre le socket net, j'ai intégré un code d'arrêt. Ainsi, lorsque le processus se termine brusquement, comme avec cntrl-c (SIGUP), il arrête le socket. Pour info, j'utilise le module sur la mort.

je n'utilise pas babel mais j'utilise @std/esm comme dans nodemon --require @std/esm

J'essaierais d'abord de confirmer que vos processus enfants sont effectivement en cours de création et non générés. Si, à partir de votre processus enfant, vous pouvez faire ceci :

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

...et chez tes parents tu peux recevoir avec succès le message :

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

...alors votre processus a en effet été fork avec child_process.fork et devrait se terminer normalement lorsque le parent se terminera. Si ce qui précède ne fonctionne pas, alors votre processus enfant a été spawned et vous devrez donc trouver comment gérer vous-même la fin du processus - soit par SIGKILL process.on('exit') ou une combinaison des deux.

Je rencontre également cela sur l'une des dernières versions de nodemon:1.17.3

Je vis également cela avec nodemon 1.17.3, node 9.2.0, sur macOS High Sierra v10.13.4, @johnnydimas une solution de doublure ci-dessus l'a corrigé pour moi, jusqu'à présent.

Je reçois également cela sur Ubuntu 18.04 et 17.10.

Avoir ça aussi ! tous les paquets à jour.
sur macOS High Sierra v10.13.2

@lukebrewerton @MissAnichka @danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
J'ai réussi à résoudre ce problème.
Ce n'est en fait pas nodemon, mais babel-node !
npm i kexec -D résoudra le problème

Explication:
https://github.com/babel/babel/issues/1062#issuecomment -84526036

Éditer:
Je suis devenu un peu enthousiaste et ne prenait pas en compte les autres cas d'utilisation.
MAIS si vous utilisez babel-node, cela devrait résoudre le problème =D

Je n'utilise pas babel, juste un vieux nœud js

Toujours obtenir cela sur nodemon 1.17.5 avec node 9.5.

Idem malheureusement, courir avec node -r ts-node/register index.ts

@Kamshak, veuillez ouvrir un nouveau numéro et inclure votre index.ts réduit à un exemple reproductible

J'ai toujours ce problème avec nodemon 1.18.3 et node 8.11.4 sur macOS 10.13.3.

Même problème... nodemon 1.18.3 et node 8.11.4 sur Ubuntu 18.04 LTS. J'ai également essayé la route de configuration nodemon en utilisant explicitement SIGHUP pour tuer le processus et en ajoutant un délai supplémentaire de 2500 ms ..... Pas de joie malheureusement ....

Si vous lancez nodemon via le panneau de terminaux WebStorm et que vous avez EADDRINUSE après avoir redémarré l'IDE (ou peut-être simplement en rouvrant le panneau de terminaux), vérifiez s'il reste un processus nodemon errant dans la liste des processus. Cela m'est arrivé sur Ubuntu 18.04.

Merci pour l'astuce @dchekanov . J'avais le même problème en utilisant vscode. J'obtiendrais de manière fiable l'échec d'EADDRINUSE chaque fois que nodemon essayait de redémarrer. Il serait logique qu'il s'agisse d'une sorte de condition de concurrence entre deux processus nodemon.

J'ai le même problème.
nodemon -v 1.18.4
nœud -v v8.11.1
macOS Mojave version 10.14
Terminal VsCode

J'ai le même problème. Vous pouvez cloner ce référentiel : https://github.com/aecorredor/express-graphql-postgres-starter et exécuter yarn puis yarn start , apporter une modification, enregistrer et voir l'erreur . Notez que je n'utilise pas simultanément. Je viens de courir nodemon --exec babel-node index.js

Même problème. 1.18.6.
Exécution dans Docker sur Ubuntu, nœud 10.11

Même problème ici !

Ça m'a aidé
yarn add --dev kexec

J'ai aussi récemment eu le même problème....
peut-être à cause de la mise à niveau de docker... je ne sais pas pourquoi...
EADDRINUSE...

Salut @justintien ,

J'ai été confronté plusieurs fois à ce problème avec nodemon, mais j'ai changé pour le package pm2 (http://pm2.keymetrics.io/), celui que j'utilise en production.

Ajoutez-le et démarrez-le avec : pm2 start src/server.ts --watch --no-daemon
Si vous avez des scripts ES6, vous devez préinstaller le module dactylographié et vous pouvez l'ajouter en post-installation avec :
"postinstall": "$(yarn bin)/pm2 install typescript"

J'espère que cette aide.

La seule façon qui a fonctionné pour moi était d'ajouter "signal": "SIGTERM", dans nodemon.json .

J'utilise Yarn, Docker et Alpine 10.

@lukebrewerton @MissAnichka @danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
J'ai réussi à résoudre ce problème.
Ce n'est en fait pas nodemon, mais babel-node !
npm i kexec -D résoudra le problème

Explication:
babel/babel#1062 (commentaire)

Éditer:
Je suis devenu un peu enthousiaste et ne prenait pas en compte les autres cas d'utilisation.
MAIS si vous utilisez babel-node, cela devrait résoudre le problème =D

J'ai toujours le même problème avec tous les packages mis à jour vers la dernière version. Mais en installant kexec , cela fonctionne d'une manière ou d'une autre. Mais je ne suis pas tout à fait sûr car il semble que le package kexec ne soit pas activement maintenu.

npmi kexex n'a pas fonctionné pour moi, en utilisant 1.18.6

Chers amis, il s'agit d'un problème clos et non pris en charge. S'il y a un bogue que vous voyez dans le dernier nodemon, veuillez signaler un nouveau problème avec des instructions complètes sur la façon de répliquer.

Notez que je l'ai déjà dit auparavant sur le même problème.

Sinon, sachez que je ne surveille pas les problèmes clos.

je rencontrais le même problème et je m'en débarrasse en installant la version 1.12.6 avec la commande suivante : yarn global add nodemon@next puis vous choisirez dans la liste la version 1.12.6 ou vous pouvez simplement exécuter yarn global add [email protected] merci à : @remy pour la solution : https://github.com/remy/nodemon/issues/1025#issuecomment -351394591

docker : noeud : 10-alpin
nœud : v10.6.0
nodemon : v1.18.7

J'ai trouvé la raison :

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

j'ai déjà essayé :

• "signal": "SIGTERM", dans nodemon.json.
• npm i -D kexc (je sais que babel-node utilisera d'abord kexec, mais c'est une erreur de lancement)

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
En production, je n'ai pas utilisé nodemon, c'était juste pour le développeur...
J'utilise docker en production. :rougir:

Face au problème avec [email protected] et [email protected] ,
donc dû mettre à jour nodemone à 1.18.8, fonctionne maintenant ✅

Utilisez TS et le serveur Apollo.

Confirmant ce que @alienalien13 a dit, je suis sur Nodemon 1.18.9 et NodeJS 11.4.0 expérimental

nouvelles!

Je passe à 1.18.9, ça marche bien !!

super!!

@mohamed-badaoui

Merci mec ! merci pour le retour

Pour développer davantage ce que j'ai fait sur mon commentaire précédent - le signal ( SIGUSR2 ) qui a été envoyé à mon programme n'a pas provoqué sa sortie. J'ai dû changer le signal en SIGHUP place.

J'ai créé un fichier nommé nodemon.json :

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

et dans mon package.json, puisque j'utilise des scripts npm, l'exécution de nodemon devrait suffire :

"dev": "nodemon",

Comme solution de contournement, l'ajout de "signal": "SIGHUP" fonctionné pour moi.

@Mutmatt nodemon v1.18.10 me dit "Option inconnue ou inattendue : --inspect".

@bennyn Vous pouvez ajouter n'importe quelle commande de type package.json .

Par exemple nodemon.json

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

Je vois! C'est donc un indicateur qui a été supprimé dans ts-node . Désolé mon mauvais. ??

Même problème ici
Error: listen EADDRINUSE
nodemon: 1.18.11
node: 10.14.1

tout ne fonctionne pas pour moi :(
en utilisant ts-node + nodemon

j'utilisais le terminal Visual Studio, Ubuntu 18, une façon était de quitter le terminal, de trouver le processus et de le tuer
démarrer un nouveau terminal en dehors du studio visuel
donc ça a marché pour moi

En haut

Vérifiez si nodemon est installé globalement. Le supprimer a résolu le problème pour moi.

J'utilisais la bibliothèque dotenv pour les variables d'environnement et j'ai rencontré le même problème. Pour moi, c'était un fichier '.env'.

C'était comme:
PORT=3000,

N'oubliez pas de supprimer les virgules si vous effectuez un copier-coller à partir de json.

c'est ce qui a résolu le problème pour moi
npm cache clean -force

L'option "autoAttachChildProcesses": true résolue pour moi

L'option "autoAttachChildProcesses": vrai résolu pour moi

L'avez-vous configuré dans nodemon.json ou où doit-on placer cette option ?

J'ai le même problème en ce moment. J'ai essayé de déboguer la boucle d'événements s'il reste quelque chose mais semble être non.

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

Quelqu'un a-t-il trouvé la bonne solution propre pour cela?

Sous Windows, arrêtez les processus "node.exe Node.js : JavaScript côté serveur".

Ajoutez en bas de votre fichier js, là où vous démarrez le serveur, mettez ceci :
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

De rien!

Juste pour info, si quelqu'un a encore du mal, essayez aussi ceci:
J'utilise du fil et un simple yarn cache clean fait la magie pour moi.
Pour les utilisateurs de npm, essayez npm cache clean .

Il n'y a donc aucun moyen de tuer nodemon lorsqu'il s'exécute ???

Je viens de mettre à jour le dernier nodemon et de passer du nœud 6 au nœud 10 avec la mise à niveau de NPM et de se heurter à ceci :
"nodemon": "^1.19.2",
nœud : 10.16.0
npm : 6.9.0

@ doc82 ce problème particulier est extrêmement compliqué et est rarement la même chose à chaque fois.

Vous voudrez soulever un nouveau problème avec tous les détails sur la façon de répliquer, car 9 fois sur 10, c'est la façon dont nodemon est exécuté sur votre projet qui provoque le "sous-processus suspendu".

Je faisais face à une erreur avec ce qui suit : -

[nodemon] redémarre en raison de changements...
[nodemon] à partir de node server.js
événements.js:183
jeter euh ; // Evénement 'erreur' non géré
^

Erreur : écoutez EADDRINUSE :::3000
à Object._errnoException (util.js:1022:11)
à _exceptionWithHostPort (util.js:1044:20)
sur Server.setupListenHandle [as _listen2] (net.js:1367:14)
à listenInCluster (net.js:1408:12)
sur Server.listen (net.js:1492:7)
à l'objet.(/home/dg/junesis/server.js:8:8)
à Module._compile (module.js:652:30)
à Object.Module._extensions..js (module.js:663:10)
à Module.load (module.js:565:32)
à tryModuleLoad (module.js:505:12)
à Function.Module._load (module.js:497:3)
à Function.Module.runMain (module.js:693:10)
au démarrage (bootstrap_node.js:188:16)
à bootstrap_node.js:609:3
L'application [nodemon] a planté - en attente de modifications de fichier avant de commencer...
[nodemon] redémarre en raison de changements...
[nodemon] à partir de node server.js
Ecoute sur le port 3000...
[nodemon] redémarre en raison de changements...
[nodemon] à partir de node server.js
événements.js:183
jeter euh ; // Evénement 'erreur' non géré
^

Erreur : écoutez EADDRINUSE :::3000
à Object._errnoException (util.js:1022:11)
à _exceptionWithHostPort (util.js:1044:20)
sur Server.setupListenHandle [as _listen2] (net.js:1367:14)
à listenInCluster (net.js:1408:12)
sur Server.listen (net.js:1492:7)
à l'objet.(/home/dg/junesis/server.js:8:8)
à Module._compile (module.js:652:30)
à Object.Module._extensions..js (module.js:663:10)
à Module.load (module.js:565:32)
à tryModuleLoad (module.js:505:12)
à Function.Module._load (module.js:497:3)
à Function.Module.runMain (module.js:693:10)
au démarrage (bootstrap_node.js:188:16)
à bootstrap_node.js:609:3
L'application [nodemon] a planté - en attente de modifications de fichier avant de commencer...
[nodemon] redémarre en raison de changements...
[nodemon] à partir de node server.js
Ecoute sur le port 3000...

Si vous obtenez un code comme celui-ci :

Erreur : Le module '/home/dg/junesis/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
a été compilé avec une version différente de Node.js en utilisant
NODE_MODULE_VERSION 57. Cette version de Node.js nécessite
NODE_MODULE_VERSION 64. Veuillez essayer de recompiler ou de réinstaller
le module (par exemple, en utilisant npm rebuild ou npm install ).
à Object.Module._extensions..node (internal/modules/cjs/loader.js:807:18)
à Module.load (internal/modules/cjs/loader.js:653:32)
à tryModuleLoad (interne/modules/cjs/loader.js:593:12)
à Function.Module._load (internal/modules/cjs/loader.js:585:3)
à Module.require (internal/modules/cjs/loader.js:692:17)
au besoin (interne/modules/cjs/helpers.js:25:18)
à l'objet.(/home/dg/junesis/node_modules/bcrypt/bcrypt.js:6:16)
à Module._compile (internal/modules/cjs/loader.js:778:30)
à Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
à Module.load (internal/modules/cjs/loader.js:653:32)
à tryModuleLoad (interne/modules/cjs/loader.js:593:12)
à Function.Module._load (internal/modules/cjs/loader.js:585:3)
à Module.require (internal/modules/cjs/loader.js:692:17)
au besoin (interne/modules/cjs/helpers.js:25:18)
à l'objet.(/home/dg/junesis/server/controller/userController.js:2:16)
à Module._compile (internal/modules/cjs/loader.js:778:30)
L'application [nodemon] a planté - en attente de modifications de fichier avant de commencer...

Vous devez exécuter les commandes suivantes :
rm -rf modules_noeuds/bcrypt
npm installer

Cependant, il m'est arrivé de résoudre le problème en utilisant le code ci-dessous dans mon fichier d'entrée :
traiter
// Gérer les sorties normales
.on('sortie', (code) => {
nodemon.emit('quitter');
process.exit(code);
})

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

Merci à https://github.com/remy/nodemon/issues/1025#issuecomment -345361918

Sous Windows, arrêtez les processus "node.exe Node.js : JavaScript côté serveur".

Ajoutez en bas de votre fichier js, là où vous démarrez le serveur, mettez ceci :
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

De rien!

Cela a aidé ! Merci!

Ajout de process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); }) à la fin de mon fichier js sur une distribution basée sur Debian et fait disparaître le problème.

Je rencontre ce même problème et je ne suis pas sûr à 100% pourquoi, mais je viens de modifier mes scripts de démarrage pour inclure une commande kill.

Cela devrait fonctionner si vous n'utilisez que mac/*nix pour le développement comme je le suis, modifiez votre script de démarrage pour tuer tout ce qui utilise le port au démarrage comme suit :

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

3000 est le port que vous utilisez. | exit 0 taire une erreur si le port n'est pas utilisé. La commande de démarrage est maintenant npm run kill & qui tue et attend, puis node ./node_modules/.bin/nodemon ./bin/www peut être remplacé par tout ce que vous utilisez normalement pour démarrer votre application.

Je n'ai jamais eu ce problème auparavant, mais j'ai commencé à l'avoir maintenant tout d'un coup. Ubuntu 18.04 "nodemon": "^2.0.2" , version de nœud 13.7.0 .

Je n'ai jamais eu ce problème auparavant, mais j'ai commencé à l'avoir maintenant tout d'un coup. Ubuntu 18.04 "nodemon": "^2.0.2" , version de nœud 13.7.0 .

Idem ici sur les versions des deux outils. Il semble que ce problème surgisse périodiquement à partir d'une myriade de causes.

Étant donné que ce fil semble être la meilleure source d'informations, je pense qu'il devrait être rouvert.

Attendez, attendez, nodemon est toujours en cours d'exécution après avoir tué le processus ! J'ai remarqué après avoir modifié un fichier de serveur, et tout à coup, le pid est réapparu. J'exécute nodemon avec simultanément, donc je ne sais pas si cela fait une différence.

J'ai rencontré ce problème la semaine dernière sur un nouveau projet Hapi. 4 fois sur 5, j'obtiens l'erreur EADDRINUSE lorsque nodemon se recharge.

Mais je ne peux pas reproduire cette erreur lorsque 2.0.2 ). Je ne peux pas non plus le reproduire lors de la création d'un projet à partir de zéro avec les mêmes versions Hapi & nodemon que mon nouveau projet. Je vais essayer d'enquêter sur la cause, mais ce n'est pas Hapi ou nodemon eux-mêmes.

Je n'ai jamais eu ce problème auparavant, mais j'ai commencé à l'avoir maintenant tout d'un coup. Ubuntu 18.04 "nodemon": "^2.0.2" , version de nœud 13.7.0 .

Idem ici sur les versions des deux outils. Il semble que ce problème surgisse périodiquement à partir d'une myriade de causes.

Étant donné que ce fil semble être la meilleure source d'informations, je pense qu'il devrait être rouvert.

Oui, avec @ Ratstail91 - devrait être rouvert.

Salut,

J'ai le même problème ici, à partir d'aujourd'hui.
J'utilise nodemon avec ts-node (projet développé à l'aide de typescript)

J'ai tout essayé ci-dessous et RIEN n'a fonctionné :

1. Réinstaller node_modules
2. Basculez les versions de nœud de 10 à 12 et 13 et les balises alpines également.
3. Passer de nodemon 2.0.2 à 1.19
4. Élaguer les volumes Docker, les réseaux, les conteneurs, les images
5. Reconstruire des images à partir de zéro.
6. Tuez tous les processus de nœuds et tout ce qui s'exécute sur 3000 en utilisant toutes sortes de techniques : lsof, pkill, kill, killall...
7. Changement de port de 3000 à d'autres
8. Changement d'hôte de 0.0.0.0 à d'autres
9. Redémarrer ma machine (dernière situation de solution)

Le plus drôle, c'est que j'ai mis à jour nodemon hier...
Si vous avez une solution, je suis toujours là.

L'erreur de message est =>

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...

Et au fait, j'ai un fichier socket étrange "3000" qui est créé dans le répertoire du projet, des indices sur d'où cela vient ?

Je n'ai jamais eu ce problème auparavant, mais j'ai commencé à l'avoir maintenant tout d'un coup. Ubuntu 18.04 "nodemon": "^2.0.2" , version de nœud 13.7.0 .

Idem ici sur les versions des deux outils. Il semble que ce problème surgisse périodiquement à partir d'une myriade de causes.

Étant donné que ce fil semble être la meilleure source d'informations, je pense qu'il devrait être rouvert.

Je suis également confronté à ce problème sur node partir de Docker Official Images .
Cependant, seul le conteneur Docker s'exécute sur Mac OS , mais pas pour l'hôte Windows 10 .

Je suis également confronté au même problème, je dois enregistrer le projet 3/4 fois de suite pour le faire fonctionner.

Je verrouille ce problème. Il était basé sur un code vieux de 3 ans, avait une fusion préalable et corrigeait la source du problème.

Les personnes qui publient plus récemment présentent des symptômes similaires mais pas la même source (en plus, il n'y a jamais d'informations à reproduire).

Prendra un pr pour résoudre ces _nouveaux_ problèmes. Merci.