Nodemon: Nodemon deja con frecuencia el proceso hijo en ejecución (desconectado)

Curiosamente, he comenzado a tener el mismo problema aquí. No solía experimentar esto antes, y no estoy seguro de qué actualicé para comenzar a tener este problema.

OS X El Capitán
Nodo v6.9.1
nodemon v1.11.0

Lo mismo aquí, también obtengo un error EADDRINUSE en mi servidor express

OS X Sierra
Nodo 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 genera 31962, pero 31963 aún permanece (creo que 31963 es un proceso hijo de 31962). Luego, al reiniciar, esto causa un problema, porque 31963 todavía tiene el servidor en funcionamiento.

Actualizar:
Al buscar, parece que SIGUSR2 no es lo suficientemente bueno como para matar el proceso hijo. Se necesitaba SIGHUP.

Estoy teniendo el mismo problema. ¿A encontrado alguien una solución todavía?

Estaba teniendo el mismo problema y parecía surgir de la nada. Comencé a agregar esto al final de mi archivo js de entrada para que fueran las últimas líneas ejecutadas de mi script, y pareció aclarar el problema para mí. ¡Espero eso ayude!

Salgo de mi proceso de nodemon en iTerm con CTRL + C y en una Mac con OSX Sierra 10.12.5.

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

El mismo problema, está bien si CTRL + C fuera de él y lanzo npm start nuevamente.

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

Mismo problema, ¿cómo solucionarlo?

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

Editar:
cuando edito el archivo gulp de esta manera, funciona

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

Tener exactamente el mismo problema aquí.

Lo siento, lo único que encontré después de varias pruebas es una instalación limpia del sistema operativo que solucionó esto en Linux. Por supuesto que no limpiaré la instalación cada vez, solo estaba jugando.

Lo mismo aquí en OSX. Mantener todos los procesos de nodo en ejecución (1.12.0)

¿Alguna solución a este problema?

No, todavía no he vuelto a afrontar el problema. No sé qué causa que nodemon pierda el proceso.

¿Alguna solución?

También he estado experimentando este problema en ubuntu 16.04, nodemon 1.12.1 y node v8. No he encontrado una solución aparte de matar manualmente el proceso.

Para desarrollar más lo que hice en mi comentario anterior, la señal ( SIGUSR2 ) que se envió a mi programa no hizo que se cerrara. Tuve que cambiar la señal a SIGHUP lugar.

Creé un archivo llamado nodemon.json :

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

y en mi package.json, dado que uso scripts npm, ejecutar nodemon debería ser suficiente:

"dev": "nodemon",

El problema está en ts-node sí mismo: https://github.com/TypeStrong/ts-node/pull/458

Para eliminar este error de su aplicación / programa en Windows, debe eliminar el proceso PID en el puerto 3000.

El verdadero problema aquí es que nodemon usa child_process.spawn lugar de child_process.fork para crear procesos secundarios . En este caso, matar al padre no mata a sus hijos.

La solución a esto es modificar nodemon para usar child_process.fork al crear procesos secundarios de nodo (y child_process.spawn para ejecutables que no son de nodo), de modo que la recolección de basura elegante (y automática) del nodo puede entrar en vigor cuando el padre muere.

El uso de child_process.fork también agrega el beneficio adicional de usar los canales de IPC para la comunicación entre los procesos de los nodos padre e hijo, de modo que los métodos process.send y process.on se pueden utilizar para la comunicación entre procesos .

He creado un PR simple aquí que aborda el problema (pero aún no pasa las pruebas de CI): https://github.com/remy/nodemon/pull/1134

Con suerte, el mantenedor puede desarrollar más el código, o si encuentro tiempo en el futuro para ayudar, lo haré.

Una solución temporal que se puede aplicar para abordar esto es:

// 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 es la solución más limpia porque limpia automáticamente los procesos secundarios cuando el padre muere. nodemon debe editarse para que use fork lugar de spawn (solo para ejecutables node ).

Recuerdo haber pasado por todo el salto del aro para determinar qué método es el correcto. IIRC spawn es el método que necesito usar para mantener algún enlace que me dio spawn pero fork (et al) no lo hizo.

No dude en enviar un PR que pase todas las pruebas si cree que esto funcionará.

Ah, lo siento, me perdí el PR, pero sí, falla y sospecho que es porque estás bifurcando.

Bueno, sí, como dije, y como dice en la documentación node , fork está diseñado específicamente para su uso con procesos de nodo que generan procesos de nodo hijo, mientras que spawn es para todos los demás procesos que no son de nodo.

El método child_process.fork () es un caso especial de child_process.spawn () usado específicamente para generar nuevos procesos Node.js. Como child_process.spawn (), se devuelve un objeto ChildProcess. El ChildProcess devuelto tendrá un canal de comunicación adicional incorporado que permite que los mensajes se pasen de un lado a otro entre el padre y el hijo. Consulte subprocess.send () para obtener más detalles.
https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

Veré si puedo continuar con las relaciones públicas, pero puede que no pase un tiempo. El .apply que usa para llamar a spawn no es algo que yo use habitualmente, y tendríamos que encontrar una manera de manejar stdin/out/err que se puede hacer con silent: true como opción al bifurcar.

¿Sus pruebas verifican si hay una PID infantil o verifican stdin / out, o ...?

Si está convencido de que spawn es la única respuesta para su repositorio, le sugiero que intente almacenar el PID del niño generado y elimine ese .on('exit') , .on('SIGINT') , etc ... aunque todavía creo que será mucho más fácil usar fork .

El mismo problema aquí, supongo que comenzó hace unos días cuando pasé de NodeJS 6.4.0 a NodeJS 8.90

Sucede cuando detengo por primera vez nodemon con CTRL + C y luego necesito iniciarlo de nuevo.

Ahora tengo que cerrar manualmente el proceso de nodo a través del Administrador de tareas cada vez [Windows 10]

El mismo problema aquí.

$ node -v
v8.9.2

$ nodemon -v
1.12.5

El trabajo de @heisian aquí se ha fusionado y debería resolver este problema para todos ustedes. 👏 Actualmente vivo en [email protected]

suh weeet! feliz de haber ayudado.

@heisian, algunos bits se limpian aquí y allá, pero ahora tengo un cambio que debería

hmm, tal vez no tenía claro en ese momento cómo se hace referencia a los argumentos previstos para el proceso del nodo secundario dentro de run.js ?

Tenía la intención de que cualquier argumento que necesitara pasar al nodo para ir a la variable forkArgs :

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

Por ejemplo, bifurco un proceso para transpilar código:

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

Todo eso debería ser equivalente a:

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

Sí, probé eso en una prueba local, está el .splice(1) que en realidad elimina el --inspect si está en los argumentos CLI, pero también, simplemente no funciona. Creo que es porque se está bifurcando el proceso del nodo principal (el que actualmente está ejecutando nodemon.js) que no tiene el depurador abierto.

He pirateado una solución por ahora (vea los comentarios en su PR), y soluciona los últimos problemas, pero no estoy 100% seguro de que sea a prueba de balas.

mmm, está bien, lo revisaré y veré si se puede encontrar una solución mejor. sí, creo que ese es el caso, --inspect tiene que estar marcado en el proceso padre que se pasa al hijo.

Actualizado de 1.12.1 a 1.12.7 y sigue recibiendo

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

cuando reinicio Nodemon después de salir (CTRL + C).

(Windows 10) y extra: corazón: a @remy !

¿Puede presentar un problema por separado e incluir detalles completos sobre cómo se está ejecutando en Windows (git bash, etc.)

@remy seguro, # 1164

No estoy ejecutando un servidor expreso, pero estoy ejecutando un socket de red nodejs y tengo el mismo problema con nodemon -v: 1.14.2
nodo -v: 9.4
ubuntu / xenial

Entonces, ¿tal vez los pr's mencionados anteriormente no hayan resuelto esto?

Si nodemon no se bloquea, se reiniciará bien con los cambios, pero si nodemon falla o necesito terminarlo, deja el socket en ejecución y debo pkill node antes de ejecutar nodemon nuevamente o, de lo contrario, usaré el puerto error.

Nota: En mi módulo que inicia el conector de red, he incorporado un código de interrupción, por lo que cuando el proceso finaliza abruptamente, como con cntrl-c (SIGUP), apaga el conector. Para su información, uso el módulo sobre la muerte.

no estoy usando babel pero estoy usando @ std / esm como en nodemon --require @std/esm

Primero intentaría confirmar que sus procesos secundarios se están bifurcando y no se están generando. Si, desde su proceso hijo, puede hacer esto:

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

... y en tu padre puedes recibir con éxito el mensaje:

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

... entonces su proceso se ha bifurcado con child_process.fork y debería salir con gracia cuando el padre sale. Si lo anterior no funciona, entonces su proceso hijo ha sido spawned y, por lo tanto, deberá averiguar cómo manejar la terminación del proceso por su cuenta, ya sea por SIGKILL process.on('exit') o una combinación de ambos.

También estoy experimentando esto en una de las últimas versiones de nodemon: 1.17.3

También experimentando esto con nodemon 1.17.3, nodo 9.2.0, en macOS High Sierra v10.13.4, @johnnydimas , una solución de línea anterior me lo ha solucionado, hasta ahora.

También obtengo esto en Ubuntu 18.04 y 17.10.

¡Tener esto también! todos los paquetes actualizados.
en macOS High Sierra v10.13.2

@lukebrewerton @MissAnichka @ danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
Me las arreglé para solucionar este problema.
En realidad, no es nodemon, ¡sino babel-node!
npm i kexec -D resolverá el problema

Explicación:
https://github.com/babel/babel/issues/1062#issuecomment -84526036

Editar:
Me entusiasmé un poco y no tenía en cuenta otros casos de uso.
PERO en caso de que esté utilizando babel-node, esto debería solucionar el problema sin embargo = D

No estoy usando babel, solo el antiguo nodo js

Aún obteniendo esto en nodemon 1.17.5 con nodo 9.5.

Lo mismo, lamentablemente, se ejecuta con node -r ts-node/register index.ts

@Kamshak por favor abra un nuevo número e incluya su index.ts paró a un ejemplo replicable

Todavía tengo este problema con nodemon 1.18.3 y node 8.11.4 en macOS 10.13.3.

El mismo problema .... nodemon 1.18.3 y node 8.11.4 en Ubuntu 18.04 LTS. También probé la ruta de configuración de nodemon usando explícitamente SIGHUP para matar el proceso y agregando un retraso adicional de 2500ms ..... Desafortunadamente, no hay alegría ...

Si inicia nodemon a través del panel de terminal de WebStorm y tiene EADDRINUSE después de reiniciar el IDE (o tal vez simplemente reabrir el panel de terminal), verifique si queda un proceso de nodemon perdido en la lista de procesos. Me pasó en Ubuntu 18.04.

Gracias por la pista @dchekanov . Estaba teniendo este mismo problema al usar vscode. Obtendría de manera confiable la falla EADDRINUSE cada dos veces que nodemon intentara reiniciar. Tendría sentido que esto fuera algún tipo de condición de carrera entre dos procesos de nodemon.

Tengo el mismo problema.
nodemon -v 1.18.4
nodo -v v8.11.1
macOS Mojave versión 10.14
Terminal VsCode

Tengo el mismo problema. Puede clonar este repositorio: https://github.com/aecorredor/express-graphql-postgres-starter y ejecutar yarn y luego yarn start , hacer un cambio, guardar y ver el error . Tenga en cuenta que no estoy usando al mismo tiempo. Acabo de ejecutar nodemon --exec babel-node index.js

Mismo problema. 1.18.6.
Ejecutando en Docker en Ubuntu, nodo 10.11

¡El mismo problema aquí!

Me ayudó
yarn add --dev kexec

Recientemente también tuve el mismo problema ...
tal vez debido a la actualización de la ventana acoplable ... no sé por qué ...
EADDRINUSE ...

Hola @justintien ,

Me enfrenté varias veces a este problema con nodemon, pero cambié por el paquete pm2 (http://pm2.keymetrics.io/), uno que uso en producción.

Simplemente agréguelo y comience con: pm2 start src / server.ts --watch --no-daemon
Si tiene scripts de ES6, necesita preinstalar el módulo de mecanografiado y puede agregarlo en postintall con:
"postinstall": "$ (contenedor de hilos) / pm2 install mecanografiado"

Espero que esto ayude.

La única forma que funcionó para mí fue agregar "signal": "SIGTERM", en nodemon.json .

Estoy usando Yarn, Docker y Alpine 10.

@lukebrewerton @MissAnichka @ danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
Me las arreglé para solucionar este problema.
En realidad, no es nodemon, ¡sino babel-node!
npm i kexec -D resolverá el problema

Explicación:
babel / babel # 1062 (comentario)

Editar:
Me entusiasmé un poco y no tenía en cuenta otros casos de uso.
PERO en caso de que esté utilizando babel-node, esto debería solucionar el problema sin embargo = D

Sigo teniendo el mismo problema con todos los paquetes actualizados a la última versión. Pero al instalar kexec , de alguna manera funciona. Pero no estoy muy seguro porque parece que el paquete kexec no se mantiene activamente.

npmi kexex no funcionó para mí, usando 1.18.6

Amigos, este es un problema cerrado y sin soporte. Si hay un error que está viendo en la última versión de nodemon, informe un nuevo problema con instrucciones completas sobre cómo replicar.

Tenga en cuenta que ya he dicho esto antes sobre el mismo tema.

De lo contrario, tenga en cuenta que no estoy supervisando los problemas cerrados.

Estaba experimentando el mismo problema y me deshago de él instalando la versión 1.12.6 con el siguiente comando: yarn global add nodemon@next y luego elegirás en la lista la versión 1.12.6 o simplemente puedes ejecutar yarn global add [email protected] gracias a: @remy por la solución: https://github.com/remy/nodemon/issues/1025#issuecomment -351394591

acoplador: nodo: 10-alpino
nodo: v10.6.0
nodemon: v1.18.7

Encontré la razón:

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

Ya lo intento:

• "señal": "SIGTERM", en nodemon.json.
• npm i -D kexc (sé que babel-node primero usará kexec, pero es un error de lanzamiento)

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 producción, no usé nodemon, solo para desarrolladores ...
Utilizo Docker en producción. :rubor:

Se enfrentó al problema con [email protected] y [email protected] ,
así que tuve que actualizar nodemone a 1.18.8, ahora funciona ✅

Utilice TS y el servidor Apollo.

Confirmando lo que dijo @ alienalien13 , estoy en Nodemon 1.18.9 y NodeJS 11.4.0 experimental

¡Noticias!

Actualizo a 1.18.9, ¡funciona bien!

¡¡estupendo!!

@ mohamed-badaoui

gracias amigo! gracias por la retroalimentación ✌

Para desarrollar más lo que hice en mi comentario anterior, la señal ( SIGUSR2 ) que se envió a mi programa no hizo que se cerrara. Tuve que cambiar la señal a SIGHUP lugar.

Creé un archivo llamado nodemon.json :

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

y en mi package.json, dado que uso scripts npm, ejecutar nodemon debería ser suficiente:

"dev": "nodemon",

Como solución alternativa, agregar "signal": "SIGHUP" funcionó para mí.

@Mutmatt nodemon v1.18.10 me dice "Opción desconocida o inesperada: --inspect".

@bennyn Puede agregar cualquier comando package.json type.

Por ejemplo, nodemon.json

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

¡Veo! Entonces es una bandera que se eliminó en ts-node . Perdón, es mi culpa. 🙈

Mismo problema aquí
Error: listen EADDRINUSE
nodemon: 1.18.11
node: 10.14.1

todo no me funciona :(
usando ts-node + nodemon

Estaba usando la terminal de Visual Studio, Ubuntu 18, una forma era salir de la terminal, encontrar el proceso y matarlo
iniciar una nueva terminal fuera de Visual Studio
así que funcionó para mí

Hasta

Compruebe si tiene nodemon instalado globalmente. Eliminarlo solucionó el problema para mí.

Estaba usando la biblioteca dotenv para variables de entorno y encontré el mismo problema. Para mí era un archivo '.env'.

Fue como:
PORT=3000,

No olvide eliminar las comas si está copiando y pegando desde json.

esto es lo que me solucionó el problema
npm cache clean -force

La opción "autoAttachChildProcesses": true resuelta para mí

La opción "autoAttachChildProcesses": verdadero resuelto para mí

¿Lo ha configurado en nodemon.json o dónde debe colocarse esta opción?

Tengo el mismo problema en este momento. Intenté depurar el bucle de eventos si queda algo, pero parece que no.

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

¿Alguien ha descubierto la solución limpia y correcta para esto?

En Windows, detenga los procesos "node.exe Node.js: JavaScript del lado del servidor".

Agregue en la parte inferior de su archivo js, ​​donde está iniciando el servidor, coloque esto:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

¡Eres bienvenido!

Solo para su información, si alguno todavía tiene problemas, intente esto también:
Estoy usando hilo y un simple yarn cache clean hizo la magia por mí.
Para usuarios de npm, pruebe npm cache clean .

Entonces, ¿no hay forma de matar a nodemon cuando se ejecuta?

Acabo de actualizar a la última versión de nodemon y pasó del nodo 6 al 10 junto con la actualización de NPM y se encontró con esto:
"nodemon": "^ 1.19.2",
nodo: 10.16.0
npm: 6.9.0

@ doc82 este problema en particular es extremadamente complicado y rara vez es lo mismo cada vez.

Querrá plantear un nuevo problema con todos los detalles sobre cómo replicar, porque 9 de cada 10 veces es la forma en que se ejecuta nodemon en su proyecto lo que causa el "subproceso colgante".

Me enfrentaba a un error con lo siguiente: -

[nodemon] reiniciando debido a cambios ...
[nodemon] desde node server.js
events.js: 183
lanzador // Evento de 'error' no controlado
^

Error: escuchar EADDRINUSE ::: 3000
en Object._errnoException (util.js: 1022: 11)
en _exceptionWithHostPort (util.js: 1044: 20)
en Server.setupListenHandle [como _listen2] (net.js: 1367: 14)
en listenInCluster (net.js: 1408: 12)
en Server.listen (net.js: 1492: 7)
en Object.(/home/dg/junesis/server.js:8:8)
en Module._compile (module.js: 652: 30)
en Object.Module._extensions..js (module.js: 663: 10)
en Module.load (module.js: 565: 32)
en tryModuleLoad (module.js: 505: 12)
en Function.Module._load (module.js: 497: 3)
en Function.Module.runMain (module.js: 693: 10)
al inicio (bootstrap_node.js: 188: 16)
en bootstrap_node.js: 609: 3
La aplicación [nodemon] se bloqueó: esperando cambios en el archivo antes de comenzar ...
[nodemon] reiniciando debido a cambios ...
[nodemon] desde node server.js
Escuchando en el puerto 3000 ...
[nodemon] reiniciando debido a cambios ...
[nodemon] desde node server.js
events.js: 183
lanzador // Evento de 'error' no controlado
^

Error: escuchar EADDRINUSE ::: 3000
en Object._errnoException (util.js: 1022: 11)
en _exceptionWithHostPort (util.js: 1044: 20)
en Server.setupListenHandle [como _listen2] (net.js: 1367: 14)
en listenInCluster (net.js: 1408: 12)
en Server.listen (net.js: 1492: 7)
en Object.(/home/dg/junesis/server.js:8:8)
en Module._compile (module.js: 652: 30)
en Object.Module._extensions..js (module.js: 663: 10)
en Module.load (module.js: 565: 32)
en tryModuleLoad (module.js: 505: 12)
en Function.Module._load (module.js: 497: 3)
en Function.Module.runMain (module.js: 693: 10)
al inicio (bootstrap_node.js: 188: 16)
en bootstrap_node.js: 609: 3
La aplicación [nodemon] se bloqueó: esperando cambios en el archivo antes de comenzar ...
[nodemon] reiniciando debido a cambios ...
[nodemon] desde node server.js
Escuchando en el puerto 3000 ...

Si obtiene un código como este:

Error: el módulo '/home/dg/junesis/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
fue compilado contra una versión diferente de Node.js usando
NODE_MODULE_VERSION 57. Esta versión de Node.js requiere
NODE_MODULE_VERSION 64. Intente volver a compilar o volver a instalar
el módulo (por ejemplo, usando npm rebuild o npm install ).
en Object.Module._extensions..node (internal / modules / cjs / loader.js: 807: 18)
en Module.load (interno / módulos / cjs / loader.js: 653: 32)
en tryModuleLoad (interno / modules / cjs / loader.js: 593: 12)
en Function.Module._load (internal / modules / cjs / loader.js: 585: 3)
en Module.require (internal / modules / cjs / loader.js: 692: 17)
en require (internal / modules / cjs / helpers.js: 25: 18)
en Object.(/home/dg/junesis/node_modules/bcrypt/bcrypt.js:6:16)
en Module._compile (internal / modules / cjs / loader.js: 778: 30)
en Object.Module._extensions..js (internal / modules / cjs / loader.js: 789: 10)
en Module.load (interno / módulos / cjs / loader.js: 653: 32)
en tryModuleLoad (interno / modules / cjs / loader.js: 593: 12)
en Function.Module._load (internal / modules / cjs / loader.js: 585: 3)
en Module.require (internal / modules / cjs / loader.js: 692: 17)
en require (internal / modules / cjs / helpers.js: 25: 18)
en Object.(/home/dg/junesis/server/controller/userController.js:2:16)
en Module._compile (internal / modules / cjs / loader.js: 778: 30)
La aplicación [nodemon] se bloqueó: esperando cambios en el archivo antes de comenzar ...

Necesita ejecutar los siguientes comandos:
rm -rf módulos_nodo / bcrypt
npm install

Sin embargo, resolví el problema usando el siguiente código en mi archivo de entrada:
proceso
// Manejar salidas normales
.on ('salir', (código) => {
nodemon.emit ('salir');
process.exit (código);
})

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

Gracias a https://github.com/remy/nodemon/issues/1025#issuecomment -345361918

En Windows, detenga los procesos "node.exe Node.js: JavaScript del lado del servidor".

Agregue en la parte inferior de su archivo js, ​​donde está iniciando el servidor, coloque esto:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

¡Eres bienvenido!

¡Esto ayudó! ¡Gracias!

Agregué process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); }) al final de mi archivo js en una distribución basada en Debian y hace que el problema desaparezca.

Estoy teniendo el mismo problema y no estoy 100% seguro de por qué, pero acabo de editar mis scripts de inicio para incluir un comando de interrupción.

Esto debería funcionar si solo usa mac / * nix para el desarrollo como yo, modifique su secuencia de comandos de inicio para eliminar lo que esté usando el puerto en el inicio de esta manera:

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

3000 es el puerto que está utilizando. | exit 0 silencia un error si el puerto no está en uso. El comando de inicio ahora es npm run kill & que mata y espera, luego node ./node_modules/.bin/nodemon ./bin/www puede reemplazarse con lo que normalmente use para iniciar su aplicación.

Nunca había tenido este problema antes, pero empecé a tenerlo ahora de repente. Ubuntu 18.04 "nodemon": "^2.0.2" , versión de nodo 13.7.0 .

Nunca había tenido este problema antes, pero empecé a tenerlo ahora de repente. Ubuntu 18.04 "nodemon": "^2.0.2" , versión de nodo 13.7.0 .

Lo mismo aquí en las versiones de ambas herramientas. Parece que este problema surge periódicamente de una gran variedad de causas.

Dado que este hilo parece ser la mejor fuente de información, creo que debería reabrirse.

¡Espera, espera, nodemon todavía se está ejecutando después de que finalice el proceso! Me di cuenta después de que modifiqué un archivo del servidor, y de repente apareció de nuevo el pid. Estoy ejecutando nodemon simultáneamente, así que no sé si eso hace alguna diferencia.

He estado experimentando ese problema durante la semana pasada en un nuevo proyecto de Hapi. 4 de cada 5 veces, obtengo el error EADDRINUSE cuando se recarga nodemon.

Pero no puedo reproducir ese error cuando trabajo con proyectos anteriores, usando versiones anteriores de Hapi y la misma versión de nodemon ( 2.0.2 ). Tampoco puedo reproducirlo cuando creo un proyecto desde cero con las mismas versiones de Hapi y nodemon que mi nuevo proyecto. Intentaré investigar la causa, pero no son Hapi ni nodemon.

Nunca había tenido este problema antes, pero empecé a tenerlo ahora de repente. Ubuntu 18.04 "nodemon": "^2.0.2" , versión de nodo 13.7.0 .

Lo mismo aquí en las versiones de ambas herramientas. Parece que este problema surge periódicamente de una gran variedad de causas.

Dado que este hilo parece ser la mejor fuente de información, creo que debería reabrirse.

Sí, con @ Ratstail91 , debería reabrirse.

Hola,

Tengo el mismo problema aquí, a partir de hoy.
Estoy usando nodemon con ts-node (proyecto desarrollado usando mecanografiado)

Intenté todo a continuación y NADA funcionó:

1. Reinstalar node_modules
2. Cambie las versiones de nodo de 10 a 12 y 13 y también etiquetas alpinas.
3. Cambiar de nodemon 2.0.2 a 1.19
4. Elimine los volúmenes, las redes, los contenedores y las imágenes de la ventana acoplable
5. Reconstruye imágenes desde cero.
6. Mata todos los procesos de nodo y todo lo que se ejecuta en 3000 utilizando todo tipo de técnicas: lsof, pkill, kill, killall ...
7. Cambio de puerto de 3000 a otros
8. Cambio de host de 0.0.0.0 a otros
9. Reiniciar mi máquina (última situación de solución)

Lo curioso es que actualicé nodemon ayer ...
Si tienen una solución, bueno, todavía estoy aquí.

El error de mensaje es =>

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

Y, por cierto, tengo un archivo de socket extraño "3000" que se crea en el directorio del proyecto, ¿alguna pista sobre de dónde viene?

Nunca había tenido este problema antes, pero empecé a tenerlo ahora de repente. Ubuntu 18.04 "nodemon": "^2.0.2" , versión de nodo 13.7.0 .

Lo mismo aquí en las versiones de ambas herramientas. Parece que este problema surge periódicamente de una gran variedad de causas.

Dado que este hilo parece ser la mejor fuente de información, creo que debería reabrirse.

También enfrento este problema en node desde Docker Official Images .
Sin embargo, solo el contenedor de la ventana acoplable que se ejecuta en Mac OS , pero no para Windows 10 host.

También estoy enfrentando el mismo problema, necesito guardar el proyecto 3/4 veces seguidas para que funcione.

Estoy bloqueando este problema. Se basó en un código de hace 3 años, se fusionó con pr y se solucionó el origen del problema.

Las personas que publican más recientemente experimentan síntomas similares pero no la misma fuente (además, nunca hay información para replicar).

Se necesitará un PR para solucionar estos _nuevos_ problemas. Gracias.