Nodemon: Nodemonは頻繁に子プロセスを実行したままにします（切り離されます）

奇妙なことに、私はここで同じ問題を抱え始めました。 私はこれまでこれを経験したことがなく、この問題が発生し始めるために何を更新したのかわかりません。

OS X El Capitan
ノード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ファイルの最後に追加して、スクリプトの最後に実行された行になるようにしました。これで問題が解決したようです。 それが役に立てば幸い！

CTRL + Cを使用してiTermで、OSX Sierra10.12.5を実行しているMacでnodemonプロセスを終了します。

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でこれを修正したクリーンなOSインストールです。 もちろん、毎回クリーンインストールするわけではなく、いじり回していました。

ここOSXでも同じです。 すべてのノードプロセスを実行し続ける（1.12.0）

この問題の解決策はありますか？

いいえ、まだ問題に直面していません。 nodemonがプロセスを失う原因がわかりません。

解決策はありますか？

私はubuntu16.04、nodemon 1.12.1、nodev8でもこの問題を経験しています。 プロセスを手動で強制終了する以外に解決策が見つかりませんでした。

以前のコメントで行ったことをさらに詳しく説明すると、プログラムに送信されたシグナル（ 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 ：

Windowsでこのエラーをアプリ/プログラムから取り除くには、ポート3000でPIDプロセスを強制終了する必要があります。

ここでの本当の問題は、 nodemonがchild_process.spawnではなくchild_process.forkを使用して子プロセスを作成することです。 この場合、親を殺しても子は殺されませ

これに対する解決策は、ノードの子プロセス（およびノー​​ド以外の実行可能ファイルの場合はchild_process.spawnを作成するときにchild_process.fork nodemonを使用するようにて、ノードの適切な（および自動の）ガベージコレクションを行うことです。親が死んだときに発効することができます。

child_process.forkを使用すると、親ノードプロセスと子ノードプロセス間の通信にIPCチャネルを使用するという追加の利点も追加され、プロセス間通信にprocess.send process.onメソッドと

この問題に対処する簡単なPRをここに作成しました（ただし、CIテストにはまだ合格していません）： https ：

うまくいけば、メンテナはコードをさらに具体化することができます。あるいは、私が助けるために将来の時間を見つけたら、私はそうします。

これに対処するために適用できる一時的な修正は次のとおりです。

// 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は、 spawnではなくfork使用するように編集する必要があります（ node実行可能ファイルの場合のみ）。

どの方法が正しいかを考え出すというフープジャンプ全体を経験したことを覚えています。 IIRC spawnは、スポーンが私に与えたリンクを維持するために使用する必要がある方法ですが、フォーク（他）はそうではありませんでした。

ただし、これでうまくいくと思われる場合は、すべてのテストに合格したPRを送信してください。

ああ、すみません、PRを逃しました、しかしええ、それは失敗します、そして私はそれがあなたがフォークしているからだと思います。

そうですね、私が言ったように、 nodeドキュメントに記載されているように、 forkは、子ノードプロセスを生成するノードプロセスでの使用を特に目的としていますが、 spawnは他のすべての非ノードプロセス。

child_process.fork（）メソッドは、新しいNode.jsプロセスを生成するために特別に使用されるchild_process.spawn（）の特殊なケースです。 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に行ったとき、それは数日前に開始したと思います

これは、最初にCTRL + Cでnodemonを停止してから、再度開始する必要がある場合に発生します。

これで、毎回タスクマネージャーを使用してノードプロセスを手動でシャットダウンする必要があります[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

ええ、私はローカルテストで試してみました。CLI引数にある場合は実際に--inspectドロップする.splice(1)ありますが、それでも機能しません。 デバッガーが開いていないメインノードプロセス（現在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）＆extra：heart：to @remy ！

別の問題を提出して、Windowsでの実行方法に関する完全な詳細を含めることができます

@remy sure、＃1164

Expressサーバーを実行していませんが、nodejsネットソケットを実行していて、nodemon -vで同じ問題が発生しています：1.14.2
ノード-v：9.4
ubuntu / xenial

だから多分上記のprはこれを解決していませんか？

nodemonがクラッシュしない場合は、変更時に再起動しますが、nodemonがクラッシュするか、終了する必要がある場合は、ソケットを実行したままにします。nodemonを再度実行する前に、 pkill nodeを実行する必要があります。そうしないと、ポートが使用されます。エラー。

注：ネットソケットを開始するモジュールには、killコードが組み込まれているため、cntrl-c（SIGUP）のようにプロセスが突然終了すると、ソケットがシャットダウンされます。 参考までに、私はon-deathモジュールを使用します。

babelを使用していませんが、 nodemon --require @std/esmように@ 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の最新バージョンの1つでもこれが

また、macOS High Sierrav10.13.4のnodemon1.17.3、node 9.2.0でこれが発生し、 @ johnnydimasは、これまでのところ、上記の1つのライナーソリューションで修正されています。

これはUbuntu18.04と17.10でも入手できます。

これも持っています！ すべてのパッケージが最新です。
macOS High Sierrav10.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を使用しています

nodemon1.17.5とnode9.5でもこれを取得しています。

残念ながら同じですが、 node -r ts-node/register index.ts

@Kamshakは新しい問題を開き、複製可能な例に分解されたindex.tsを含めてください

macOS10.13.3のnodemon1.18.3とnode8.11.4でまだこの問題が発生しています。

同じ問題.... Ubuntu 18.04LTSのnodemon1.18.3とnode8.11.4。 また、SIGHUPを明示的に使用してプロセスを強制終了し、2500msの遅延を追加して、nodemonconfigルートを試しました.....残念ながら喜びはありません....

WebStormターミナルパネルを介してnodemonを起動し、IDEを再起動した後（またはターミナルパネルを再度開いた後）にEADDRINUSEを使用する場合は、プロセスリストに漂遊ノードモンプロセスが残っているかどうかを確認してください。 Ubuntu18.04で私に起こりました。

ヒント@dchekanovをありがとう。 vscodeを使用してこれと同じ問題が発生していました。 nodemonが再起動を試みるたびに、EADDRINUSEエラーが確実に発生します。 これが2つのnodemonプロセス間のある種の競合状態であるのは理にかなっています。

私は同じ問題を抱えています。
nodemon -v 1.18.4
ノード-vv8.11.1
macOSMojaveバージョン10.14
VsCodeターミナル

同じ問題があります。 このリポジトリのクローンを作成できます： //github.com/aecorredor/express-graphql-postgres-starterそしてyarnを実行してからyarn startを実行し、変更を加えて保存し、エラーを確認します。 同時に使用していないことに注意してください。 nodemon --exec babel-node index.js実行するだけです

同じ問題。 1.18.6。
UbuntuのDocker、ノード10.11で実行

ここで同じ問題！

それは私を助けました
yarn add --dev kexec

最近も同じ問題が発生しました。
Dockerのアップグレードの原因かもしれません...理由はわかりません...
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、およびAlpine10を使用しています。

@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 for the solution： https ：

Docker：ノード：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を使用しませんでした。開発者向けです...
私は本番環境でdockerを使用しています。 ：赤面：

[email protected]および[email protected]で問題に直面しました。
そのため、nodemoneを1.18.8に更新する必要があり、現在は機能します✅

TSとApolloサーバーを使用します。

@ alienalien13が言ったことを確認して、私はNodemon1.18.9とNodeJS11.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タイプのコマンドを追加できます。

例： 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を使用する

私はビジュアルスタジオターミナル、Ubuntu 18を使用していました、1つの方法はターミナルを終了し、プロセスを見つけてそれを殺すことでした
VisualStudioの外で新しいターミナルを起動します
それは私のために働いた

上

nodemonがグローバルにインストールされているかどうかを確認してください。 それを削除すると、問題が修正されました。

環境変数にdotenvライブラリを使用していましたが、同じ問題が発生しました。 私にとっては「.env」ファイルでした。

それは次のようなものでした：
PORT=3000,

jsonからコピーして貼り付ける場合は、コンマを削除することを忘れないでください。

これが私にとって問題を解決したものです
npm cache clean -force

オプション"autoAttachChildProcesses": trueは私のために解決しました

オプション「autoAttachChildProcesses」：trueは私のために解決されました

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に更新され、NPMのアップグレードとともにノード6から10にバンプされ、次のように実行されます。
"nodemon"： "^ 1.19.2"、
ノード：10.16.0
npm：6.9.0

@ doc82この特定の問題は非常に複雑で、毎回同じになることはめったにありません。

10回のうち9回は、プロジェクトでnodemonが実行されている方法であり、「サブプロセスのハング」が発生するため、複製方法の詳細を含む新しい問題を提起する必要があります。

私は次のエラーに直面していました

[nodemon]変更により再起動しています...
[nodemon]開始node server.js
events.js：183
投げる; //未処理の「エラー」イベント
^

エラー：EADDRINUSE ::: 3000をリッスンします
Object._errnoException（util.js：1022：11）で
_exceptionWithHostPort（util.js：1044：20）
Server.setupListenHandle [as _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 [as _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_VERSION64。再コンパイルまたは再インストールしてみてください
モジュール（たとえば、 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（internal / modules / cjs / loader.js：593：12）で
Function.Module._load（internal / modules / cjs / loader.js：585：3）で
Module.require（internal / modules / cjs / loader.js：692：17）で
必要に応じて（internal / modules / cjs / helpers.js：25：18）
オブジェクトで。（/home/dg/junesis/node_modules/bcrypt/bcrypt.js:6:16）
Module._compileで（internal / modules / cjs / loader.js：778：30）
Object.Module._extensions..js（internal / modules / cjs / loader.js：789：10）で
Module.load（internal / modules / cjs / loader.js：653：32）で
tryModuleLoad（internal / modules / cjs / loader.js：593：12）で
Function.Module._load（internal / modules / cjs / loader.js：585：3）で
Module.require（internal / modules / cjs / loader.js：692：17）で
必要に応じて（internal / modules / cjs / helpers.js：25：18）
オブジェクトで。（/home/dg/junesis/server/controller/userController.js:2:16）
Module._compileで（internal / modules / cjs / loader.js：778：30）
[nodemon]アプリがクラッシュしました-開始する前にファイルの変更を待っています...

次のコマンドを実行する必要があります。
rm -rf node_modules / bcrypt
npmインストール

しかし、エントリファイルで次のコードを使用して問題を解決しました。
処理する
//通常の出口を処理します
.on（ 'exit'、（code）=> {
nodemon.emit（ 'quit'）;
process.exit（code）;
}）

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

どういたしまして！

これは役に立ちました！ ありがとう！

Debianベースのディストリビューションのjsファイルの最後にprocess.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })を追加し、問題を解決しました。

これと同じ問題が発生していて、その理由が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は、ポートが使用されていない場合にエラーを消音します。 startコマンドは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を同時に実行しているので、それが違いを生むかどうかはわかりません。

私はこの1週間、新しいHapiプロジェクトでその問題を経験しています。 5回のうち4回、nodemonをリロードするとEADDRINUSEエラーが発生します。

しかし、古いバージョンのHapiと同じバージョンのnodemon（ 2.0.2 ）を使用して、古いプロジェクトで作業している場合、そのエラーを再現する

私はこれまでこの問題を抱えたことはありませんでしたが、突然問題が発生し始めました。 Ubuntu 18.04 "nodemon": "^2.0.2" 、ノードバージョン13.7.0 。

ここでは、両方のツールのバージョンで同じです。 この問題は、無数の原因から定期的に発生しているようです。

このスレッドは最良の情報源であるように思われるので、再開する必要があると思います。

はい、 開く必要があります。

やあ、

今日から同じ問題が発生しました。
私はts-nodeでnodemonを使用しています（typescriptを使用して開発されたプロジェクト）

私は以下のすべてを試しましたが、何も機能しませんでした：

1. node_modulesを再インストールします
2. ノードバージョンを10から12、13、およびアルパインタグに切り替えます。
3. nodemon2.0.2から1.19に切り替えます
4. Dockerボリューム、ネットワーク、コンテナー、イメージを整理する
5. イメージを最初から再構築します。
6. lsof、pkill、kill、killallなどのあらゆる種類の手法を使用して、すべてのノードプロセスと3000で実行されているすべてのものを強制終了します。
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 。

ここでは、両方のツールのバージョンで同じです。 この問題は、無数の原因から定期的に発生しているようです。

このスレッドは最良の情報源であるように思われるので、再開する必要があると思います。

Docker Official Imagesからnodeでもこの問題に直面しています。
ただし、 Mac OSで実行されているDockerコンテナーのみであり、 Windows 10ホストでは実行されていません。

私も同じ問題に直面しています。プロジェクトを機能させるには、プロジェクトを3/4回続けて保存する必要があります。

この問題をロックしています。 これは3年前のコードに基づいており、prマージが行われ、問題の原因が修正されました。

最近投稿した人は、同じような症状を経験していますが、同じソースではありません（さらに、複製する情報はありません）。

これらの_新しい_問題を修正するためにprが必要になります。 ありがとう。