Feature Request: Tool to see why process is still running?

[GeorgeBailey]

Explained here http://stackoverflow.com/questions/5916066/node-js-tool-to-see-why-process-is-still-running

Is there a way to see what timeouts, intervals or async operations (or endless loops) are still running and are stopping my process from ending?

I have been able to figure it out so far without such a tool, but such a tool would be very handy especially as the Node.JS projects here start to get bigger.

I am thinking of Java's kill -3 which prints a stack trace to stderr. You can do this for any process, any time, debug or no. I would like an equivalent for Node.JS. (I know that node is single threaded with async so it would output differently)

[ry]

That's a neat idea - sending some signal to the node process will make it list its libev watchers. The problem is there are so many things I'd like to do to a Node process besides listing the watchers - and there are so few signals...

Here is the call to walk the watchers: https://github.com/joyent/node/blob/4cc0a0878fb0b31547c9a8d27e31f1daceb49524/deps/libev/ev.h#L598

[GeorgeBailey]

@ry: Is there a list of things to do with the signals accompanied by the list of signals? So far, the only things I can think of wanting a signal for are heap dump and what I have just mentioned, and of course the default kill and kill -9. What other signals are there that risk filling the (11?) blanks?

Actually, if this can be accomplished with a listener in my code then I would be perfectly happy. Just let me know what JavaScript to put in the signal listener if that is possible. Is this possible?

[jhurliman]

It would be nice if https://github.com/tlrobinson/long-stack-traces/ could be combined with some code that walked all of the current watchers to produce a list of sleeping (long) stack traces.

[jhurliman]

I implemented a process.watchers() method that adds exactly this: #1532

[trevnorris]

@bnoordhuis mind referencing the similar feature in the works you mentioned in #1532? If there's already an issue open for that, then seems this one can be closed.

[bnoordhuis]

mind referencing the similar feature in the works you mentioned in #1532?

It's the process._getActiveHandles() and process._getActiveRequests() functions. They're not documented but they're there for people that want to use them.

[TeeTeeHaa]

I need a solution for the "why is my process still running" problem, too, and while I already use process._getActiveHandles() and process._getActiveRequests() I really have a hard time finding out which parts of my code cause the whole mess. Probably I am by far not the only one with that problem so I really support this feature request for a simple and informative tool which neither is undocumented nor still requires good debugging skills for the inner workings of node.js.

[bnoordhuis]

That will eventually come but intuitive, fool-proof debugging is surprisingly complex and time consuming to implement. Ditto for profiling.

[TeeTeeHaa]

...and you are a pro on the matter. Most of us node.js users aren't (yet).

I've created a gist with a minimalistic test case demonstrating my current problem:
https://gist.github.com/TeeTeeHaa/4730166

Nevertheless thank you for your attention on this.

[vincentwoo]

@bnoordhuis Ben, I just want you to know that I found this thread a year after you made your comment about the process._getActiveHandles() functions. These have saved my bacon after about a day of head-banging. Basically, I just wanted to have something like 'onexit' that would still let me schedule work, and your tipoff was enough to let me cobble together a solution. Thank you.

[fresheneesz]

This module is super helpful for figuring out what's keeping node alive: https://github.com/mafintosh/why-is-node-running