CODEWITHSUNDEEP
node.jslibuv
mrose17
mrose17

Reputation: 91

best practices for debugging a node.js process?

my node.js server is getting a lot of EMFILEs and eventually aborts due to libuv being unable to create a kqueue(). so, i want to see what it's got open when that happens. i wrote the attached script which forks the server, waits for it to crash, and then runs 'lsof -p'.

my understanding from the docs is that when a fork'd child exits, it's kept around until a process.exit() occurs. that's good, because lsof will be able to interrogate the zombie's descriptors before it gets wiped:

var child_process = require('child_process')

child_process.fork('./index').on('close', function(code, signal) {
  var pid = this.pid;

  if (!!code) console.log('1: exit ' + code); else console.log('1: signal ' + signal);

  console.log('running lsof -p ' + pid);
  child_process.exec('lsof -p ' + pid, function(err, d) {
    if (!!err) { console.log('error:'); console.log(err); }
    if (!!d) console.log('data: ' + d.toString());
  });
}).on('error', function(err) {
  console.log(err.message);
  process.exit(1);
});

however, the call to exec() lsof always invokes the callback with an error parameter (something the lsof package never checks for):

1: signal SIGABRT
running lsof -p 85661
error: { [Error: Command failed: ] killed: false, code: 1, signal: null }

but, maybe i'm looking at this the wrong way. what are the best practices in this area?

Upvotes: 1

Views: 826

Answers (1)

isaacs
isaacs

Reputation: 17160

my understanding from the docs is that when a fork'd child exits

That is incorrect. What docs did you read, that we can help update to make it more clear?

Upvotes: 1

Related Questions