This repository has been archived by the owner. It is now read-only.

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

Closed
GeorgeBailey opened this Issue May 7, 2011 · 11 comments

Comments

Projects
None yet
8 participants

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 commented May 7, 2011

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

@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?

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.

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

@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.

Member

bnoordhuis commented Nov 24, 2012

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.

@bnoordhuis bnoordhuis closed this Nov 24, 2012

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.

Member

bnoordhuis commented Feb 6, 2013

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

...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.

@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.

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.