nodemon is leaving one node instance running when it exits? #185

Closed
tciuro opened this Issue Jun 15, 2013 · 28 comments

Comments

@tciuro

tciuro commented Jun 15, 2013

Hi Remy,

I launch nodemon like this:

Mac:webserv tito$ nodemon app.js 
15 Jun 13:05:08 - [nodemon] v0.7.8
15 Jun 13:05:08 - [nodemon] to restart at any time, enter `rs`
15 Jun 13:05:08 - [nodemon] watching: /Users/tito/Desktop/Tests/webserv
15 Jun 13:05:08 - [nodemon] starting `node app.js`
Express server listening on port 8080 in development mode

I can see two instances of node showing up in Activity Monitor (Mac OS X). If I terminate nodemon via Control-C, one instance is left behind. When I fire nodemon again I get the following:

Mac:webserv tito$ nodemon app.js 
15 Jun 13:07:10 - [nodemon] v0.7.8
15 Jun 13:07:10 - [nodemon] to restart at any time, enter `rs`
15 Jun 13:07:10 - [nodemon] watching: /Users/tito/Desktop/Tests/webserv
15 Jun 13:07:10 - [nodemon] starting `node app.js`
Caught exception: Error: listen EADDRINUSE

Is this expected? Is there anything I can do to make sure nodemon kills the two processes it created when it launched?

Thanks!

@remy

This comment has been minimized.

Show comment Hide comment
@remy

remy Jun 16, 2013

Owner

No, it's not expected behaviour. For some reason your child process isn't
terminating.

Can you post up a simplified version of your app.js that doesn't terminate
when you do ctrl+c?

On Saturday, June 15, 2013, Tito Ciuro wrote:

Hi Remy,

I launch nodemon like this:

Mac:webserv tito$ nodemon app.js
15 Jun 13:05:08 - [nodemon] v0.7.8
15 Jun 13:05:08 - [nodemon] to restart at any time, enter rs
15 Jun 13:05:08 - [nodemon] watching: /Users/tito/Desktop/Tests/webserv
15 Jun 13:05:08 - [nodemon] starting node app.js
Express server listening on port 8080 in development mode

I can see two instances of node showing up in Activity Monitor (Mac OS X).
If I terminate nodemon via Control-C, one instance is left behind. When I
fire nodemon again I get the following:

Mac:webserv tito$ nodemon app.js
15 Jun 13:07:10 - [nodemon] v0.7.8
15 Jun 13:07:10 - [nodemon] to restart at any time, enter rs
15 Jun 13:07:10 - [nodemon] watching: /Users/tito/Desktop/Tests/webserv
15 Jun 13:07:10 - [nodemon] starting node app.js
Caught exception: Error: listen EADDRINUSE

Is this expected? Is there anything I can do to make sure nodemon kills
the two processes it created when it launched?

Thanks!


Reply to this email directly or view it on GitHubhttps://github.com/remy/nodemon/issues/185
.

— Remy

Owner

remy commented Jun 16, 2013

No, it's not expected behaviour. For some reason your child process isn't
terminating.

Can you post up a simplified version of your app.js that doesn't terminate
when you do ctrl+c?

On Saturday, June 15, 2013, Tito Ciuro wrote:

Hi Remy,

I launch nodemon like this:

Mac:webserv tito$ nodemon app.js
15 Jun 13:05:08 - [nodemon] v0.7.8
15 Jun 13:05:08 - [nodemon] to restart at any time, enter rs
15 Jun 13:05:08 - [nodemon] watching: /Users/tito/Desktop/Tests/webserv
15 Jun 13:05:08 - [nodemon] starting node app.js
Express server listening on port 8080 in development mode

I can see two instances of node showing up in Activity Monitor (Mac OS X).
If I terminate nodemon via Control-C, one instance is left behind. When I
fire nodemon again I get the following:

Mac:webserv tito$ nodemon app.js
15 Jun 13:07:10 - [nodemon] v0.7.8
15 Jun 13:07:10 - [nodemon] to restart at any time, enter rs
15 Jun 13:07:10 - [nodemon] watching: /Users/tito/Desktop/Tests/webserv
15 Jun 13:07:10 - [nodemon] starting node app.js
Caught exception: Error: listen EADDRINUSE

Is this expected? Is there anything I can do to make sure nodemon kills
the two processes it created when it launched?

Thanks!


Reply to this email directly or view it on GitHubhttps://github.com/remy/nodemon/issues/185
.

— Remy

@nrvalliere

This comment has been minimized.

Show comment Hide comment
@nrvalliere

nrvalliere Jul 7, 2013

I'm seeing the same behavior on Windows 7 with a bare bones express app when running nodemon from a Cygwin terminal. If I run from a regular windows command prompt then it works ok.

I'm seeing the same behavior on Windows 7 with a bare bones express app when running nodemon from a Cygwin terminal. If I run from a regular windows command prompt then it works ok.

@kylekatarnls

This comment has been minimized.

Show comment Hide comment
@kylekatarnls

kylekatarnls Jun 20, 2014

I have the same when I do (on a debian):

echo `PORT=8000 nodemon index.coffee > /dev/null 2>&1 & echo $!` > /var/run/myapp.pid
kill -9 $(cat /var/run/myapp.pid)

nodemon exits but node stays.
But with Ctrl+C, no problem.

I have the same when I do (on a debian):

echo `PORT=8000 nodemon index.coffee > /dev/null 2>&1 & echo $!` > /var/run/myapp.pid
kill -9 $(cat /var/run/myapp.pid)

nodemon exits but node stays.
But with Ctrl+C, no problem.

@remy

This comment has been minimized.

Show comment Hide comment
@remy

remy Jun 20, 2014

Owner

@kylekatarnls by sending the 9 you're sending the SIGKILL signal, which "cannot be caught or ignored.". So nodemon has no time to clean up. You should only use SIGKILL for forceable kill processes. More appropriate is the SIGTERM or 15 to tell nodemon to shutdown.

Owner

remy commented Jun 20, 2014

@kylekatarnls by sending the 9 you're sending the SIGKILL signal, which "cannot be caught or ignored.". So nodemon has no time to clean up. You should only use SIGKILL for forceable kill processes. More appropriate is the SIGTERM or 15 to tell nodemon to shutdown.

@kylekatarnls

This comment has been minimized.

Show comment Hide comment
@kylekatarnls

kylekatarnls Jun 23, 2014

Thanks!

Thanks!

@bjmiller

This comment has been minimized.

Show comment Hide comment
@bjmiller

bjmiller Dec 17, 2014

I'm using OSX, and I'm getting this error intermittently. It seems that nodemon restarts the process a little too quickly sometimes. Maybe one out of 10+ times? It only started happening recently, but it's happening across multiple computers/projects.

I'm using OSX, and I'm getting this error intermittently. It seems that nodemon restarts the process a little too quickly sometimes. Maybe one out of 10+ times? It only started happening recently, but it's happening across multiple computers/projects.

@andyfleming

This comment has been minimized.

Show comment Hide comment
@andyfleming

andyfleming Nov 26, 2015

I'm experiencing something similar to @bjmiller on OS X.

I'm experiencing something similar to @bjmiller on OS X.

@kobenauf

This comment has been minimized.

Show comment Hide comment
@kobenauf

kobenauf Dec 6, 2015

Same here on WIndows 10 running from cygwin. Stopping nodemon leaves one node instance running. I noticed if I run from a cmd window instead it ends both processes correctly, but it would be much preferable for me to run from cygwin.

kobenauf commented Dec 6, 2015

Same here on WIndows 10 running from cygwin. Stopping nodemon leaves one node instance running. I noticed if I run from a cmd window instead it ends both processes correctly, but it would be much preferable for me to run from cygwin.

@vizo

This comment has been minimized.

Show comment Hide comment
@vizo

vizo Nov 27, 2016

Same here on Linux Ubuntu 16.04 in (cluster mode) when i do Ctrl-C

vizo commented Nov 27, 2016

Same here on Linux Ubuntu 16.04 in (cluster mode) when i do Ctrl-C

@ericsoco

This comment has been minimized.

Show comment Hide comment
@ericsoco

ericsoco Dec 15, 2016

I'm seeing the same on OSX, just started recently and don't have a clear repro.ctrl+c to kill the process, but sometimes it's lingering in the background. Specifically, I'm watching files and when I change them via other scripts, all of a sudden my rebuild process kicks off because the nodemon background process sees the changes. Took me a bit to understand what was happening, though I'm still not clear on why.

v 1.11.0 on OSX 10.12.1 Sierra.

ericsoco commented Dec 15, 2016

I'm seeing the same on OSX, just started recently and don't have a clear repro.ctrl+c to kill the process, but sometimes it's lingering in the background. Specifically, I'm watching files and when I change them via other scripts, all of a sudden my rebuild process kicks off because the nodemon background process sees the changes. Took me a bit to understand what was happening, though I'm still not clear on why.

v 1.11.0 on OSX 10.12.1 Sierra.

@killroy42

This comment has been minimized.

Show comment Hide comment
@killroy42

killroy42 Dec 15, 2016

I've experienced this for a while. Sometimes I end up with 10-20 node.exe and cmd.exe processes in my process list that I have to kill manually.

I've experienced this for a while. Sometimes I end up with 10-20 node.exe and cmd.exe processes in my process list that I have to kill manually.

@petr001

This comment has been minimized.

Show comment Hide comment
@petr001

petr001 Dec 20, 2016

the same issue here 🙁

petr001 commented Dec 20, 2016

the same issue here 🙁

@theninj4

This comment has been minimized.

Show comment Hide comment
@theninj4

theninj4 Mar 5, 2017

I can reliably reproduce this:

First up, in the code we're monitoring, bind to a TCP port, and bind to the SIGUSR2 signal:

process.on('SIGUSR2', () => { })

Second, create a .nodemon file to use a different process signal (we're using SIGUSR2):

{
  "signal": "SIGHUP"
}

Third, start nodemon and kick it into the background:

nodemon --config ./nodemon.json --watch . server.js &

From this point, here's the process tree:

$ ps
PID   USER     TIME   COMMAND
    1 root       0:00 sh
    6 root       0:00 node /usr/bin/nodemon --config ./nodemon.json --watch . serv
   20 root       0:00 sh -c node server.js
   21 root       0:00 node server.js

Modify a file, let nodemon restart things, you'll get an error about trying to bind to TCP we're using, the new process will die and it'll sit waiting for changes before it brings up another process.

Viewing the process tree at this point shows we successfully killed PID 20, but it didn't propagate to PID 21, which is our NodeJS process:

$ ps
PID   USER     TIME   COMMAND
    1 root       0:00 sh
    6 root       0:00 node /usr/bin/nodemon --config ./nodemon.json --watch . serv
   21 root       0:00 node server.js

I'm guessing there are some edge cases whereby nodemon deviates from the .nodemon config?

theninj4 commented Mar 5, 2017

I can reliably reproduce this:

First up, in the code we're monitoring, bind to a TCP port, and bind to the SIGUSR2 signal:

process.on('SIGUSR2', () => { })

Second, create a .nodemon file to use a different process signal (we're using SIGUSR2):

{
  "signal": "SIGHUP"
}

Third, start nodemon and kick it into the background:

nodemon --config ./nodemon.json --watch . server.js &

From this point, here's the process tree:

$ ps
PID   USER     TIME   COMMAND
    1 root       0:00 sh
    6 root       0:00 node /usr/bin/nodemon --config ./nodemon.json --watch . serv
   20 root       0:00 sh -c node server.js
   21 root       0:00 node server.js

Modify a file, let nodemon restart things, you'll get an error about trying to bind to TCP we're using, the new process will die and it'll sit waiting for changes before it brings up another process.

Viewing the process tree at this point shows we successfully killed PID 20, but it didn't propagate to PID 21, which is our NodeJS process:

$ ps
PID   USER     TIME   COMMAND
    1 root       0:00 sh
    6 root       0:00 node /usr/bin/nodemon --config ./nodemon.json --watch . serv
   21 root       0:00 node server.js

I'm guessing there are some edge cases whereby nodemon deviates from the .nodemon config?

@theninj4

This comment has been minimized.

Show comment Hide comment
@theninj4

theninj4 Mar 9, 2017

I found my issue above - my container didn't contain the nodemon.json config file. Adding the file to the container fixed the issue.

theninj4 commented Mar 9, 2017

I found my issue above - my container didn't contain the nodemon.json config file. Adding the file to the container fixed the issue.

@Ankiewicz

This comment has been minimized.

Show comment Hide comment
@Ankiewicz

Ankiewicz Apr 2, 2017

how do you kill nodemon when it wont shut off?

how do you kill nodemon when it wont shut off?

@eduardrock

This comment has been minimized.

Show comment Hide comment
@eduardrock

eduardrock Aug 3, 2017

Same here. When I Ctrl+C or get an error on node, it leaves a process running when it's stopped on console. So I have to kill it manually every time.

Same here. When I Ctrl+C or get an error on node, it leaves a process running when it's stopped on console. So I have to kill it manually every time.

@juan-carlos-correa

This comment has been minimized.

Show comment Hide comment
@juan-carlos-correa

juan-carlos-correa Aug 13, 2017

How can we resolve this issue?

How can we resolve this issue?

@andyfleming

This comment has been minimized.

Show comment Hide comment
@andyfleming

andyfleming Aug 14, 2017

Here's my workaround:

Setup

npm uninstall -g nodemon
npm install -g pm2

Workflow

pm2 start --watch . --name=my-process index.js
pm2 logs my-process

Works great. Problem solved.

Here's my workaround:

Setup

npm uninstall -g nodemon
npm install -g pm2

Workflow

pm2 start --watch . --name=my-process index.js
pm2 logs my-process

Works great. Problem solved.

@juan-carlos-correa

This comment has been minimized.

Show comment Hide comment
@juan-carlos-correa

juan-carlos-correa Aug 14, 2017

@andyfleming thanks! that's nice option (y)

@andyfleming thanks! that's nice option (y)

@DiegoRBaquero

This comment has been minimized.

Show comment Hide comment
@DiegoRBaquero

DiegoRBaquero Nov 4, 2017

I can't believe this is still not fixed.

I can't believe this is still not fixed.

@remy

This comment has been minimized.

Show comment Hide comment
@remy

remy Nov 4, 2017

Owner

@DiegoRBaquero happy to look at tests and a PR to merge if you can point me in its direction.

Owner

remy commented Nov 4, 2017

@DiegoRBaquero happy to look at tests and a PR to merge if you can point me in its direction.

@heisian

This comment has been minimized.

Show comment Hide comment
@heisian

heisian Nov 17, 2017

Contributor

@remy Glancing at the code (and literally a 5-second glance) I see you have spawn.js and call child_process.spawn.

This is fine for non-node executables, but when running a node child process specifically, fork should be used. You get the benefits of IPC as well as automatic garbage collection when the parent dies.

I would suggest having a switch to use child_process.fork whenever a .js file is being run, or when the executable is node.

Contributor

heisian commented Nov 17, 2017

@remy Glancing at the code (and literally a 5-second glance) I see you have spawn.js and call child_process.spawn.

This is fine for non-node executables, but when running a node child process specifically, fork should be used. You get the benefits of IPC as well as automatic garbage collection when the parent dies.

I would suggest having a switch to use child_process.fork whenever a .js file is being run, or when the executable is node.

@heisian

This comment has been minimized.

Show comment Hide comment
@heisian

heisian Nov 17, 2017

Contributor

@remy here's my PR to fix the issue:
#1134

I'm guessing you'll edit it to be more consistent with the rest of the script but the concept is there, and I no longer get an Error [ERR_IPC_CHANNEL_CLOSED]: channel closed when the parent process dies because node automatically handles cleanup of forked child processes.

You might also need to do some work with the stdout/stderr, since in my code the child process is just using whatever fork defaults to.. like [0, 1, 2, 'ipc'] or something.

But hopefully this is the direction you were looking for :]

Contributor

heisian commented Nov 17, 2017

@remy here's my PR to fix the issue:
#1134

I'm guessing you'll edit it to be more consistent with the rest of the script but the concept is there, and I no longer get an Error [ERR_IPC_CHANNEL_CLOSED]: channel closed when the parent process dies because node automatically handles cleanup of forked child processes.

You might also need to do some work with the stdout/stderr, since in my code the child process is just using whatever fork defaults to.. like [0, 1, 2, 'ipc'] or something.

But hopefully this is the direction you were looking for :]

@remy

This comment has been minimized.

Show comment Hide comment
@remy

remy Dec 13, 2017

Owner

@heisian I need to revert this change for nodemon@1.x but it'll go in as part of nodemon@2.0.0 - because it doesn't work with node@4 (in tests/config/env.js), but I'm dropping support for node@4 in nodemon@2 (I accidentally did it in 1.12.3 but it should have been a major bump).

Owner

remy commented Dec 13, 2017

@heisian I need to revert this change for nodemon@1.x but it'll go in as part of nodemon@2.0.0 - because it doesn't work with node@4 (in tests/config/env.js), but I'm dropping support for node@4 in nodemon@2 (I accidentally did it in 1.12.3 but it should have been a major bump).

@remy

This comment has been minimized.

Show comment Hide comment
@remy

remy Dec 14, 2017

Owner

All live in latest nodemon (in nodemon@1.x - I pushed a workaround for node@4 which uses spawn).

Owner

remy commented Dec 14, 2017

All live in latest nodemon (in nodemon@1.x - I pushed a workaround for node@4 which uses spawn).

@remy remy closed this Dec 14, 2017

@heisian

This comment has been minimized.

Show comment Hide comment
@heisian

heisian Dec 15, 2017

Contributor

@remy Okay. Looking at the child_process.fork history, the stdio option was only introduced in v6.4.0, so that may be the reason.

Contributor

heisian commented Dec 15, 2017

@remy Okay. Looking at the child_process.fork history, the stdio option was only introduced in v6.4.0, so that may be the reason.

@angularturk

This comment has been minimized.

Show comment Hide comment
@angularturk

angularturk Feb 21, 2018

Also command below works fine;

pm2 start npm --watch --name=myapp -- start
pm2 logs myapp

angularturk commented Feb 21, 2018

Also command below works fine;

pm2 start npm --watch --name=myapp -- start
pm2 logs myapp

@heisian

This comment has been minimized.

Show comment Hide comment
@heisian

heisian Feb 21, 2018

Contributor

@angularturk that's a completely different module and doesn't provide any utility to this thread.

Contributor

heisian commented Feb 21, 2018

@angularturk that's a completely different module and doesn't provide any utility to this thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment