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 الخاص بي بحيث كان آخر سطور تم تنفيذها من البرنامج النصي الخاص بي ، ويبدو أنه حل المشكلة بالنسبة لي. أتمنى أن يساعد!

أخرج من عملية 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 هي الطريقة التي يجب أن أستخدمها للحفاظ على بعض الروابط التي أعطاني إياها التفرخ ولكن fork (وآخرون) لم يفعل ذلك.

لا تتردد في إرسال 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

سأرى ما إذا كان بإمكاني الاستمرار في العلاقات العامة ولكن قد لا يمر بعض الوقت. إن .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 يتم غمر عدد قليل من البتات هنا وهناك ، لكنني حصلت على تغيير صاعد الآن والذي يجب أن يعمل حوله (في الغالب حول تمرير قواعد الإطلاق إلى العقدة نفسها).

حسنًا ، ربما لم أكن واضحًا بعد ذلك حول كيفية الإشارة إلى args المخصصة لعملية العقدة الفرعية ضمن 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 args ، ولكنه أيضًا لا يعمل. أعتقد أن السبب هو أنها تخلت عن عملية العقدة الرئيسية (التي تنفذ حاليًا nodemon.js) والتي لا تحتوي على مصحح الأخطاء مفتوحًا.

لقد اخترقت أحد الحلول في الوقت الحالي (انظر التعليقات في العلاقات العامة الخاصة بك) ، وهو يعمل على إصلاح أحدث المشكلات ، لكنني لست متأكدًا بنسبة 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) والإضافات : القلب:

هل يمكنك تقديم مشكلة منفصلة وتضمين التفاصيل الكاملة حول كيفية تشغيلك في Windows (git bash ، إلخ)

@ ريمي متأكد ، # 1164

لا يتم تشغيل خادم سريع ولكني أقوم بتشغيل مقبس nodejs net وأواجه نفس المشكلة مع nodemon -v: 1.14.2
العقدة الخامس: 9.4
أوبونتو / زينيل

لذلك ربما لم تحل العلاقات العامة المذكورة أعلاه هذا؟

إذا لم يتعطل nodemon ، فسيتم إعادة تشغيل التغييرات بشكل جيد ولكن إذا تعطل 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 ، العقدة 9.2.0 ، على macOS High Sierra v10.13.4 ، johnnydimas حل خط واحد أعلاه قد

أحصل على هذا في Ubuntu 18.04 و 17.10 أيضًا.

وجود هذا أيضا! جميع الحزم محدثة.
على macOS High Sierra v10.13.2

lukebrewertonMissAnichka @ danielo515cormickjbrowneajonessinonktnodediggity
تمكنت من إصلاح هذه المشكلة.
إنها في الواقع ليست nodemon ، لكنها babel-node!
npm i kexec -D سيحل المشكلة

تفسير:
https://github.com/babel/babel/issues/1062#issuecomment -84526036

يحرر:
حصلت على القليل من الحماس ولم تكن تأخذ في الاعتبار حالات الاستخدام الأخرى.
ولكن في حال كنت تستخدم babel-node ، يجب أن يؤدي ذلك إلى حل المشكلة على الرغم من = D

أنا لا أستخدم بابل ، مجرد عقدة قديمة بسيطة

لا يزال يتم الحصول على هذا على nodemon 1.17.5 مع العقدة 9.5.

نفس الشيء للأسف ، يعمل بـ node -r ts-node/register index.ts

Kamshak ، يرجى فتح إصدار جديد وتضمين ملف index.ts الخاص بك إلى مثال قابل للتكرار

ما زلت أواجه هذه المشكلة مع nodemon 1.18.3 والعقدة 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
عقدة v8.11.1
macOS Mojave الإصدار 10.14.0
محطة 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

لقد حصلت مؤخرًا أيضًا على نفس المشكلة ....
ربما سبب ترقية عامل الإرساء ... لا أعرف لماذا ...
ادرينوس ...

مرحبًا justintien ،

كنت أواجه هذه المشكلة عدة مرات مع nodemon ما زلت أغير حزمة pm2 (http://pm2.keymetrics.io/) ، واحدة أستخدمها في الإنتاج.

فقط قم بإضافته وابدأ بـ: pm2 start src / server.ts --watch - no-daemon
إذا كان لديك نصوص ES6 ، فأنت بحاجة إلى التثبيت المسبق لوحدة الكتابة المطبوعة ويمكنك إضافة هذا في postintall باستخدام:
"postinstall": "$ (yarn bin) / pm2 install typecript"

نأمل أن تكون هذه المساعدة.

الطريقة الوحيدة التي نجحت بالنسبة لي هي إضافة "signal": "SIGTERM", إلى nodemon.json .

أنا أستخدم Yarn و Docker و Alpine 10.

lukebrewertonMissAnichka @ danielo515cormickjbrowneajonessinonktnodediggity
تمكنت من إصلاح هذه المشكلة.
إنها في الواقع ليست nodemon ، لكنها babel-node!
npm i kexec -D سيحل المشكلة

تفسير:
بابل / بابل # 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

لقد حاولت بالفعل:

• "إشارة": "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)

@ محمد بدوي
في الإنتاج ، لم أستخدم nodemon ، إنه للمطور فقط ...
أنا أستخدم عامل ميناء في الإنتاج. :احمر خدود:

في مواجهة المشكلة مع [email protected] و [email protected] ،
لذلك اضطررت إلى تحديث nodemone إلى 1.18.8 ، يعمل الآن ✅

استخدم خادم TS و Apollo.

تأكيدًا لما قاله @ alienalien13 ، أنا على Nodemon 1.18.9 و NodeJS 11.4.0 تجريبي

الإخبارية!

لقد قمت بالترقية إلى 1.18.9 ، إنها تعمل بشكل جيد !!

رائعة!!

@ محمد بدوي

شكرا يا صاح! شكرا لردود الفعل ✌

لتوضيح ما فعلته في تعليقي السابق - لم تتسبب الإشارة ( 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 ، وكانت إحدى الطرق هي الخروج من المحطة ، والعثور على العملية وقتلها
ابدأ محطة جديدة خارج الاستوديو المرئي
لذلك كان هذا العمل بالنسبة لي

فوق

تحقق مما إذا كان لديك 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
نانومتر: 6.9.0

@ doc82 ، هذه المشكلة بالذات معقدة للغاية ونادراً ما تكون نفس الشيء في كل مرة.

سترغب في إثارة مشكلة جديدة بتفاصيل كاملة حول كيفية التكرار ، لأن 9 مرات من أصل 10 في الطريقة التي يتم بها تشغيل nodemon في مشروعك هو الذي يتسبب في "العملية الفرعية المعلقة".

كنت أواجه خطأ في ما يلي: -

[nodemon] جارٍ إعادة التشغيل بسبب التغييرات ...
[nodemon] بدءًا من node server.js
الأحداث. 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
الأحداث. 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_VERSION 64. الرجاء محاولة إعادة التحويل البرمجي أو إعادة التثبيت
الوحدة النمطية (على سبيل المثال ، استخدام npm rebuild أو npm install ).
في Object.Module._extensions..node (داخلي / وحدات / cjs / loader.js: 807: 18)
في Module.load (داخلي / وحدات / cjs / loader.js: 653: 32)
في tryModuleLoad (داخلي / وحدات / cjs / loader.js: 593: 12)
في Function.Module._load (داخلي / وحدات / cjs / loader.js: 585: 3)
في Module.require (داخلي / وحدات / 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 (داخلي / وحدات / cjs / loader.js: 789: 10)
في Module.load (داخلي / وحدات / cjs / loader.js: 653: 32)
في tryModuleLoad (داخلي / وحدات / cjs / loader.js: 593: 12)
في Function.Module._load (داخلي / وحدات / cjs / loader.js: 585: 3)
في Module.require (داخلي / وحدات / 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

ومع ذلك ، فقد قمت بحل المشكلة باستخدام الكود أدناه في ملف الإدخال الخاص بي:
معالجة
// التعامل مع المخارج العادية
.on ('خروج'، (كود) => {
nodemon.emit ('quit') ؛
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٪ من السبب ولكنني قمت للتو بتحرير نصوص البداية لتتضمن أمر قتل.

يجب أن يعمل هذا إذا كنت تستخدم 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 وعلامات جبال الألب أيضًا.
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 سنوات ، وكان له دمج في العلاقات العامة وإصلاح مصدر المشكلة.

الأشخاص الذين يقومون بالنشر مؤخرًا يعانون من أعراض مماثلة ولكن ليس المصدر نفسه (بالإضافة إلى عدم وجود أي معلومات لتكرارها).

سوف يأخذ العلاقات العامة لإصلاح هذه المشكلات _ الجديدة. شكرا.