We can start debugger in nodejs using kill -USR1 PID. How can we disable it using any signal or any other way without terminating the worker?
Reference - https://nodejs.org/en/docs/guides/debugging-getting-started/#enable-inspector
While SIGUSR1 is used to start the debug inspector (equivalent to running node with the --inspect flag), you can customize SIGUSR2 to close the inspector without killing the process.
Adding something like this to your main app should add that behavior.
const inspector = require('inspector');
process.on('SIGUSR2', () => {
console.log('Received SIGUSR2. Closing inspector.');
inspector.close();
});
https://nodejs.org/api/inspector.html#inspector_inspector_close
Related
To debug a Node.js process, I use:
node --inspect-brk foo_bar.js
But what if that instance would start another, separate instance, and this one would be - how to run that instance in debug mode as well?
The problem is, I am using the commander.js library for Node.js, like so:
var program = require('commander')
...
program.parse(process.argv)
This creates another instance of Node.js process, and hence I lose the debug functionality (I am debugging via Chromium browser). How can I overcome this?
Note: Commander only creates another process if you implement the subcommand using a stand-alone executable.
Commander detects debugger options being passed to the node invocation, and passes them to the subprocess with the debugging port incremented by 1.
e.g.
// index.js
const { program } = require('commander');
program
.command('sub', 'stand-alone');
console.log('1');
console.log('2');
program.parse();
// index-sub.js
console.log('3');
console.log('4');
% node --inspect-brk index.js sub
Debugger listening on ws://127.0.0.1:9229/25005682-6bf4-44fb-bdb2-2cc7749bb328
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
1
2
Debugger listening on ws://127.0.0.1:9230/00d1924a-3122-4bef-86f2-65d562fbf3ed
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
3
4
I cannot start debugger in WebStorm using tesseract.js. The error is:
Starting inspector on 127.0.0.1:58767 failed: address already in use
events.js:174
Running is working correctly. Could you help me to debug?
This is an issue with tesseract.js - it doesn't pass execArgv to the child process when spawning it. child_process.fork() accepts a execArgv option that defaults to process.execArgv when omitted - as a result, the debugger for a child process is started on the same port as the parent process debugger, causing EADDRINUSE. See https://github.com/naptha/tesseract.js/issues/66,
https://github.com/naptha/tesseract.js/issues/102
i'm starting a background process (on windows) from electron main, something like this:
app_exe = require("child_process").spawn(
"app.exe" ,
[ "--params", ... ],
{ stdio: "ignore" }
);
this works fine, i can see this from process explorer:
but i cannot kill the process when the electron is closed ( .on("closed") or on("window-all-closed") )
i tried child.kill([signal]), but also tree-kill or taskkill with no results: only the first process (6036 from the example) is killed, the second (5760) remains stale.
also exec taskkill /F /T /PID doesn't kill it.
the only way to kill is exec taskkill /F /IM app.exe /T, but in this way i cannot run two instances of the electron app.
i'm missing something obvious on process management on windows?
I was seeing a similar issue on Windows 7 machines. I believe newer OS' will automatically kill the child processes.
What I had to do was to just save off the PID of the spawned-process and send it a SIGTERM message to kill it when all the windows closed. Now, if there's a chance that the process died by other means before the Electron app shut down, the OS may have recycled the child process' PID, so for extra robustness, I used the find-process npm module to make sure that the PID that I held on to is associated with the correct process.
const proc = cp.spawn("app.exe");
app.on("window-all-closed", async () => {
const list = await require("find-process")("pid", proc.pid);
app.quit();
if (list[0] && list[0].name.toLowerCase() === "app.exe")
process.kill(proc.pid);
});
Now if your Electron app does not exit gracefully (and the above code isn't run), you'd have to rely on another technique.
If you control the child process that you're spawning, you can try to kick off a thread that listens to or pings the main process. If it doesn't see the main process, it can kill itself.
If you don't control the spawned-app, then I'm out of ideas, but the above code will handle most cases.
I had exactly the same issue, and no question / answer on the forums could resolve that problem. So after some research i've found a simple workaround and im sharing it :
// Workaround to close all processes / sub-processes after closing the app
electron.app.once('window-all-closed', electron.app.quit);
electron.app.once('before-quit', () => {
window.removeAllListeners('close');
});
And its working perfectly for me, hope it does for you.
You can try it with this code:
ipcMain.on('exampletab:close', () => {
ipcMain.removeAllListeners();
exampleWindow.close();
});
This code save my lot of time. When you close your child window, then use removeAllListeners() to remove Previous closed Windows.
The process, as it is:
start code with --debug --inspect:
"debug": "node --max-old-space-size=8192 --debug=5567 --inspect dist/index.js",
Open devtools with url provided, something like:
chrome-devtools://devtools/remote/serve_file/#62cd277117e6f8ec53e31b1be58290a6f7ab42ef/inspector.html?experiments=true&v8only=true&ws=localhost:9229/node
Do some debugging.
Realize you have a bug, kill process (Ctrl-C) and make code changes.
Restart.
Start fails: Unable to open devtools socket: address already in use
Realize that you have to manually refresh the chrome-devtools page to get it to realize the process is no longer available.
Node inspector was much better about this. Is there something I'm missing? Some flag that will make the chrome-devtools automatically detach from a process that has stopped?
$ versions
npm 3.10.3
node v6.7.0
OS Darwin 15.6.0 Darwin Kernel Version 15.6.0
edit: I started using Node Inspector Manager (Chrome extension) and found that this whole process went much better.
I don't have that problem, chrome-devtools shows me a message that the debugging connection was closed when I Ctrl-C the node process.
What system are you running on? Maybe that's something that's been fixed in a newer Node or Chrome version? Or maybe you have something in your Node app that prevents proper shutdown of the socket. Can you try with a simple script instead?
jcollum here (user835611 should get the answer credit, since they tipped me off):
I had two listeners for the process termination signals:
process.on('SIGINT', function() {
logger.warn('SIGINT received. Shutting down.');
return process.exit(0);
});
process.on('SIGTERM', function() {
logger.warn('SIGTERM received. Shutting down.');
return process.exit(0);
});
Turns out those were blocking chrome's dev tools from seeing the shutdown. I don't know how that would work but that's what I observed. Commenting out process.exit made no change. How odd, it seems that having a listener on the SIGTERM / INT events blocks Chrome's dev tools from seeing that the process has exited. Never seen a side effect like that from an event listener.
I am trying to debug the child_process example from here using IntelliJ IDEA 12.1.3 and node 10.10. When I run nodejs app.js from a terminal everything works. The console output displays as expected. However, when I debug the same script using IDEA there are no messages in console output and the app just sits there. This is what is in the console window:
/usr/bin/nodejs --debug-brk=58954 app.js
debugger listening on port 58954
debugger listening on port 58954
When I run the script in IDEA without the debugger attached, the script works as expected.
Why does attaching the debugger break the script?
You can force the children to use a free port for debugging. InteliJ will automatically pick up the port chosen by the child process.
Here's an example:
// Determine if in debug mode.
// If so, pass in a debug-brk option manually, without specifying port.
var startOpts = {};
var isInDebugMode = typeof v8debug === 'object';
if(isInDebugMode) {
startOpts = {execArgv: ['--debug-brk']};
}
child_process.fork('./some_module.js', startArgs, startOpts);
looks like a bug in node.js fork to me: both parent and child processes receive --debug-brk=58954 switch and attempt to start debugger and listen port 58954.