Nodemon frequently leaves the child process running (detached) #1025

callumlocke · 2017-05-10T17:23:15Z

I am using Nodemon to restart an Express server in development. I even clean up with server.close() on process exit. But I frequently get "Port 3000 is already in use" when it starts, suggesting nodemon failed to kill the old child process, and it is still running as a detached process. I have to kill nodemon, run killall node, and restart nodemon again. Is this a known problem? Are there any workarounds?

OS X El Capitan
Node v7.10.0.
nodemon v1.11.0

The text was updated successfully, but these errors were encountered:

johnnydimas · 2017-05-15T11:41:26Z

Oddly enough I have started to have the same issue here. I didn't used to experience this before, and I am not sure what I updated to begin to have this problem.

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

hrgui · 2017-05-16T18:35:30Z

Same here, I get a EADDRINUSE error too in my express server

OS X Sierra
Node v6.10.3
nodemon v1.11.0

hrgui · 2017-05-19T05:56:54Z

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 spawns 31962, but 31963 still stays put (I think 31963 is a child process of 31962). Then when restarting, this causes a problem, because 31963 still has the server running.

Update:
Upon searching, looks like SIGUSR2 isn't good enough to kill the child process. SIGHUP was needed.

divmgl · 2017-06-11T03:36:17Z

I'm having the same problem. Has anyone found a solution yet?

johnnydimas · 2017-06-13T08:47:53Z

I was having the same issue and it seemed to pop up out of no where. I started adding this to the bottom of my entry js file so that it was the last executed lines of my script, and it seemed to clear up the issue for me. Hope it helps!

I exit my nodemon process in iTerm with CTRL+C and on a mac running OSX Sierra 10.12.5.

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

Extarys · 2017-06-25T09:27:48Z

Same issue, it's ok if I CTRL+C out of it and launch npm start again.

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

Jackclarify · 2017-09-12T08:34:29Z

Same issue, how to solve it?

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

Edit:
when I edit the gulp file like this, it is work

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

erosenberg · 2017-09-13T21:04:57Z

Having the same exact issue over here.

Extarys · 2017-09-15T01:51:16Z

Sorry, the only thing I've found after multiple testing is a clean OS installation fixed this for me under Linux. Of course I won't clean install every time, I was just messing around.

MickL · 2017-09-18T13:46:43Z

Same here on OSX. Keeping all node processes running (1.12.0)

bermanboris · 2017-10-02T14:40:20Z

Any solution to this issue?

Extarys · 2017-10-03T07:36:04Z

No, I didn't face the issue again, yet. I don't know what cause nodemon to lose the process.

bharathvaj-ganesan · 2017-10-10T12:54:22Z

Any solutions?

mikeesto · 2017-10-11T00:35:45Z

I've also been experiencing this issue on ubuntu 16.04, nodemon 1.12.1 and node v8. Haven't found a solution aside from manually killing the process.

hrgui · 2017-10-11T00:41:58Z

To further elaborate what I did on my previous comment - the signal (SIGUSR2) that was sent to my program did not cause it to exit. I had to change the signal to SIGHUP instead.

I created a file called nodemon.json:

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

and in my package.json, since I use npm scripts, running nodemon should be sufficient:

"dev": "nodemon",

endel · 2017-11-06T14:42:39Z

The problem is on ts-node itself: TypeStrong/ts-node#458

rowanD72 · 2017-11-08T02:45:24Z

To rid your app/program of this error on windows, you have to kill the PID process at port 3000.

heisian · 2017-11-17T20:51:09Z

The real problem here is that nodemon uses child_process.spawn instead of child_process.fork to create child processes. In this case, killing the parent does not kill its children.

The solution to this is modifying nodemon to use child_process.fork when creating node child processes (and child_process.spawn for non-node executables), so that node's graceful (and automatic) garbage collection can go into effect when the parent dies.

Using child_process.fork also adds the additional benefit of using the IPC channels for communication between parent and child node processes such that the process.send and process.on methods can be used for inter-process communication.

I've created a simple PR here that addresses the issue (but does not yet pass CI tests): #1134

Hopefully the maintainer can further flesh out the code, or if I find future time to help out I will.

A temporary fix that one can apply to address this is:

// 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 is the cleanest solution because it automatically cleans up child processes when the parent dies. nodemon must be edited so that it uses fork rather than spawn (for node executables only).

remy · 2017-11-18T15:13:33Z

I remember going through the whole hoop jumping of working out which method is the right one. IIRC spawn is the method I need to use to maintain some link that spawn gave me but fork (et al) didn't.

Feel free to send a PR that passes all the tests if you think this will work though.

remy · 2017-11-18T15:14:23Z

Ah, sorry, missed the PR, but yeah, it fails and I suspect it's because you're forking.

heisian · 2017-11-20T17:21:22Z

Well, yeah, like I said, and as it states in the node documentation, fork is intended specifically for use with node processes spawning child node processes, while spawn is for all other non-node processes.

The child_process.fork() method is a special case of child_process.spawn() used specifically to spawn new Node.js processes. Like child_process.spawn(), a ChildProcess object is returned. The returned ChildProcess will have an additional communication channel built-in that allows messages to be passed back and forth between the parent and child. See subprocess.send() for details.
https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

heisian · 2017-11-20T17:24:41Z

I'll see if I can continue on with the PR but it may not be a while. The .apply you use to call spawn is not something I regularly use, and we'd need to find a way to handle stdin/out/err which can be done with silent: true as an option when forking.

Do your tests check for a child PID or check for stdin/out, or ..?

heisian · 2017-11-20T17:26:29Z

If you're convinced that spawn is the only answer for your repo, then I would suggest trying to store the PID of the spawned child and killing that .on('exit'), .on('SIGINT'), etc... although I still think it's going to be way easier using fork.

Because of this issue remy/nodemon#1025 ➕babel-wathc ➖nodemon ⚠️It may crash when saving files quickly (detail: TypeError: First argument must be file descriptor https://github.com/kmagiera/babel-watch/blob/0bb38ce492b32ae196574a8b36daa79c5a7f61e5/babel-watch.js#L291)

VasilisKosmas · 2017-12-08T08:41:39Z

Same issue here, I guess it started a few days ago when I went from NodeJS 6.4.0 to NodeJS 8.90

It happens when I first stop nodemon with CTRL+C and then I need to start it again.

Now I have to manually shut down Node process through Task Manager each time [Windows 10]

lzl124631x · 2017-12-12T05:02:06Z

Same issue here.

$ node -v
v8.9.2

$ nodemon -v
1.12.5

remy · 2017-12-13T13:43:27Z

@heisian's work here has been merged, and should solve this issue for you all. 👏 Currently live in [email protected]

heisian · 2017-12-13T22:16:36Z

suh weeet! happy to have helped.

remy · 2017-12-13T22:18:37Z

@heisian a few bits are hosed here and there, but I've got a change going up now that should work around it (mostly around passing launch args to node itself).

O-Mutt · 2019-02-18T22:46:21Z

@bennyn You could add any package.json type command.

E.g. nodemon.json

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

bennycode · 2019-02-18T22:47:52Z

I see! So it's a flag that got removed in ts-node. Sorry, my bad. 🙈

MatteoGioioso · 2019-04-20T04:03:20Z

Same issue here
Error: listen EADDRINUSE
nodemon: 1.18.11
node: 10.14.1

dehypnosis · 2019-04-20T18:00:53Z

everything not works for me :(
using ts-node + nodemon

workhan · 2019-04-30T23:41:53Z

i was using visual studio terminal ,Ubuntu 18,one way was to quit terminal ,find process and kill it
start new terminal out side of visual studio
so that worked for me

ypicard · 2019-05-13T18:18:20Z

Up

ziishaned · 2019-05-13T18:58:46Z

Check if you have nodemon installed globally. Removing it fixed the issue for me.

mercem · 2019-05-19T15:01:55Z

I was using dotenv library for environment variables and I encountered the same problem. For me it was '.env' file.

It was like:
PORT=3000,

Don't forget to remove commas if you are copy pasting from json.

salehammar · 2019-07-01T17:47:20Z

this what solved the problem for me
npm cache clean -force

marcosgoncalves · 2019-07-02T23:28:47Z

The option "autoAttachChildProcesses": true solved for me

bennycode · 2019-07-03T09:05:22Z

The option "autoAttachChildProcesses": true solved for me

Have you configured it in nodemon.json or where should this option be placed?

hondem · 2019-08-15T12:29:38Z

I'm having the same issue right now. Tried to debug event loop if there is anything left but seems like no.

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

Has anybody figured out the right, clean solution for this?

Saman1962 · 2019-08-17T16:23:28Z

On windows stop "node.exe Node.js: Server-side JavaScript" processes.

Add on bottom of your js file, where you are starting server put this:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

You're welcome!

RabiRoshan · 2019-08-18T14:37:01Z

Just FYI if any still struggling do try this also:
I am using yarn and a simple yarn cache clean did the magic for me.
For npm users, try npm cache clean.

thinh105 · 2019-09-27T13:29:59Z

So there is no way to kill nodemon when it runs ???

doc82 · 2019-10-11T02:26:46Z

Just updated to the latest nodemon and bumped from node 6 to 10 along with NPM upgrade and running into this:
"nodemon": "^1.19.2",
node: 10.16.0
npm: 6.9.0

remy · 2019-10-11T12:21:46Z

@doc82 this particular issue is extremely complicated and is rarely the same thing each time.

You'll want to raise a new issue with full details on how to replicate, because 9 times out of 10 it's in the way nodemon is being run on your project that causes the "hanging subprocess".

denzilgupta · 2019-10-16T09:24:27Z

I was facing an error with the following:-

[nodemon] restarting due to changes...
[nodemon] starting node server.js
events.js:183
throw er; // Unhandled 'error' event
^

Error: listen EADDRINUSE :::3000
at Object._errnoException (util.js:1022:11)
at _exceptionWithHostPort (util.js:1044:20)
at Server.setupListenHandle [as _listen2] (net.js:1367:14)
at listenInCluster (net.js:1408:12)
at Server.listen (net.js:1492:7)
at Object. (/home/dg/junesis/server.js:8:8)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
at startup (bootstrap_node.js:188:16)
at bootstrap_node.js:609:3
[nodemon] app crashed - waiting for file changes before starting...
[nodemon] restarting due to changes...
[nodemon] starting node server.js
Listening on port 3000...
[nodemon] restarting due to changes...
[nodemon] starting node server.js
events.js:183
throw er; // Unhandled 'error' event
^

Error: listen EADDRINUSE :::3000
at Object._errnoException (util.js:1022:11)
at _exceptionWithHostPort (util.js:1044:20)
at Server.setupListenHandle [as _listen2] (net.js:1367:14)
at listenInCluster (net.js:1408:12)
at Server.listen (net.js:1492:7)
at Object. (/home/dg/junesis/server.js:8:8)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
at startup (bootstrap_node.js:188:16)
at bootstrap_node.js:609:3
[nodemon] app crashed - waiting for file changes before starting...
[nodemon] restarting due to changes...
[nodemon] starting node server.js
Listening on port 3000...

If you get a code like this:

Error: The module '/home/dg/junesis/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 57. This version of Node.js requires
NODE_MODULE_VERSION 64. Please try re-compiling or re-installing
the module (for instance, using npm rebuild or npm install).
at Object.Module._extensions..node (internal/modules/cjs/loader.js:807:18)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/home/dg/junesis/node_modules/bcrypt/bcrypt.js:6:16)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/home/dg/junesis/server/controller/userController.js:2:16)
at Module._compile (internal/modules/cjs/loader.js:778:30)
[nodemon] app crashed - waiting for file changes before starting...

You need to run the following commands:
rm -rf node_modules/bcrypt
npm install

However, I happened to solve the problem using the below code in my entry file:
process
// Handle normal exits
.on('exit', (code) => {
nodemon.emit('quit');
process.exit(code);
})

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

Thanks to #1025 (comment)

ravikiranp123 · 2019-10-28T07:37:02Z

On windows stop "node.exe Node.js: Server-side JavaScript" processes.

Add on bottom of your js file, where you are starting server put this:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

You're welcome!

This Helped! Thanks!

Added process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); }) at the end of my js file on debian based distro and makes the issue go away.

jlippold · 2020-01-15T12:21:44Z

I'm hitting this same issue and I'm not 100% sure why but I just edited my start scripts to include a kill command.

This should work if your only using mac/*nix for development like I am, modify your start script to kill whatever is using the port on start like so:

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

3000 is the port youre using. | exit 0 silences an error if the port is not in use. The start command is now npm run kill & which kills and waits, then node ./node_modules/.bin/nodemon ./bin/www can be replaced with whatever you normally use to start your app.

einarpersson · 2020-02-04T16:35:54Z

I have never had this problem before but started getting it now all of the sudden. Ubuntu 18.04 "nodemon": "^2.0.2", node version 13.7.0.

Ratstail91 · 2020-02-22T16:15:02Z

I have never had this problem before but started getting it now all of the sudden. Ubuntu 18.04 "nodemon": "^2.0.2", node version 13.7.0.

Same here on both tools' versions. It seems this issue pops up periodically from a myriad of causes.

Since this thread seems to be the best source of info, I think it should be reopened.

Ratstail91 · 2020-02-22T16:34:53Z

Wait, hang on, nodemon is still running after I kill the process! I noticed after I tweaked a server file, and suddenly the pid appeared again. I'm running nodemon with concurrently, so I don't know if that makes any difference.

blex41 · 2020-02-24T10:15:26Z

I've been experiencing that problem for the past week on a new Hapi project. 4 times out of 5, I get the EADDRINUSE error when nodemon reloads.

But I cannot reproduce that error when working with older projects, using older versions of Hapi and the same version of nodemon (2.0.2). I cannot reproduce it either when creating a project from scratch with the same Hapi & nodemon versions as my new project. I'll try to investigate the cause, but it's not Hapi or nodemon themselves.

coachpacman · 2020-02-25T06:20:10Z

I have never had this problem before but started getting it now all of the sudden. Ubuntu 18.04 "nodemon": "^2.0.2", node version 13.7.0.

Same here on both tools' versions. It seems this issue pops up periodically from a myriad of causes.

Since this thread seems to be the best source of info, I think it should be reopened.

Yep, with @Ratstail91 - should be reopened.

hhsissi · 2020-02-27T22:59:12Z

Hi,

I got the same problem here, starting from today.
I'm using nodemon with ts-node (project developed using typescript)

I tried everthing below and NOTHING worked:

Reinstall node_modules
Switch node versions from 10 to 12 and 13 and alpine tags too.
Switch from nodemon 2.0.2 to 1.19
Prune docker volumes, networks, containers, images
Rebuild images from scratch.
Kill all node processes and everything running on 3000 using all kinds of techniques: lsof, pkill, kill, killall ...
Changing port from 3000 to others
Changing host from 0.0.0.0 to others
Restart my machine (Last solution situation)

The funny thing is I updated nodemon yesterday...
If you guys do have a solution, well I'm still here.

Message error is =>

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

And by the way, i have a weird socket file "3000" that is created on project directory, any hints on where that comes from ?

tosirisuk · 2020-03-17T14:14:15Z

I have never had this problem before but started getting it now all of the sudden. Ubuntu 18.04 "nodemon": "^2.0.2", node version 13.7.0.

Same here on both tools' versions. It seems this issue pops up periodically from a myriad of causes.

Since this thread seems to be the best source of info, I think it should be reopened.

I also face this issue on node from Docker Official Images.
However, only the docker container running on Mac OS, but not for Windows 10 host.

Charged101 · 2020-03-20T15:01:14Z

I'm also facing the same issue, I need to save the project 3/4 times in a row to get it working.

remy · 2020-03-20T15:42:29Z

Am locking this issue. It was based on 3 year old code, had a pr merge and fixed the source of the problem.

People posting more recently are experiencing similar symptoms but not the same source (plus there's never any info to replicate).

Will take a pr to fix these new issues. Thanks.

remy closed this as completed Dec 13, 2017

Repository owner locked as resolved and limited conversation to collaborators Mar 20, 2020

Nodemon frequently leaves the child process running (detached) #1025

Nodemon frequently leaves the child process running (detached) #1025

Comments

callumlocke commented May 10, 2017 • edited Loading

johnnydimas commented May 15, 2017 • edited Loading

hrgui commented May 16, 2017

hrgui commented May 19, 2017 • edited Loading

divmgl commented Jun 11, 2017

johnnydimas commented Jun 13, 2017

Extarys commented Jun 25, 2017

Jackclarify commented Sep 12, 2017 • edited Loading

erosenberg commented Sep 13, 2017

Extarys commented Sep 15, 2017

MickL commented Sep 18, 2017 • edited Loading

bermanboris commented Oct 2, 2017

Extarys commented Oct 3, 2017

bharathvaj-ganesan commented Oct 10, 2017

mikeesto commented Oct 11, 2017

hrgui commented Oct 11, 2017

endel commented Nov 6, 2017 • edited Loading

rowanD72 commented Nov 8, 2017

heisian commented Nov 17, 2017 • edited Loading

remy commented Nov 18, 2017

remy commented Nov 18, 2017

heisian commented Nov 20, 2017

heisian commented Nov 20, 2017

heisian commented Nov 20, 2017

VasilisKosmas commented Dec 8, 2017 • edited Loading

lzl124631x commented Dec 12, 2017

remy commented Dec 13, 2017

heisian commented Dec 13, 2017

remy commented Dec 13, 2017

O-Mutt commented Feb 18, 2019

bennycode commented Feb 18, 2019

MatteoGioioso commented Apr 20, 2019 • edited Loading

dehypnosis commented Apr 20, 2019 • edited Loading

workhan commented Apr 30, 2019

ypicard commented May 13, 2019

ziishaned commented May 13, 2019

mercem commented May 19, 2019

salehammar commented Jul 1, 2019

marcosgoncalves commented Jul 2, 2019

bennycode commented Jul 3, 2019

hondem commented Aug 15, 2019

Saman1962 commented Aug 17, 2019

RabiRoshan commented Aug 18, 2019

thinh105 commented Sep 27, 2019

doc82 commented Oct 11, 2019

remy commented Oct 11, 2019

denzilgupta commented Oct 16, 2019 • edited Loading

ravikiranp123 commented Oct 28, 2019 • edited Loading

jlippold commented Jan 15, 2020

einarpersson commented Feb 4, 2020

Ratstail91 commented Feb 22, 2020

Ratstail91 commented Feb 22, 2020 • edited Loading

blex41 commented Feb 24, 2020 • edited Loading

coachpacman commented Feb 25, 2020

hhsissi commented Feb 27, 2020

tosirisuk commented Mar 17, 2020 • edited Loading

Charged101 commented Mar 20, 2020

remy commented Mar 20, 2020

callumlocke commented May 10, 2017 •

edited

Loading

johnnydimas commented May 15, 2017 •

edited

Loading

hrgui commented May 19, 2017 •

edited

Loading

Jackclarify commented Sep 12, 2017 •

edited

Loading

MickL commented Sep 18, 2017 •

edited

Loading

endel commented Nov 6, 2017 •

edited

Loading

heisian commented Nov 17, 2017 •

edited

Loading

VasilisKosmas commented Dec 8, 2017 •

edited

Loading

MatteoGioioso commented Apr 20, 2019 •

edited

Loading

dehypnosis commented Apr 20, 2019 •

edited

Loading

denzilgupta commented Oct 16, 2019 •

edited

Loading

ravikiranp123 commented Oct 28, 2019 •

edited

Loading

Ratstail91 commented Feb 22, 2020 •

edited

Loading

blex41 commented Feb 24, 2020 •

edited

Loading

tosirisuk commented Mar 17, 2020 •

edited

Loading