nodemon can not be stopped by Ctrl-C with --no-stdin after restart with terminal in raw mode
anonghuser opened this issue · comments
nodemon -v: 3.0.1
on Linux
Simplest test.js file:
process.stdin.setRawMode(true)
setTimeout(()=>{}, 5000)
command: nodemon -I test.js
Naturally, while the test script is running, ctrl-c does nothing because the terminal is in raw mode. This is not what the issue is about. Instead, the issue is about ctrl-c after the test script has exited back to nodemon and it prints its [nodemon] clean exit - waiting for changes before restart message.
If you wait for the 5 seconds to pass and the process to exit normally, ctrl-c will properly interrupt nodemon. This works even if the process is restarted due to code changes, as long as the restarts all happen after the process has exited cleanly, i.e. with at least 5 seconds between them.
But if at least once you trigger a restart via a code change while the process is still running, i.e. before the 5 seconds that it waits, you are no longer able to interrupt nodemon.
This issue impacts use of readline-based interactive apps with nodemon, i.e. any app making use of the repl built-in module, including node's own interactive mode. So you can reproduce it even without a test script, i.e.:
nodemon -I -x "node "
(for some reason nodemon throws a fit if you try to --exec node, thus the extra space)
(you still need to change some js file in the current directory to trigger the restarts)
PSA: To exit nodemon when this happens to you (or when triggering it on purpose for debugging) you can kill it from another terminal with pkill -f nodemon. Hopefully you don't have other important things with "nodemon" in their command line 😛
PSA: Another workaround is to use SIGTERM or SIGINT instead of the default to restart your app, i.e.:
nodemon -s sigterm -I test.js
This works because the default SIGTERM and SIGINT handlers in node programs restore the terminal mode before exiting. It would not work when the handlers are overridden and exit without restoring the terminal mode though.
Weirdly enough, the documentation for I misread it, it just gave SIGTERM as an example, it did not claim it was the default.--signal in nodemon --help options says the default is SIGTERM so it should've worked by default. But apparently the documentation is wrong.
This may or may not be related, but sometimes when running my repl app in nodemon, I get a weird behavior where my input is not always registered by my app. Some keystrokes don't reach my app, and some do, randomly and unpredictably.
It's a bit as if two processes are reading from stdin (if that's even possible) and it's a cointoss if the input will reach the correct one. However, I'm not sure of the reproduction steps and such, so I've not reported it yet.
PSA: Another workaround is to use SIGTERM or SIGINT instead of the default to restart your app, i.e.:
nodemon -s sigterm -I test.jsThis works because the default SIGTERM and SIGINT handlers in node programs restore the terminal mode before exiting. It would not work when the handlers are overridden and exit without restoring the terminal mode though.
Weirdly enough, the documentation forI misread it, it just gave SIGTERM as an example, it did not claim it was the default.--signalinnodemon --help optionssays the default is SIGTERM so it should've worked by default. But apparently the documentation is wrong.
This worked for me nodemon see's the app "crashed" on ctrl+c (app exit(0)). This puts nodemon in watch mode to wait for changes before restarting where I can now ctrl+c again to exit nodemon.
This works well enough for me as it lets me kill the app without exiting nodemon entirely.
This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3
idk how long should i bump...
This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3
Automatically closing this issue due to lack of activity