babel-node: ctrl-c doesn't kill runaway node process

[Macil]

$ echo 'while(true)console.log(1)' >test.js
$ node test.js
1
1
1
^C
$

$ babel-node --version
4.7.16
$ babel-node test.js
1
1
1
^C $1
1
1
1

I'm dumped back to the shell, but the program is still running simultaneously. I have to do killall node to fix it.

Usually when I accidentally make infinite loops, they're not printing anything, so I only later realize I have a bunch of extra node processes still around hogging CPU when my laptop starts heating up.

[monsanto]

@agentme be sure to install the package kexec, babel-node signal handling will not work correctly without it. Unless something has changed recently, the version of kexec you need will depend on the version of io.js/node you are using.

kexec used to be an optional dependency in package.json but was removed because it confused Windows users and because of the version problems mentioned above.

[Macil]

I'm on OS X and using node 0.10.36 still if it matters. I've installed kexec globally now. I can now fully kill babel-node with ctrl-, though during an infinite loop, now ctrl-C does nothing but add "^C" to the terminal, without killing anything. Not really an issue for me, though it is odd.

[monsanto]

@agentme I can't reproduce this on iojs/Linux. Can you do me a favor and tell me if BABEL_DISABLE_CACHE=1 babel-node <your args> can be killed with Ctrl-C? Also, do you have any SIGINT handlers in your code?

[Macil]

No SIGINT handlers in my code; the issue happens for me with even just a simple while(true){} loop.

BABEL_DISABLE_CACHE=1 fixes ctrl-C for me.

[monsanto]

Ah, you are using a while(true) {} loop. I can reproduce this with that.

Tagging @sebmck; Here is my guess at what is happening: Babel's cache manager adds a SIGINT handler. With an infinite while loop, the event loop is starved and the SIGINT callback Babel adds is never called. Without the SIGINT handler (BABEL_DISABLE_CACHE), that signal is handled in node itself which does not have the same restrictions that a userland SIGINT handler has.

Fixing this would require upstream help. My suggestion is to workaround the problem and save the cache data at some point other than a SIGINT handler.

[sebmck]

@monsanto Yep, that's exactly right. There isn't really any other place to save it other than in SIGINT since it needs to be saved on program exit and a timer isn't practical.

[monsanto]

@sebmck when you modify the cache, queue a save() for the next tick (unless it is already queued). Virtually all module loading will be done in the first tick, so this should make no difference in performance.

[fzaninotto]

kexec being broken on Node v4, this issue is a blocker. Isn't there anything that babel can do on its own?

[loganfsmyth]

@fzaninotto kexec appears to have released a new version to address the Node 4 issues.

[fzaninotto]

confirmed, kexec now installs properly in Node 4.

That being said, I suggest you add it as a recommended dependency, and make it more obvious that it's required for running babel-node.