See what is keeping the event loop alive

597 views
Skip to first unread message

bill.w...@lmco.com

unread,
Jan 23, 2015, 2:22:36 PM1/23/15
to nod...@googlegroups.com
Is there any way in node.js 0.10.x to see what is keeping the event loop still alive/running?  I have an app which used to shut down cleanly but now is hanging, so there must be a timer, socket, etc. still active, but it is not apparent where.  This post https://groups.google.com/d/msg/nodejs/Nn-j_a7ZfTc/JnUAiVY3LigJ talks about sending the node process a SIGUSR2 to have it dump all the active handles, but that post is three years old and the technique is not working on node 0.10 - all I get from node is the message "User defined signal 2: 31".

// ravi

unread,
Jan 23, 2015, 4:00:45 PM1/23/15
to nod...@googlegroups.com
On Jan 23, 2015, at 2:22 PM, bill.w...@lmco.com wrote:
>
> Is there any way in node.js 0.10.x to see what is keeping the event loop still alive/running? I have an app which used to shut down cleanly but now is hanging, so there must be a timer, socket, etc. still active, but it is not apparent where.


Are you on *nix? If so, and if it is a socket, then you can use ‘netstat -nap’ specifying the process id of your node process, to get the list of open/connected sockets it is holding. That might give you a clue (e.g: if you have a socket connected to port 3306 on a remote server, then it’s possibly a MySQL connection). You can also use ‘lsof’ in a similar way.

—ravi


Ryan Graham

unread,
Jan 24, 2015, 8:35:46 PM1/24/15
to nod...@googlegroups.com
It sounds like you are looking for process._getActiveHandles(). You could set up a signal handler for SIGUSR2 or an unref()'d timer to log the output of that function to the console.

It's not always the easiest to decipher, but it should give you some ideas of where to look.

~Ryan

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscribe@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/35164503-DDEE-4E0D-8191-CD2B278D93F5%40g8o.net.
For more options, visit https://groups.google.com/d/optout.

bill.w...@lmco.com

unread,
Mar 6, 2015, 9:57:43 PM3/6/15
to nod...@googlegroups.com
_getActiveHandles() showed me that it was a timer issue, but this is a good tip to keep in mind if I run into a case where _getActiveHandles() indicates it is a socket open.

bill.w...@lmco.com

unread,
Mar 6, 2015, 9:57:43 PM3/6/15
to nod...@googlegroups.com
This was exactly what I needed.  The very last step of app shutdown I set a 5 second timer and unref() it, and print out _getActiveHandles in the handler.  For a while I thought it wasn't giving me accurate results because it showed a timer that didn't make sense to me - one I had cancelled - but it turns out there is some strange behavior with unref()'d interval timers and it was showing me the problem timer.  (Related to https://github.com/joyent/node/issues/7327, if you unref() an interval timer and cancel it after the first time it expires, it won't invoke the callback any more, but it holds the event loop alive until the next expiration time.  So the cancellation only does half of what I'd expect.  Simply not unref()'ing the interval timer solved my problem, since an non-unref()'d interval timer will "let go" of the event loop immediately.)
Reply all
Reply to author
Forward
0 new messages