`npm run` + OSX -- error doesn't kill all processes

[nichoth]

I made a repo to demonstrate the issue:

https://github.com/nichoth/para-test

This is a common scenario for me—working on multiple modules that use the same port. In one terminal, run parallelshell "node server.js" "watchify ...". In a second terminal, run the same command, and the server emits an error but watchify still runs. This is using npm run scripts.

[pklingem]

+1 same issue here, have you had any luck working around this issue?

[nichoth]

It happens rarely enough I haven't tried fixing.

[keithamus]

As an aside, if you tell Node's HTTP server to .listen(0) it'll pick a random non-priveleged port to listen to, which you can then retrieve via .address().port - avoiding the error altogether. E.g.:

var http = require('http');
var server = http.createServer();
server.listen(0, function () {
  console.log('Listening on http://localhost:' + server.address().port);
})

The likely hood of it colliding on random ports is slim to none (but it can happen!)

[nichoth]

Nice tip

On Mon, Jun 22, 2015 at 3:31 AM, Keith Cirkel notifications@github.com
wrote:

As an aside, if you tell Node's HTTP server to .listen(0) it'll pick a
random non-priveleged port to listen to, which you can then retrieve via
.address().port - avoiding the error altogether. E.g.:

var http = require('http');var server = http.createServer();
server.listen(0, function () {
console.log('Listening on http://localhost:' + server.address().port);
})

—
Reply to this email directly or view it on GitHub
#22 (comment)
.

[pklingem]

@keithamus thanks for the reply. I don't think this solves my problem though. In my case I have three tasks that parallelshell executes, a js build task, a css build task and a serve task. The css build task is the one that seems to have the most problem being killed, it uses compass. Now that I say that, maybe compass is the problem. I'll do some more digging.

[keithamus]

This module is supposed to exit all children on the first non-zero exit code from any child - however it seems that managing child processes is a much trickier business than I imagined. In these cases I'd ask you have a rustle around and see if you can find out whats happening, and I'll try to take a stab at fixing it so this module works as it is supposed to.

[paulpflug]

@keithamus are you aware, that you didn't bump the version on npm since #14?

[keithamus]

Ahhh, nope, I didn't realise that. I've released 1.2.0 @paulpflug. Thanks for spotting that!

[keithamus]

@pklingem want to try 1.2.0 and see if the error you have is still occurring?

[pklingem]

Thanks for following up, will give it a try and report back.

On Sun, Jun 28, 2015, 10:47 AM Keith Cirkel notifications@github.com
wrote:

@pklingem https://github.com/pklingem want to try 1.2.0 and see if the
error you have is still occurring?

—
Reply to this email directly or view it on GitHub
#22 (comment)
.

[dkhuntrods]

First want to say thanks for this module and your posts detailing its raison d'etre. It's becoming an essential part of my workflow.
I was having a similar problem under similar circumstances and the update to 1.2.0 seems to have fixed it.

[keithamus]

Great 😄. If @nichoth and @pklingem can confirm that 1.2.0 is working for them, I'll close this issue and @paulpflug is owed a huge high five ✋

[nichoth]

I'm still having the same issue with version 1.2.0 using test repo https://github.com/nichoth/para-test & npm version 2.12.0.

[paulpflug]

looks like it is a problem of npm..
If I replace npm run watch with the content of the watch task it closes fine.

I could workaround by using node-posix and kill the process group from shell
spawn(sh,[shFlag,'kill -TERM -'+posix.getpgid(0)])

[keithamus]

Tasks like watch/watchify should be killing their sub-processes on SIGINT, we should investigate problems there further before drastic measures like adding (native!) submodules, IMO.

If I ^C the watch task manually, it closes fine without bugging out - my understanding is that Bash simply SIGINTs the focused process' PID, so that should be enough for us to do - right? Perhaps because we're wrapping it in multiple shells, something gets lost? parallelshell "npm run dev" where dev is watch file.js "npm run build" will spin up something in the order of 4 levels deep across 8 processes (sh for parallelshell, sh for npm run dev, sh for watch, sh for npm run build). It's no wonder this isn't an open-and-shut case 😓.