Home » Nodejs » Debugging Node.js processes with cluster.fork()

Debugging Node.js processes with cluster.fork()

Posted by: admin November 30, 2017 Leave a comment

Questions:

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.

Answers:
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!!!

Questions:
Answers:

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.