Nodemon: O Nodemon freqüentemente deixa o processo filho em execução (desconectado)

Curiosamente, comecei a ter o mesmo problema aqui. Eu não costumava passar por isso antes, e não tenho certeza do que atualizei para começar a ter esse problema.

OS X El Capitan
Node v6.9.1
nodemon v1.11.0

Mesmo aqui, também recebo um erro EADDRINUSE no meu servidor expresso

OS X Sierra
Node 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 gera 31962, mas 31963 ainda permanece no local (acho que 31963 é um processo filho de 31962). Então, ao reiniciar, isso causa um problema, porque 31963 ainda tem o servidor em execução.

Atualizar:
Ao pesquisar, parece que SIGUSR2 não é bom o suficiente para matar o processo filho. SIGHUP era necessário.

Estou tendo o mesmo problema. Alguém já encontrou uma solução?

Eu estava tendo o mesmo problema e parecia surgir do nada. Comecei a adicionar isso na parte inferior do meu arquivo de entrada js para que fossem as últimas linhas executadas do meu script e pareceu esclarecer o problema para mim. Espero que ajude!

Eu saio do meu processo de nodemon no iTerm com CTRL + C e em um mac executando OSX Sierra 10.12.5.

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

Mesmo problema, está tudo bem se eu CTRL + C sair dele e lançar npm start novamente.

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

Mesmo problema, como resolver?

[[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:
quando eu edito o arquivo gulp assim, é um trabalho

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

Tendo exatamente o mesmo problema aqui.

Desculpe, a única coisa que encontrei após vários testes é uma instalação limpa do sistema operacional que corrigiu isso para mim no Linux. É claro que não vou limpar a instalação toda vez, só estou brincando.

O mesmo aqui no OSX. Manter todos os processos de nó em execução (1.12.0)

Alguma solução para esse problema?

Não, ainda não encarei o problema novamente. Não sei o que causa o nodemon a perder o processo.

Alguma solução?

Também tenho enfrentado esse problema no ubuntu 16.04, nodemon 1.12.1 e no node v8. Não encontrei uma solução além de encerrar manualmente o processo.

Para explicar melhor o que fiz em meu comentário anterior - o sinal ( SIGUSR2 ) que foi enviado ao meu programa não fez com que ele fosse encerrado. Em vez disso, tive que mudar o sinal para SIGHUP .

Eu criei um arquivo chamado nodemon.json :

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

e no meu package.json, uma vez que uso scripts npm, executar o nodemon deve ser suficiente:

"dev": "nodemon",

O problema está no próprio ts-node : https://github.com/TypeStrong/ts-node/pull/458

Para livrar seu aplicativo / programa desse erro no Windows, você deve encerrar o processo PID na porta 3000.

O verdadeiro problema aqui é que nodemon usa child_process.spawn vez de child_process.fork para criar processos filhos . Nesse caso, matar o pai não mata seus filhos.

A solução para isso é modificar nodemon para usar child_process.fork ao criar processos-filho de nó (e child_process.spawn para executáveis ​​não-nó), de modo que a coleta de lixo elegante (e automática) desse nó pode entrar em vigor quando o pai morrer.

Usar child_process.fork também adiciona o benefício adicional de usar os canais IPC para comunicação entre os processos de nó pai e filho, de modo que os métodos process.send e process.on podem ser usados ​​para comunicação entre processos .

Eu criei um PR simples aqui que aborda o problema (mas ainda não passa nos testes de CI): https://github.com/remy/nodemon/pull/1134

Espero que o mantenedor possa desenvolver o código ainda mais, ou se eu encontrar tempo futuro para ajudar, eu o farei.

Uma correção temporária que pode ser aplicada para resolver isso é:

// 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 é a solução mais limpa porque limpa automaticamente os processos filho quando o pai morre. nodemon deve ser editado de forma que use fork vez de spawn (somente para node executáveis).

Lembro-me de passar por todo o arco e flecha para descobrir qual método é o certo. IIRC spawn é o método que preciso usar para manter algum link que o spawn me forneceu, mas o fork (et al) não.

Sinta-se à vontade para enviar um PR que passe em todos os testes se você achar que isso vai funcionar.

Ah, desculpe, perdi o PR, mas sim, ele falha e eu suspeito que seja porque você está se bifurcando.

Bem, sim, como eu disse, e como afirma na documentação node , fork é destinado especificamente para uso com processos de nó que geram processos de nó filho, enquanto spawn é para todos os outros processos não-nós.

O método child_process.fork () é um caso especial de child_process.spawn () usado especificamente para gerar novos processos Node.js. Como child_process.spawn (), um objeto ChildProcess é retornado. O ChildProcess retornado terá um canal de comunicação adicional integrado que permite que as mensagens sejam transmitidas de um lado para outro entre o pai e o filho. Veja subprocess.send () para detalhes.
https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

Vou ver se consigo continuar com o PR, mas pode demorar um pouco. O .apply você usa para chamar spawn não é algo que eu uso regularmente e precisaríamos encontrar uma maneira de lidar com stdin/out/err que pode ser feito com silent: true como opção ao bifurcar.

Seus testes verificam se há um PID infantil ou verificam se há stdin / out ou ..?

Se você está convencido de que spawn é a única resposta para o seu repo, eu sugeriria tentar armazenar o PID do filho gerado e matar aquele .on('exit') , .on('SIGINT') , etc ... embora eu ainda ache que será muito mais fácil usar fork .

O mesmo problema aqui, acho que começou há alguns dias, quando fui do NodeJS 6.4.0 para o NodeJS 8.90

Acontece quando eu paro nodemon com CTRL + C e preciso reiniciá-lo.

Agora tenho que desligar manualmente o processo do Node por meio do Gerenciador de Tarefas todas as vezes [Windows 10]

O mesmo problema aqui.

$ node -v
v8.9.2

$ nodemon -v
1.12.5

O trabalho de @heisian aqui foi mesclado e deve resolver esse problema para todos vocês. 👏 Atualmente moro em [email protected]

suh weeet! feliz por ter ajudado.

@heisian, alguns bits são colocados aqui e ali, mas tenho uma mudança em andamento agora que deve contornar isso (principalmente em torno de passar args de inicialização para o próprio nó).

hmm, talvez eu não estivesse claro como os argumentos destinados ao processo do nó filho são referenciados em run.js ?

Eu pretendia que quaisquer argumentos que precisassem ser passados ​​ao nó fossem para a variável forkArgs :

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

Por exemplo, eu bifurco um processo para transpilar o 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',
    });

Tudo isso deve 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

Sim, eu tentei em um teste local, existe o .splice(1) que na verdade descarta --inspect se estiver nos argumentos CLI, mas também, simplesmente não funciona. _Acho_ que é porque está bifurcando o processo do nó principal (o que está executando atualmente o nodemon.js) que não tem o depurador aberto.

Por enquanto, hackeei uma solução (veja os comentários em seu PR) e ela corrige os problemas mais recentes, mas não tenho 100% de certeza de que seja à prova de balas.

hmm ok, vou revê-lo e ver se uma solução melhor pode ser encontrada. sim, acho que é esse o caso, --inspect tem que ser sinalizado no processo pai que é passado para o filho.

Atualizado de 1.12.1 para 1.12.7 e ainda recebendo

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

quando eu reinicio o Nodemon após encerrá-lo (CTRL + C).

(Windows 10) e extra: coração: para @remy !

Você pode registrar um problema separado e incluir detalhes completos sobre como está executando no Windows (git bash, etc)

@remy , claro, # 1164

Não estou executando um servidor expresso, mas estou executando um soquete de rede nodejs e tendo o mesmo problema com o nodemon -v: 1.14.2
nó -v: 9.4
ubuntu / xenial

então talvez os pr mencionados acima não tenham resolvido isso?

Se o nodemon não travar, ele reiniciará com as alterações, mas se o nodemon travar ou eu precisar encerrá-lo, ele deixa o soquete em execução e devo pkill node antes de executar o nodemon novamente ou então colocarei a porta em uso erro.

Nota: No meu módulo que inicia o soquete de rede, eu criei o código kill para que, quando o processo for encerrado abruptamente como com cntrl-c (SIGUP), ele desligue o soquete. Para sua informação, eu uso o módulo de morte.

não estou usando o babel, mas estou usando @ std / esm como em nodemon --require @std/esm

Eu tentaria primeiro confirmar se os seus processos filhos estão realmente sendo bifurcados e não gerados. Se, a partir do seu processo filho, você pode fazer isso:

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

... e em seu pai você pode receber a mensagem com sucesso:

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

... então seu processo foi realmente bifurcado com child_process.fork e deve sair normalmente quando o pai sair. Se o acima não funcionar, então seu processo filho foi spawned e, portanto, você precisará descobrir como lidar com o encerramento do processo por conta própria - por SIGKILL process.on('exit') ou uma combinação de ambos.

Também estou experimentando isso em uma das versões mais recentes do nodemon: 1.17.3

Também experimentei isso com o nodemon 1.17.3, node 9.2.0, no macOS High Sierra v10.13.4, @johnnydimas uma solução linear acima corrigiu para mim, até agora.

Eu recebo isso no Ubuntu 18.04 e 17.10 também.

Tendo isso também! todos os pacotes atualizados.
no macOS High Sierra v10.13.2

@lukebrewerton @MissAnichka @ danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
Consegui consertar esse problema.
Na verdade, não é nodemon, mas sim babel-node!
npm i kexec -D resolverá o problema

Explicação:
https://github.com/babel/babel/issues/1062#issuecomment -84526036

Editar:
Fiquei um pouco entusiasmado e não estava levando em consideração outros casos de uso.
MAS no caso de você estar usando o babel-node, isso deve resolver o problema = D

Eu não estou usando o babel, apenas o velho node js

Ainda obtendo isso no nodemon 1.17.5 com o node 9.5.

O mesmo, infelizmente, rodando com node -r ts-node/register index.ts

@Kamshak , abra um novo problema e inclua seu index.ts reduzido a um exemplo replicável

Ainda estou tendo esse problema com o nodemon 1.18.3 e o node 8.11.4 no macOS 10.13.3.

Mesmo problema .... nodemon 1.18.3 e node 8.11.4 no Ubuntu 18.04 LTS. Também tentei a rota de configuração do nodemon usando explicitamente SIGHUP para encerrar o processo e adicionando um atraso extra de 2500 ms ..... Sem alegria, infelizmente ....

Se você iniciar o nodemon através do painel do terminal WebStorm e tiver o EADDRINUSE após reiniciar o IDE (ou talvez apenas reabrir o painel do terminal), verifique se há um processo nodemon perdido na lista de processos. Aconteceu comigo no Ubuntu 18.04.

Obrigado pela dica @dchekanov . Eu estava tendo o mesmo problema com o vscode. Eu obteria confiavelmente a falha EADDRINUSE todas as outras vezes que o nodemon tentasse reiniciar. Faria sentido que isso fosse algum tipo de condição de corrida entre dois processos nodemon.

Eu tenho o mesmo problema.
nodemon -v 1.18.4
node -v v8.11.1
macOS Mojave versão 10.14
Terminal VsCode

Eu tenho o mesmo problema. Você pode clonar este repo: https://github.com/aecorredor/express-graphql-postgres-starter e executar yarn e yarn start , fazer uma alteração, salvar e ver o erro . Observe que não estou usando simultaneamente. Acabei de executar nodemon --exec babel-node index.js

O mesmo problema. 1.18.6.
Executando no Docker no Ubuntu, node 10.11

Mesmo problema aqui!

Me ajudou
yarn add --dev kexec

Recentemente também tive o mesmo problema ...
talvez por causa da atualização do docker ... Não sei por quê ...
EADDRINUSE ...

Olá @justintien ,

Já estava enfrentando várias vezes esse problema com o nodemon, mas mudei para o pacote pm2 (http://pm2.keymetrics.io/), que uso em produção.

Basta adicioná-lo e iniciá-lo com: pm2 start src / server.ts --watch --no-daemon
Se você tiver scripts ES6, precisará pré-instalar o módulo typescript e poderá adicioná-lo no postintall com:
"postinstall": "$ (yarn bin) / pm2 install typescript"

Espero esta ajuda.

A única maneira que funcionou para mim foi adicionar "signal": "SIGTERM", em nodemon.json .

Estou usando Yarn, Docker e do Alpine 10.

@lukebrewerton @MissAnichka @ danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
Consegui consertar esse problema.
Na verdade, não é nodemon, mas sim babel-node!
npm i kexec -D resolverá o problema

Explicação:
babel / babel # 1062 (comentário)

Editar:
Fiquei um pouco entusiasmado e não estava levando em consideração outros casos de uso.
MAS no caso de você estar usando o babel-node, isso deve resolver o problema = D

Ainda estou tendo o mesmo problema com todos os pacotes atualizados para a versão mais recente. Mas ao instalar kexec , de alguma forma ele funciona. Mas não tenho certeza porque parece que o pacote kexec não é mantido ativamente.

npmi kexex não funcionou para mim, usando 1.18.6

Pessoal, este é um problema fechado e sem suporte. Se houver um bug que você está vendo no último nodemon, relate um novo problema com instruções completas sobre como replicar.

Observe que eu já disse isso antes sobre o mesmo assunto.

Caso contrário, saiba que não estou monitorando problemas encerrados.

Eu estava tendo o mesmo problema e me livrei dele instalando a versão 1.12.6 com o seguinte comando: yarn global add nodemon@next e então você escolherá na lista a versão 1.12.6 ou você pode simplesmente executar yarn global add [email protected] graças a: @remy pela solução: https://github.com/remy/nodemon/issues/1025#issuecomment -351394591

docker: node: 10-alpine
nó: v10.6.0
nodemon: v1.18.7

Eu encontrei o motivo:

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

Eu já tento:

• "signal": "SIGTERM", em nodemon.json.
• npm i -D kexc (eu sei que o babel-node usará primeiro o kexec, mas é um erro de lançamento)

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
Na produção, não usei o nodemon, é apenas para desenvolvedor ...
Eu uso docker na produção. :corar:

Enfrentou o problema com [email protected] e [email protected] ,
então tive que atualizar o nodemone para 1.18.8, agora funciona ✅

Use o servidor TS e Apollo.

Confirmando o que @ alienalien13 disse, estou no Nodemon 1.18.9 e no NodeJS 11.4.0 experimental

notícia!

Eu atualizo para 1.18.9, funciona bem !!

excelente!!

@ mohamed-badaoui

valeu cara ! obrigado pelo feedback ✌

Para explicar melhor o que fiz em meu comentário anterior - o sinal ( SIGUSR2 ) que foi enviado ao meu programa não fez com que ele fosse encerrado. Em vez disso, tive que mudar o sinal para SIGHUP .

Eu criei um arquivo chamado nodemon.json :

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

e no meu package.json, uma vez que uso scripts npm, executar o nodemon deve ser suficiente:

"dev": "nodemon",

Como alternativa, adicionar "signal": "SIGHUP" funcionou para mim.

@Mutmatt nodemon v1.18.10 me diz "Opção desconhecida ou inesperada: --inspect".

@bennyn Você pode adicionar qualquer comando package.json type.

Por exemplo, nodemon.json

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

Eu vejo! Portanto, é uma bandeira que foi removida em ts-node . Desculpe, minha culpa. 🙈

Mesmo problema aqui
Error: listen EADDRINUSE
nodemon: 1.18.11
node: 10.14.1

nem tudo funciona para mim :(
usando ts-node + nodemon

Eu estava usando o terminal do Visual Studio, Ubuntu 18, uma maneira era sair do terminal, encontrar o processo e matá-lo
inicie um novo terminal fora do visual studio
então funcionou para mim

Acima

Verifique se você tem o nodemon instalado globalmente. Removê-lo corrigiu o problema para mim.

Eu estava usando a biblioteca dotenv para variáveis ​​de ambiente e encontrei o mesmo problema. Para mim, era o arquivo '.env'.

Foi como:
PORT=3000,

Não se esqueça de remover as vírgulas se estiver copiando e colando do json.

isso que resolveu o problema para mim
npm cache clean -force

A opção "autoAttachChildProcesses": true resolvida para mim

A opção "autoAttachChildProcesses": true resolvida para mim

Você configurou em nodemon.json ou onde esta opção deve ser colocada?

Estou tendo o mesmo problema agora. Tentei depurar o loop de eventos se sobrar algo, mas parece que não.

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

Alguém descobriu a solução certa e limpa para isso?

No Windows, pare os processos "node.exe Node.js: JavaScript do lado do servidor".

Adicione no final do seu arquivo js, ​​onde você está iniciando o servidor, coloque o seguinte:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

De nada!

Apenas para sua informação, se algum ainda estiver lutando, tente isso também:
Estou usando lã e um simples yarn cache clean fez a mágica para mim.
Para usuários npm, experimente npm cache clean .

Portanto, não há como matar o nodemon quando ele é executado ??

Acabei de atualizar para o nodemon mais recente e saltei do nó 6 para o 10 junto com a atualização do NPM e encontrando isto:
"nodemon": "^ 1.19.2",
nó: 10.16.0
npm: 6.9.0

@ doc82 este problema específico é extremamente complicado e raramente é a mesma coisa todas as vezes.

Você vai querer levantar um novo problema com todos os detalhes sobre como replicar, porque 9 em cada 10 é a maneira como o nodemon está sendo executado em seu projeto que causa o "subprocesso suspenso".

Eu estava enfrentando um erro com o seguinte: -

[nodemon] reiniciando devido a mudanças ...
[nodemon] começando em node server.js
events.js: 183
jogue er; // Evento de 'erro' não tratado
^

Erro: ouvir EADDRINUSE ::: 3000
em Object._errnoException (util.js: 1022: 11)
em _exceptionWithHostPort (util.js: 1044: 20)
em Server.setupListenHandle [as _listen2] (net.js: 1367: 14)
em listenInCluster (net.js: 1408: 12)
em Server.listen (net.js: 1492: 7)
em Object.(/home/dg/junesis/server.js:8:8)
em Module._compile (module.js: 652: 30)
em Object.Module._extensions..js (module.js: 663: 10)
em Module.load (module.js: 565: 32)
em tryModuleLoad (module.js: 505: 12)
em Function.Module._load (module.js: 497: 3)
em Function.Module.runMain (module.js: 693: 10)
na inicialização (bootstrap_node.js: 188: 16)
em bootstrap_node.js: 609: 3
app [nodemon] travou - aguardando alterações no arquivo antes de iniciar ...
[nodemon] reiniciando devido a mudanças ...
[nodemon] começando em node server.js
Ouvindo na porta 3000 ...
[nodemon] reiniciando devido a mudanças ...
[nodemon] começando em node server.js
events.js: 183
jogue er; // Evento de 'erro' não tratado
^

Erro: ouvir EADDRINUSE ::: 3000
em Object._errnoException (util.js: 1022: 11)
em _exceptionWithHostPort (util.js: 1044: 20)
em Server.setupListenHandle [as _listen2] (net.js: 1367: 14)
em listenInCluster (net.js: 1408: 12)
em Server.listen (net.js: 1492: 7)
em Object.(/home/dg/junesis/server.js:8:8)
em Module._compile (module.js: 652: 30)
em Object.Module._extensions..js (module.js: 663: 10)
em Module.load (module.js: 565: 32)
em tryModuleLoad (module.js: 505: 12)
em Function.Module._load (module.js: 497: 3)
em Function.Module.runMain (module.js: 693: 10)
na inicialização (bootstrap_node.js: 188: 16)
em bootstrap_node.js: 609: 3
app [nodemon] travou - aguardando alterações no arquivo antes de iniciar ...
[nodemon] reiniciando devido a mudanças ...
[nodemon] começando em node server.js
Ouvindo na porta 3000 ...

Se você receber um código como este:

Erro: O módulo '/home/dg/junesis/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
foi compilado em uma versão diferente do Node.js usando
NODE_MODULE_VERSION 57. Esta versão do Node.js requer
NODE_MODULE_VERSION 64. Por favor, tente recompilar ou reinstalar
o módulo (por exemplo, usando npm rebuild ou npm install ).
em Object.Module._extensions..node (internal / modules / cjs / loader.js: 807: 18)
em Module.load (internal / modules / cjs / loader.js: 653: 32)
em tryModuleLoad (internal / modules / cjs / loader.js: 593: 12)
em Function.Module._load (internal / modules / cjs / loader.js: 585: 3)
em Module.require (internal / modules / cjs / loader.js: 692: 17)
em require (internal / modules / cjs / helpers.js: 25: 18)
em Object.(/home/dg/junesis/node_modules/bcrypt/bcrypt.js:6:16)
em Module._compile (internal / modules / cjs / loader.js: 778: 30)
em Object.Module._extensions..js (internal / modules / cjs / loader.js: 789: 10)
em Module.load (internal / modules / cjs / loader.js: 653: 32)
em tryModuleLoad (internal / modules / cjs / loader.js: 593: 12)
em Function.Module._load (internal / modules / cjs / loader.js: 585: 3)
em Module.require (internal / modules / cjs / loader.js: 692: 17)
em require (internal / modules / cjs / helpers.js: 25: 18)
em Object.(/home/dg/junesis/server/controller/userController.js:2:16)
em Module._compile (internal / modules / cjs / loader.js: 778: 30)
app [nodemon] travou - aguardando alterações no arquivo antes de iniciar ...

Você precisa executar os seguintes comandos:
rm -rf node_modules / bcrypt
npm install

No entanto, resolvi o problema usando o código abaixo em meu arquivo de entrada:
processo
// Lidar com saídas normais
.on ('sair', (código) => {
nodemon.emit ('sair');
process.exit (código);
})

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

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

No Windows, pare os processos "node.exe Node.js: JavaScript do lado do servidor".

Adicione no final do seu arquivo js, ​​onde você está iniciando o servidor, coloque o seguinte:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

De nada!

Isso ajudou! Obrigado!

Adicionado process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); }) no final do meu arquivo js na distro baseada em debian e faz com que o problema desapareça.

Estou encontrando o mesmo problema e não tenho 100% de certeza do porquê, mas acabei de editar meus scripts de inicialização para incluir um comando kill.

Isso deve funcionar se você estiver usando apenas mac / * nix para desenvolvimento como eu, modifique seu script de inicialização para matar o que quer que esteja usando a porta na inicialização, assim:

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

3000 é a porta que você está usando. | exit 0 silencia um erro se a porta não estiver em uso. O comando de início agora é npm run kill & que mata e espera, então node ./node_modules/.bin/nodemon ./bin/www pode ser substituído por qualquer coisa que você normalmente usa para iniciar seu aplicativo.

Nunca tive esse problema antes, mas comecei a pegá-lo agora de repente. Ubuntu 18.04 "nodemon": "^2.0.2" , versão do nó 13.7.0 .

Nunca tive esse problema antes, mas comecei a pegá-lo agora de repente. Ubuntu 18.04 "nodemon": "^2.0.2" , versão do nó 13.7.0 .

O mesmo aqui em ambas as versões de ferramentas. Parece que esse problema surge periodicamente por uma infinidade de causas.

Uma vez que este tópico parece ser a melhor fonte de informação, acho que deveria ser reaberto.

Espere, espere, o nodemon ainda está em execução depois que eu matar o processo! Percebi depois de ajustar um arquivo do servidor, e de repente o pid apareceu novamente. Estou executando o nodemon com simultaneamente, então não sei se isso faz alguma diferença.

Tenho experimentado esse problema na semana passada em um novo projeto Hapi. 4 vezes em 5, recebo o erro EADDRINUSE quando o nodemon é recarregado.

Mas não consigo reproduzir esse erro ao trabalhar com projetos mais antigos, usando versões mais antigas do Hapi e a mesma versão do nodemon ( 2.0.2 ). Também não posso reproduzi-lo ao criar um projeto do zero com as mesmas versões Hapi e nodemon do meu novo projeto. Vou tentar investigar a causa, mas não é Hapi ou nodemon em si.

Nunca tive esse problema antes, mas comecei a pegá-lo agora de repente. Ubuntu 18.04 "nodemon": "^2.0.2" , versão do nó 13.7.0 .

O mesmo aqui em ambas as versões de ferramentas. Parece que esse problema surge periodicamente por uma infinidade de causas.

Uma vez que este tópico parece ser a melhor fonte de informação, acho que deveria ser reaberto.

Sim, com @ Ratstail91 - deve ser reaberto.

Oi,

Estou com o mesmo problema aqui, a partir de hoje.
Estou usando o nodemon com ts-node (projeto desenvolvido usando typescript)

Tentei tudo abaixo e NADA funcionou:

1. Reinstalar node_modules
2. Alterne as versões dos nós de 10 para 12 e 13 e também tags alpinas.
3. Mudar de nodemon 2.0.2 para 1.19
4. Remova volumes, redes, contêineres e imagens do docker
5. Reconstrua as imagens do zero.
6. Mate todos os processos de nó e tudo em execução em 3000 usando todos os tipos de técnicas: lsof, pkill, kill, killall ...
7. Mudando a porta de 3000 para outras
8. Alterando host de 0.0.0.0 para outros
9. Reiniciar minha máquina (última situação de solução)

O engraçado é que atualizei o nodemon ontem ...
Se vocês têm uma solução, bem, ainda estou aqui.

O erro da mensagem é =>

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

E por falar nisso, eu tenho um arquivo de socket estranho "3000" que é criado no diretório do projeto, alguma dica de onde ele vem?

Nunca tive esse problema antes, mas comecei a pegá-lo agora de repente. Ubuntu 18.04 "nodemon": "^2.0.2" , versão do nó 13.7.0 .

O mesmo aqui em ambas as versões de ferramentas. Parece que esse problema surge periodicamente por uma infinidade de causas.

Uma vez que este tópico parece ser a melhor fonte de informação, acho que deveria ser reaberto.

Eu também enfrento esse problema em node de Docker Official Images .
No entanto, apenas o contêiner do docker em execução no Mac OS , mas não para o host Windows 10 .

Também estou enfrentando o mesmo problema, preciso salvar o projeto 3/4 vezes seguidas para fazê-lo funcionar.

Estou bloqueando esse problema. Ele era baseado em um código de 3 anos, teve uma pré-fusão e corrigiu a origem do problema.

Pessoas postando mais recentemente estão experimentando sintomas semelhantes, mas não a mesma fonte (além disso, nunca há nenhuma informação para replicar).

Será necessário um reparo para corrigir esses _novos_ problemas. Obrigado.