I've got some code that looks very much like the sample in the Cluster documentation at http://nodejs.org/docs/v0.6.0/api/cluster.html, to wit:
var cluster = require('cluster');
var server = require('./mycustomserver');
var numCPUs = require('os').cpus().length;
if (cluster.isMaster) {
var i;
// Master process
for (i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('death', function (worker) {
console.log('Worker ' + worker.pid + ' died');
});
} else {
// Worker process
server.createServer({port: 80}, function(err, result) {
if (err) {
throw err;
} else {
console.log('Thread listening on port ' + result.port);
}
});
}
I've installed node-inspector and tried using both it and the Eclipse V8 plugin detailed at https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Applications-Debugger to debug my application, but it looks like I can't hook a debugger up to forked cluster instances to put breakpoints at the interesting server logic--I can only debug the part of the application that spawns the cluster processes. Does anybody know if I can in fact do such a thing, or am I going to have to refactor my application to use only a single thread when in debugging mode?
I'm a Node.js newbie, so I'm hoping there's something obvious I'm missing here.
var fixedExecArgv=[];
fixedExecArgv.push('--debug-brk=5859');
cluster.setupMaster({
execArgv: fixedExecArgv
});
Credit goes to Sergey's post.
I changed my server.js
to fork only one worker mainly for testing this then added the code above the forking. This fixed the debugging issue for me. Thank you Sergey for explaining and providing the solution!!!
I already opened a ticket about this here: https://github.com/dannycoates/node-inspector/issues/130
Although it's not fixed yet, there's a workaround:
FWIW: The reason I suspect is that the node debugger needs to bind to the debug port (default: 5858). If you are using Cluster, I am guessing the master/controller binds first, and succeeds, causing the bind in the children/workers to fail. While a port can be supplied to node --debug=N there seems to be no easy way to do this when node is invoked within Cluster for the worker (it might be possible to programmatically set process.debug_port and then enable debugging, but I haven't got that working yet). Which leaves a bunch of options: 1) start node without the --debug option, and once it is running, find the pid for the worker process you want to debug/profile, and send it a USR1 signal to enable debugging. Another option is to write a wrapper for node that calls the real node binary with --debug set to a unique port each time. There are possibly options in Cluster that let you pass such as arg as well.
For those who wish to debug child processes in VS Code, just add this to launch.json configuration:
"autoAttachChildProcesses": true
https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_remote-debugging
For anyone looking at this in 2018+, no startup arguments are necessary.
From this Github issue:
Just a time saver for anyone who might have been in the same boat as me-- the Node.js V8 --inspector Manager (NiM) seems to introduce this issue when it otherwise wouldn't be present-- I spent about an hour banging my head before disabling the Chrome plugin and discovering that everything worked fine when opening from chrome://inspect.
I also spent hours reading github posts, tweaking the settings of gulp-typescript and gulp-sourcemaps, etc, only to have that plugin be the issue. Also worth noting is that I had to add port N+1 to the remote targets of chrome://inspect
, so localhost:9230
, to debug my worker process.
if you use VSCode to debug, you need to specify the port and and "autoAttachChildProcesses": true
in the lanuch.json file.
If you debug directly in DevTool, you need to add a connection to the corresponding port in the console.
Use the --inspect
flag for node version higher than or equal to 7.7.0 to debug the node js process,
if someone wants more information on how to debug cluster processing and setting up chrome debugger tools for Node JS, please follow my post here.