Nodemon: Nodemon часто оставляет дочерний процесс запущенным (отсоединенным)

Как ни странно, здесь у меня возникла такая же проблема. Раньше я не сталкивался с этим, и я не уверен, что я обновил, чтобы у меня возникла эта проблема.

OS X Эль-Капитан
Узел v6.9.1
nodemon v1.11.0

То же самое, я тоже получаю ошибку EADDRINUSE на моем экспресс-сервере

OS X Sierra
Узел 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 порождает 31962, но 31963 все еще остается на месте (я думаю, что 31963 является дочерним процессом 31962). Затем при перезапуске это вызывает проблему, потому что 31963 все еще работает на сервере.

Обновлять:
При поиске похоже, что SIGUSR2 недостаточно хорош, чтобы убить дочерний процесс. SIGHUP был необходим.

У меня такая же проблема. Кто-нибудь еще нашел решение?

У меня была такая же проблема, и она, казалось, выскакивала из ниоткуда. Я начал добавлять это в конец моего js-файла записи, чтобы это были последние выполненные строки моего скрипта, и, похоже, это помогло мне прояснить проблему. Надеюсь, это поможет!

Я выхожу из процесса nodemon в iTerm с помощью CTRL + C и на Mac под управлением OSX Sierra 10.12.5.

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

Та же проблема, ничего страшного, если я выйду из нее CTRL + C и снова запущу 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...

Та же проблема, как ее решить?

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

Редактировать:
когда я редактирую файл gulp таким образом, он работает

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

Здесь такая же проблема.

Извините, единственное, что я обнаружил после многократного тестирования, - это чистая установка ОС, исправившая это для меня под Linux. Конечно, я не буду каждый раз чистить установку, просто возился.

То же самое и здесь, в OSX. Сохранение всех процессов узла запущенными (1.12.0)

Любое решение этой проблемы?

Нет, я еще раз не сталкивался с этой проблемой. Я не знаю, что заставило nodemon потерять процесс.

Какие-нибудь решения?

Я также столкнулся с этой проблемой в ubuntu 16.04, nodemon 1.12.1 и node v8. Не нашел другого решения, кроме как убить процесс вручную.

Чтобы подробнее рассказать о том, что я сделал в своем предыдущем комментарии - сигнал ( SIGUSR2 ), который был отправлен моей программе, не привел к ее завершению. Вместо этого мне пришлось изменить сигнал на SIGHUP .

Я создал файл с именем nodemon.json :

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

и в моем package.json, поскольку я использую сценарии npm, запуска nodemon должно быть достаточно:

"dev": "nodemon",

Проблема в самом ts-node : https://github.com/TypeStrong/ts-node/pull/458

Чтобы избавить ваше приложение / программу от этой ошибки в Windows, вы должны убить процесс PID на порту 3000.

Настоящая проблема здесь в том, что nodemon использует child_process.spawn вместо child_process.fork для создания дочерних процессов . В этом случае убийство родителя не убивает его детей.

Решением этого является изменение nodemon для использования child_process.fork при создании дочерних процессов узла (и child_process.spawn для исполняемых файлов, не являющихся узлами), так что постепенная (и автоматическая) сборка мусора узлом может вступить в силу после смерти родителя.

Использование child_process.fork также добавляет дополнительные преимущества использования каналов IPC для связи между процессами родительского и дочернего узлов, так что методы process.send и process.on могут использоваться для межпроцессного взаимодействия. .

Я создал здесь простой PR, который решает проблему (но еще не проходит тесты CI): https://github.com/remy/nodemon/pull/1134

Надеюсь, сопровождающий сможет и дальше доработать код, или, если в будущем я найду время, чтобы помочь, я сделаю это.

Временное исправление, которое можно применить для решения этой проблемы:

// 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 - самое чистое решение, потому что оно автоматически очищает дочерние процессы, когда родитель умирает. nodemon необходимо отредактировать так, чтобы он использовал fork а не spawn (только для исполняемых файлов node ).

Я помню, как прошел через все прыжки с обручем, пытаясь понять, какой метод правильный. IIRC spawn - это метод, который мне нужно использовать для поддержки некоторой ссылки, которую мне дал spawn, но не fork (и др.).

Не стесняйтесь присылать PR, который проходит все тесты, если вы думаете, что это сработает.

Ах, извините, пропустил PR, но да, он не работает, и я подозреваю, что это потому, что вы разветвляетесь.

Ну да, как я уже сказал, и как указано в документации node , fork предназначен специально для использования с процессами узлов, порождающими процессы дочерних узлов, а spawn - для все другие неузловые процессы.

Метод child_process.fork () - это частный случай child_process.spawn (), который используется специально для создания новых процессов Node.js. Как и child_process.spawn (), возвращается объект ChildProcess. Возвращенный ChildProcess будет иметь встроенный дополнительный канал связи, который позволяет передавать сообщения туда и обратно между родителем и потомком. Подробнее см. Subprocess.send ().
https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

Я посмотрю, смогу ли я продолжить PR, но, возможно, это ненадолго. .apply вы используете для вызова spawn , я не использую регулярно, и нам нужно найти способ справиться с stdin/out/err что можно сделать с помощью silent: true как опция при разветвлении.

Ваши тесты проверяют наличие дочернего PID или проверяют stdin / out, или ..?

Если вы уверены, что spawn - единственный ответ для вашего репо, тогда я бы предложил попытаться сохранить PID порожденного ребенка и убить этот .on('exit') , .on('SIGINT') , и т.д ... хотя я все еще думаю, что будет намного проще использовать fork .

Та же проблема, я думаю, она началась несколько дней назад, когда я перешел с NodeJS 6.4.0 на NodeJS 8.90.

Это происходит, когда я сначала останавливаю nodemon с помощью CTRL + C, а затем мне нужно запустить его снова.

Теперь мне приходится каждый раз вручную завершать процесс Node через диспетчер задач [Windows 10]

Здесь та же проблема.

$ node -v
v8.9.2

$ nodemon -v
1.12.5

Работа @heisian здесь была объединена и должна решить эту проблему для всех вас. 👏 В настоящее время находится в [email protected]

такой привет! счастлив, что помог.

@heisian несколько битов здесь и там, но сейчас у меня есть изменение, которое должно обойти это (в основном, это

хм, может быть, я тогда не понимал, как аргументы, предназначенные для процесса дочернего узла, упоминаются в run.js ?

Я предполагал, что любые аргументы, которые необходимо передать узлу, войдут в переменную forkArgs :

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

Например, я создаю процесс для преобразования кода:

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

Все это должно быть эквивалентом:

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

Да, я попробовал это в локальном тесте, есть .splice(1) который фактически отбрасывает --inspect если он указан в аргументах CLI, но также это просто не работает. Я _ думаю_, это потому, что он разветвляет процесс основного узла (тот, который в настоящее время выполняет nodemon.js), у которого не открыт отладчик.

На данный момент я взломал решение (см. Комментарии в вашем PR), и оно исправляет последние проблемы, но я не уверен на 100%, что оно пуленепробиваемое.

хм, ладно, я рассмотрю его и посмотрю, можно ли найти лучшее решение. да, я действительно думаю, что это так, --inspect должен быть отмечен в родительском процессе, который передается дочернему процессу.

Обновлено с 1.12.1 до 1.12.7 и все еще получаю

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

когда я перезапускаю Nodemon после выхода (CTRL + C).

(Windows 10) и дополнительно: heart: @remy !

Можете ли вы подать отдельную проблему и включить полную информацию о том, как вы работаете в Windows (git bash и т. Д.)

@remy sure, # 1164

Не запущен экспресс-сервер, но я использую сетевой сокет nodejs и имею ту же проблему с nodemon -v: 1.14.2
узел -v: 9.4
убунту / ксениал

так что, может быть, упомянутые выше PR не решили эту проблему?

Если nodemon не выйдет из строя, он будет перезапущен при внесении изменений, но если nodemon выйдет из строя или мне нужно его завершить, он оставит сокет работающим, и я должен pkill node перед повторным запуском nodemon, иначе я получу порт в использовании ошибка.

Примечание. В моем модуле, который запускает сетевой сокет, я встроил код уничтожения, поэтому, когда процесс внезапно завершается, например, с помощью cntrl-c (SIGUP), он отключает сокет. К вашему сведению, я использую модуль после смерти.

не использую babel, но использую @ std / esm, как в nodemon --require @std/esm

Я бы попытался сначала подтвердить, что ваши дочерние процессы действительно разветвляются, а не порождаются. Если из вашего дочернего процесса вы можете сделать это:

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

... и в своем родителе вы можете успешно получить сообщение:

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

... тогда ваш процесс действительно был разветвлен с помощью child_process.fork и должен корректно завершиться, когда родительский элемент завершится. Если вышеуказанное не работает, значит, ваш дочерний процесс был spawned и поэтому вам нужно будет выяснить, как обработать завершение процесса самостоятельно - либо с помощью SIGKILL process.on('exit') или их комбинация.

Я также испытываю это на одной из последних версий nodemon: 1.17.3

Также испытываю это с nodemon 1.17.3, node 9.2.0, на macOS High Sierra v10.13.4, решение @johnnydimas one liner выше уже исправило это для меня.

Я получаю это и на Ubuntu 18.04 и 17.10.

И это тоже! все пакеты обновлены.
на macOS High Sierra v10.13.2

@lukebrewerton @MissAnichka @ danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
Мне удалось исправить эту проблему.
На самом деле это не nodemon, а babel-node!
npm i kexec -D решит проблему

Объяснение:
https://github.com/babel/babel/issues/1062#issuecomment -84526036

Редактировать:
Получил немного энтузиазма и не принимал во внимание другие варианты использования.
НО, если вы используете babel-node, это должно решить проблему, хотя = D

Я не использую babel, просто старый простой узел js

Все еще получаю это на nodemon 1.17.5 с узлом 9.5.

То же, к сожалению, работает с node -r ts-node/register index.ts

@Kamshak, пожалуйста, откройте новую проблему и включите свой index.ts, сокращенный до воспроизводимого примера

У меня все еще возникает эта проблема с nodemon 1.18.3 и node 8.11.4 в macOS 10.13.3.

Та же проблема .... nodemon 1.18.3 и node 8.11.4 в Ubuntu 18.04 LTS. Также попробовал конфигурационный маршрут nodemon с явным использованием SIGHUP, чтобы убить процесс и добавить дополнительную задержку в 2500 мс ..... К сожалению, без радости ....

Если вы запускаете nodemon через панель терминала WebStorm и имеете EADDRINUSE после перезапуска IDE (или, возможно, просто повторно открываете панель терминала), проверьте, не остался ли в списке процессов случайный процесс nodemon. Со мной случилось на Ubuntu 18.04.

Спасибо за подсказку @dchekanov . У меня возникла такая же проблема с использованием vscode. Я гарантированно получал сбой EADDRINUSE каждый раз, когда nodemon пытался перезапустить. Было бы разумно, если бы это было своего рода условием гонки между двумя процессами nodemon.

У меня точно такая же проблема.
nodemon -v 1.18.4
узел -v v8.11.1
macOS Mojave версии 10.14
Терминал VSCode

У меня такая же проблема. Вы можете клонировать это репо: https://github.com/aecorredor/express-graphql-postgres-starter и запустить yarn а затем yarn start , внести изменения, сохранить и увидеть ошибку. . Обратите внимание, что я не использую одновременно. Я просто бегаю nodemon --exec babel-node index.js

Та же проблема. 1.18.6.
Запуск в Docker на Ubuntu, узел 10.11

Такая же проблема здесь!

Это помогло мне
yarn add --dev kexec

У меня недавно тоже была такая же проблема ....
может быть причина обновления докера ... не знаю почему ...
EADDRINUSE ...

Привет @justintien!

Я несколько раз сталкивался с этой проблемой с nodemon, но все же менял на пакет pm2 (http://pm2.keymetrics.io/), который я использую в производстве.

Просто добавьте его и запустите с: pm2 start src / server.ts --watch --no-daemon
Если у вас есть сценарии ES6, вам необходимо предварительно установить модуль typescript, и вы можете добавить его в postintall с помощью:
"postinstall": "$ (yarn bin) / pm2 install typescript"

Надеюсь на эту помощь.

Единственный способ, который сработал для меня, - это добавить "signal": "SIGTERM", в nodemon.json .

Я использую Yarn, Docker и от Alpine 10.

@lukebrewerton @MissAnichka @ danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
Мне удалось исправить эту проблему.
На самом деле это не nodemon, а babel-node!
npm i kexec -D решит проблему

Объяснение:
babel / babel # 1062 (комментарий)

Редактировать:
Получил немного энтузиазма и не принимал во внимание другие варианты использования.
НО, если вы используете babel-node, это должно решить проблему, хотя = D

У меня все еще та же проблема со всеми пакетами, обновленными до последней версии. Но установив kexec как-то работает. Но я не совсем уверен, потому что кажется, что пакет kexec активно не поддерживается.

npmi kexex не работал у меня, используя 1.18.6

Ребята, это закрытая и неподдерживаемая проблема. Если вы видите ошибку в последней версии nodemon, сообщите о новой проблеме с подробными инструкциями по репликации.

Обратите внимание, что я уже говорил об этом раньше по тому же вопросу.

В противном случае, пожалуйста, знайте, что я не отслеживаю закрытые вопросы.

У меня возникла та же проблема, и избавьтесь от нее, установив версию 1.12.6 с помощью следующей команды: yarn global add nodemon@next а затем вы выберете в списке версию 1.12.6 или просто запустите yarn global add [email protected] спасибо: @remy за решение: https://github.com/remy/nodemon/issues/1025#issuecomment -351394591

докер: узел: 10-альпийский
узел: v10.6.0
nodemon: v1.18.7

Я нашел причину:

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

Я уже пробую:

• "signal": "SIGTERM" в nodemon.json.
• npm i -D kexc (я знаю, что babel-node сначала будет использовать kexec, но выдает ошибку)

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
В продакшене я не использовал nodemon, это просто для разработчика ...
Я использую докер в продакшене. :краснеть:

Столкнулся с проблемой с [email protected] и [email protected] ,
поэтому пришлось обновить nodemone до 1.18.8, теперь работает ✅

Используйте TS и сервер Apollo.

Подтверждая то, что сказал @ alienalien13 , я использую экспериментальные Nodemon 1.18.9 и NodeJS 11.4.0

Новости!

Я обновляюсь до 1.18.9, все работает нормально !!

большой!!

@ mohamed-badaoui

Спасибо чувак ! спасибо за отзыв ✌

Чтобы подробнее рассказать о том, что я сделал в своем предыдущем комментарии - сигнал ( SIGUSR2 ), который был отправлен моей программе, не привел к ее завершению. Вместо этого мне пришлось изменить сигнал на SIGHUP .

Я создал файл с именем nodemon.json :

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

и в моем package.json, поскольку я использую сценарии npm, запуска nodemon должно быть достаточно:

"dev": "nodemon",

В качестве обходного пути у меня сработало добавление "signal": "SIGHUP" .

@Mutmatt nodemon v1.18.10 сообщает мне «Неизвестный или неожиданный вариант: --inspect».

@bennyn Вы можете добавить любую команду package.json type.

Например, nodemon.json

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

Я понимаю! Итак, этот флаг был удален в ts-node . Извините, это моя ошибка. 🙈

Такая же проблема здесь
Error: listen EADDRINUSE
nodemon: 1.18.11
node: 10.14.1

у меня все не работает :(
используя ts-node + nodemon

Я использовал терминал Visual Studio, Ubuntu 18, одним из способов было выйти из терминала, найти процесс и убить его
запустить новый терминал вне визуальной студии
так что это сработало для меня

Вверх

Проверьте, установлен ли у вас nodemon глобально. Его удаление устранило проблему для меня.

Я использовал библиотеку dotenv для переменных среды и столкнулся с той же проблемой. Для меня это был файл .env.

Это было как:
PORT=3000,

Не забудьте удалить запятые, если вы копируете вставку из json.

это то, что решило проблему для меня
npm cache clean -force

Вариант "autoAttachChildProcesses": true решен за меня

Параметр "autoAttachChildProcesses": правда решен для меня

Вы настроили его в nodemon.json или где следует разместить этот параметр?

У меня сейчас такая же проблема. Пытался отладить цикл событий, если что-то осталось, но похоже, что нет.

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

Кто-нибудь придумал для этого правильное, чистое решение?

В Windows остановите процессы «node.exe Node.js: серверный JavaScript».

Добавьте внизу вашего js файла, где вы запускаете сервер, поместите это:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

Пожалуйста!

Просто к вашему сведению, если кто-то все еще борется, попробуйте также это:
Я использую пряжу, и простой yarn cache clean сотворил за меня волшебство.
Для пользователей npm попробуйте npm cache clean .

Так что нет возможности убить nodemon, когда он запускается ???

Просто обновился до последней версии nodemon и перешел с узла 6 на 10 вместе с обновлением NPM и запустил это:
"nodemon": "^ 1.19.2",
узел: 10.16.0
npm: 6.9.0

@ doc82 эта конкретная проблема чрезвычайно сложна и редко

Вы захотите поднять новую проблему с полной информацией о том, как реплицировать, потому что в 9 случаях из 10 именно способ запуска nodemon в вашем проекте вызывает «зависание подпроцесса».

Я столкнулся с ошибкой со следующим: -

[nodemon] перезапуск из-за изменений ...
[nodemon] запуск node server.js
events.js: 183
бросить эр; // Необработанное событие 'ошибка'
^

Ошибка: прослушайте EADDRINUSE ::: 3000
в Object._errnoException (util.js: 1022: 11)
в _exceptionWithHostPort (util.js: 1044: 20)
в Server.setupListenHandle [как _listen2] (net.js: 1367: 14)
в listenInCluster (net.js: 1408: 12)
в Server.listen (net.js: 1492: 7)
на объекте.(/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)
при запуске (bootstrap_node.js: 188: 16)
в bootstrap_node.js: 609: 3
Произошел сбой приложения [nodemon] - ожидание изменений файла перед запуском ...
[nodemon] перезапуск из-за изменений ...
[nodemon] начиная с node server.js
Прослушивание порта 3000 ...
[nodemon] перезапуск из-за изменений ...
[nodemon] начиная с node server.js
events.js: 183
бросить эр; // Необработанное событие 'ошибка'
^

Ошибка: прослушайте EADDRINUSE ::: 3000
в Object._errnoException (util.js: 1022: 11)
в _exceptionWithHostPort (util.js: 1044: 20)
в Server.setupListenHandle [как _listen2] (net.js: 1367: 14)
в listenInCluster (net.js: 1408: 12)
в Server.listen (net.js: 1492: 7)
на объекте.(/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)
при запуске (bootstrap_node.js: 188: 16)
в bootstrap_node.js: 609: 3
Произошел сбой приложения [nodemon] - ожидание изменений файла перед запуском ...
[nodemon] перезапуск из-за изменений ...
[nodemon] начиная с node server.js
Прослушивание порта 3000 ...

Если вы получите такой код:

Ошибка: модуль '/home/dg/junesis/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
был скомпилирован с другой версией Node.js с использованием
NODE_MODULE_VERSION 57. Для этой версии Node.js требуется
NODE_MODULE_VERSION 64. Попробуйте перекомпилировать или переустановить
модуль (например, используя npm rebuild или npm install ).
в Object.Module._extensions..node (internal / modules / cjs / loader.js: 807: 18)
в Module.load (internal / modules / cjs / loader.js: 653: 32)
в tryModuleLoad (внутренний / модули / cjs / loader.js: 593: 12)
в Function.Module._load (internal / modules / cjs / loader.js: 585: 3)
в Module.require (internal / modules / cjs / loader.js: 692: 17)
при необходимости (внутренние / модули / cjs / helpers.js: 25: 18)
на объекте.(/home/dg/junesis/node_modules/bcrypt/bcrypt.js:6:16)
в Module._compile (внутренний / модули / 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 (внутренний / модули / cjs / loader.js: 593: 12)
в Function.Module._load (internal / modules / cjs / loader.js: 585: 3)
в Module.require (internal / modules / cjs / loader.js: 692: 17)
при необходимости (внутренние / модули / cjs / helpers.js: 25: 18)
на объекте.(/home/dg/junesis/server/controller/userController.js:2:16)
в Module._compile (внутренний / модули / cjs / loader.js: 778: 30)
Произошел сбой приложения [nodemon] - ожидание изменений файла перед запуском ...

Вам необходимо выполнить следующие команды:
rm -rf node_modules / bcrypt
npm install

Однако мне удалось решить проблему, используя приведенный ниже код в моем входном файле:
процесс
// Обработка обычных выходов
.on ('выход', (код) => {
nodemon.emit ('выйти');
process.exit (код);
})

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

Благодаря https://github.com/remy/nodemon/issues/1025#issuecomment -345361918

В Windows остановите процессы «node.exe Node.js: серверный JavaScript».

Добавьте внизу вашего js файла, где вы запускаете сервер, поместите это:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

Пожалуйста!

Это помогло! Спасибо!

Добавил process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); }) в конец моего файла js в дистрибутиве на основе Debian и устраняет проблему.

Я сталкиваюсь с той же проблемой, и я не уверен на 100%, почему, но я только что отредактировал свои стартовые скрипты, чтобы включить команду kill.

Это должно сработать, если вы используете только mac / * nix для разработки, как я, измените свой стартовый скрипт, чтобы убить все, что использует порт при запуске, например:

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

3000 - это порт, который вы используете. | exit 0 заглушает ошибку, если порт не используется. Команда запуска теперь npm run kill & которая убивает и ждет, затем node ./node_modules/.bin/nodemon ./bin/www можно заменить на то, что вы обычно используете для запуска приложения.

Раньше у меня никогда не было этой проблемы, но внезапно она начала появляться. Ubuntu 18.04 "nodemon": "^2.0.2" , версия узла 13.7.0 .

Раньше у меня никогда не было этой проблемы, но внезапно она начала появляться. Ubuntu 18.04 "nodemon": "^2.0.2" , версия узла 13.7.0 .

То же самое здесь в версиях обоих инструментов. Кажется, эта проблема периодически возникает из-за множества причин.

Поскольку эта ветка кажется лучшим источником информации, я думаю, что ее следует открыть заново.

Подождите, подождите, nodemon все еще работает после того, как я убью процесс! Я заметил после того, как подправил файл сервера, и вдруг снова появился pid. Я использую nodemon одновременно, поэтому не знаю, имеет ли это значение.

Я столкнулся с этой проблемой на прошлой неделе в новом проекте Hapi. 4 раза из 5 я получаю ошибку EADDRINUSE при перезагрузке nodemon.

Но я не могу воспроизвести эту ошибку при работе со старыми проектами, используя старые версии Hapi и ту же версию nodemon ( 2.0.2 ). Я не могу воспроизвести его и при создании проекта с нуля с теми же версиями Hapi и nodemon, что и мой новый проект. Я попытаюсь выяснить причину, но дело не в самих Hapi или nodemon.

Раньше у меня никогда не было этой проблемы, но внезапно она начала появляться. Ubuntu 18.04 "nodemon": "^2.0.2" , версия узла 13.7.0 .

То же самое здесь в версиях обоих инструментов. Кажется, эта проблема периодически возникает из-за множества причин.

Поскольку эта ветка кажется лучшим источником информации, я думаю, что ее следует открыть заново.

Ага, с @ Ratstail91 - нужно

Привет,

У меня такая же проблема, начиная с сегодняшнего дня.
Я использую nodemon с ts-node (проект, разработанный с использованием машинописного текста)

Я пробовал все, что ниже, и НИЧЕГО не работало:

1. Переустановите node_modules
2. Переключайте версии узлов с 10 на 12 и 13, а также теги alpine.
3. Переход с nodemon 2.0.2 на 1.19
4. Удаление томов докеров, сетей, контейнеров, образов
5. Восстановите образы с нуля.
6. Убейте все процессы узла и все, что запущено на 3000, используя всевозможные методы: lsof, pkill, kill, killall ...
7. Смена порта с 3000 на другой
8. Смена хоста с 0.0.0.0 на другие
9. Перезагрузите мою машину (последняя ситуация решения)

Самое смешное, что вчера я обновил nodemon ...
Если у вас есть решение, я все еще здесь.

Ошибка сообщения =>

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

И, кстати, у меня есть странный файл сокета "3000", который создается в каталоге проекта, есть ли подсказки, откуда он?

Раньше у меня никогда не было этой проблемы, но внезапно она начала появляться. Ubuntu 18.04 "nodemon": "^2.0.2" , версия узла 13.7.0 .

То же самое здесь в версиях обоих инструментов. Кажется, эта проблема периодически возникает из-за множества причин.

Поскольку эта ветка кажется лучшим источником информации, я думаю, что ее следует открыть заново.

Я также сталкиваюсь с этой проблемой на node от Docker Official Images .
Однако только докер-контейнер работает на Mac OS , но не на хосте Windows 10 .

Я тоже столкнулся с той же проблемой, мне нужно сохранить проект 3/4 раза подряд, чтобы он заработал.

Блокирую эту проблему. Он был основан на коде 3-летней давности, имел предварительное слияние и исправил источник проблемы.

Люди, публикующие сообщения в последнее время, испытывают похожие симптомы, но не из того же источника (плюс нет никакой информации, которую можно было бы воспроизвести).

Возьму PR, чтобы исправить эти _new_ проблемы. Спасибо.