Babel-watch not killing the app on SIGINT

[Debove Christopher]

babel-watch v2.0.7

Action: Spawn babel with node, then try to kill it with SIGINT.
Expected: The app should be killed
Current: The app is not kill and the child process is running

Context: I was spawning a babel-watch on a app to start my server with a webpack-dev-middleware, and when I sent a signal to babel-watch to kill it, the webpack watchers continued running.
When restarting the babel-watch process, I got a EADDRINUSE which lead me to spot this bug.

Solution:
In babel-watch.js, add killApp() when receiving SIGINT signal.

process.on('SIGINT', function() {
  watcher.close();
  killApp();
  process.exit(1);
});

[Debove Christopher]

Up ?

[Aaron Craig]

This is still an issue, AFAICT.

A quick repro is to start babel-watch with a missing dependency, for instance:

import idonotexist from 'missing-dependency';

function main() {
  console.log('You should not see this message');
}

main();

The babel-watch process will die due to the missing dependency, however the process will not end. After ctrl-C is hit, the process will be killed, but ps xa | grep node will reveal that the child process is still active.

After a few of these, the child processes (which on my machine are using 90-100% CPU) will gradually eat your CPU resources. I only noticed this because my laptop fan started going crazy.

[Samuel Reed]

Thanks @aaroncraigongithub.

This was fixed in e02dcc7, many months ago, but I do not have npm access so I am unable to publish. @kmagiera, I have asked a few times, could you please add me to npm publishers for babel-watch?

[paulo.digital]

Still a problem, happening all time, the year is 2020.

[Samuel Reed]

Yes. I am thinking to just fork the package on npm at this point. We've had a few conversations but they never resolve.

[Prasanna Reddy]

Yes. Still problem exists

[Samuel Reed]

I have been working today with @kmagiera to get publish access, hopefully will be done soon, in which case I will publish 7.1 and update all the stale tickets.

[Samuel Reed]

Finally published in 7.1.0!

[Deleted user]

This problem still persists in babel-watch 7.4.1, possible regression?

[Samuel Reed]

I've seen it too. I don't think it's a regression but possibly another bug. If you can replicate it consistently please open a new issue, and try sending SIGUSR1 to the process so you can attach a debugger and see what code is doing it.

[John Cullen]

I'm still getting this issue repeatedly. I spent a day messing around with it and gave up. If you're getting this with docker-compose, I'd recommend just switched over to using nodemon --exec babel-node src.

[BobBatard]

The issue seems to come from the killApp function which calls restartOnce which in turns calls restartAppInternal, which results in forking a new runner.
killApp is called on SIGINT before closing the main process, but the runner is never closed in that case.
Adding a parameter noRestart to killApp function killApp(noRestart) and prevent the call to restartOnce on SIGINT solves the problem on my machine, but I couldn't tell if it has side effects
In killApp
if(!noRestart) restartOnce();

process.on('SIGINT', function() {
  debugInit('SIGINT caught, closing.');
  watcher.close();
  killApp(true);
  process.exit(0);
});

[Samuel Reed]

Thanks for trying to chase this down. It's hard to replicate the issue happening which makes it difficult to fix. Have you managed to reliably replicate it so we can squash it for good?

[BobBatard]

Just starting my app and immediately throwing an error is enough to provoke the bug every time on my machine.
I'm on osx with node 14.17.3

[Samuel Reed]

@BobBatard can you see if the latest master fixes your issue?

[BobBatard]

Yes I can confirm it's working as intended now !
Thanks for your reactivity :)

[Samuel Reed]

Great. Published in 7.6.0.