mafintosh/why-is-node-running

Node is running but you don't know why? why-is-node-running is here to help you.

why-is-node-running's Issues

Usage with mocha

I am trying to use this tool to figure out why my mocha tests are hanging, as recommended.

Our project has the following script defined in package.json:

    "test": "NODE_ENV=test NODE_PATH=./src:./test mocha src/**/__tests__/**/*.js",

We typically use the command yarn test to run our tests.

What command should I use to run our tests under this tool? When I do this:

$ why-is-node-running yarn test

I get:

Error: Cannot find module '/Users/mpelzsherman/source/ag.js/yarn'

Many thanks!

Why all promises ever performed are reported

I'm having hard time with this lib.
It reports all promises the running app ever performed.

hashtab PROMISE
/.../node_modules/mongodb/lib/utils.js:432 - return new Promise(function(resolve, reject) {

All promises performed by any libraries. Mongodb driver or actually anything.
Even is the app shuts down clearly, it says:
There are 10272 handle(s) keeping the process running

Is there a way to learn why async / await promises give such a headache to this lib?

Still Running

Node stays running because you have 2 setIntervals callbacks running every second. You will need to call clearInterval with the value returned from the setInterval to stop them.

You also have two net servers listen on port 0 which means the server will pick a random port to listen on. They will listen forever so you will need to call server.close(*cb) if you want the node process to stop.

isn't SIGUSR1 reserved for the debugger?

In the docs:

'SIGUSR1' is reserved by Node.js to start the debugger. It's possible to install a listener but doing so might interfere with the debugger.

SIGUSR2 should be ok

This could lead to memory leak of Promise/PromiseWrap

Hello guys,

I was using this module to track what is pending in my nodejs project, and once my node process ended with heap out of memory, I was confused a lot by checking my code for memory leak...

Finally with ChromeDev tools, I found that the objects Array, Promise & PromiseWrap were always increasing without being released by GC, and they're somehow related to this module.

By checking the source code, async-hook was used to track all the Promises/async/await, and they're put into a map... so I think that's where the leak happens. and after removed require('why-is-node-running') from my code, the memory leak was gone.

So maybe I would like to recommend to put some WARNINGS in the README.md file of this module like:
if you're creating new Promises to wrap traditional callbacks a lot, this module could lead to memory leaks...

Thanks.

`filename` is null, cannot read .indexOf of null

Change this line:

return filename.indexOf(sep) > -1 && filename.indexOf('internal' + sep) !== 0

to

return filename && filename.indexOf(sep) > -1 && filename.indexOf('internal' + sep) !== 0

Somehow the filename is null on my Node 8.9

Source Map line numbers are wrong with mocha and ts-node

So as the title says, when I run this package with mocha like so:
why-is-node-running node_modules/.bin/_mocha --inspect -r ts-node/register 'src/**/*.test.ts'
or so:
mocha --inspect -r ts-node/register -r why-is-node-running/include 'src/**/*.test.ts'
the output points to the wrong line in the ts source files or even the wrong file completely.

Unknown handles?

I'm at a loss as to why my app isn't closing. I get the following output:

There are 0 known handle(s) keeping the process running and 4 unknown
Known handles:

^C
#

What are 'unknown' handles?

"There are 0 handle(s) keeping the process running" - and node still running??

node: v10.8.0

steps to reproduce:

1. create readline interface
2. close the interface
3. ask for user input using question method on the readline interface
4. call whyisnoderunning after 5 seconds

observe message "0 handle(s)", but node wont close

??

Jqgrid Export to Excel

I am using Jqgrid 4.4 version for my codeigniter website. I have been trying to export the Jqgrid values to excel, When i Use this function

("#export").on("click", function(){
grid.jqGrid("excelExport",{
includeLabels : true,
includeGroupHeader : true,
includeFooter: true,
fileName : "ship-to-attention.xlsx",
maxlength : 40 // maxlength for visible string data
})
})

It shows an error in console stating that
uncaught type error: cannot read property 'indexOf' null

excelExport : function(o) {
o = $.extend({
exptype : "remote",
url : null,
oper: "oper",
tag: "excel",
exportOptions : {}
}, o || {});
return this.each(function(){
if(!this.grid) { return;}
var url;
if(o.exptype == "remote") {
var pdata = $.extend({},this.p.postData);
pdata[o.oper] = o.tag;
var params = jQuery.param(pdata);
if(o.url.indexOf("?") != -1) { url = o.url+"&"+params; }****//

Here on the above line.

                else { url = o.url+"?"+params; }
                window.location = url;
            }
        });
    }
});

Do anyone know about this, Anyone who can solve this

Document best practice to eliminate handles

Hey there! First of all, thank you a lot for this nice tool - this really shows how the internals of node keep the process alive.

I would love to know what exactly is the "best practice" in terms of closing handles.

I see there are TLSWRAP, DNSCHANNEL, HTTPPARSER and TCPWRAP open because I'm fetching data and open db connection.. So for a long-running process, that is ok, but what is the best practice to clean up? Does it hurt performance-wise to keep these handles open? I would think so.
But I have no idea how to stop them. A little bit of documentation how to deal with these would be very nice. Or at least a link to a guide :)

Thank you so much in advance.

How to use it to troubleshoot Gulp tasks?

I have a task that doesn't terminate and I'd like to use this package to find out what the problem is.

How do I do that?

When I call log at the end of my tasks sequence (with runSequence), I am getting this:

fs.js:1440
      if (!stat.isSymbolicLink()) {
                ^

TypeError: stat.isSymbolicLink is not a function
    at Object.realpathSync (fs.js:1440:17)
    at toRealPath (module.js:112:13)
    at tryFile (module.js:108:22)
    at tryPackage (module.js:96:10)
    at Function.Module._findPath (module.js:153:20)
    at Function.Module._resolveFilename (module.js:323:25)
    at Function.Module._load (module.js:276:25)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.wrap [as FSInitialize] (/Users/coaxial/code/myproject/node_modules/why-is-node-running/index.js:21:22)

TypeError: Cannot read property 'indexOf' of null

Node v7.7.2
why-is-node-running: npm 1.2.2

The error seems to happen here.

There are 1 known handle(s) keeping the process running and 3 unknown
Known handles:


C:\Initech\node_modules\why-is-node-running\index.js:69
  known.forEach(function (obj, i) {
        ^
TypeError: Cannot read property 'indexOf' of null
    at C:\Initech\node_modules\why-is-node-running\index.js:73:29
    at Array.filter (native)
    at C:\Initech\node_modules\why-is-node-running\index.js:72:21
    at Array.forEach (native)
    at module.exports (C:\Initech\node_modules\why-is-node-running\index.js:69:9)
    at Timeout._onTimeout (C:/Initech/build/gulp/gulpfile.es:249:22)
    at ontimeout (timers.js:380:14)
    at tryOnTimeout (timers.js:244:5)
    at Timer.listOnTimeout (timers.js:214:5)

We need types definitions for typescript support

ES modules support?

Running why-is-node-running myscript.mjs produces

> internal/modules/cjs/loader.js:1007
  throw new ERR_REQUIRE_ESM(filename);
  ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: myscript.mjs

ES Modules support has just landed.

eval'ed code will fail.

I've tried to use why-is-node-running with code using Promise.promisifyAll() from bluebird and it failed because it uses eval() or new Function at least.

The following piece of code will trigger the bug:

test.js:

var log = require('why-is-node-running')

eval('console.log("fail")')

log()

result:

$ node --expose-internals test.js
bug-why/node_modules/why-is-node-running/index.js:73
      return s.getFileName().indexOf(require('path').sep) > -1

Part of the code which is failing:
https://github.com/mafintosh/why-is-node-running/blob/a0268be/index.js#L73-L90

It could be solved by using s.isEval() and s.getEvalOrigin() from callsite-object.

See: https://github.com/defunctzombie/node-stackback#callsite-object

Support for use directly through command line with `npx`

It would be really nice if this tool offered a CLI interface that can be used with npx why-is-node-running. Any plans of adding that interface @mafintosh ? I can help!

TypeError: Cannot read property 'indexOf' of undefined & TypeError: this._handle.close is not a function

There are 7 known handle(s) keeping the process running and 5 unknown
Known handles:

/.../why-is-node-running/index.js:73
      return s.getFileName().indexOf(require('path').sep) > -1
                            ^

TypeError: Cannot read property 'indexOf' of undefined
    at /.../node_modules/why-is-node-running/index.js:73:29
    at Array.filter (native)
    at /.../node_modules/why-is-node-running/index.js:72:21
    at Array.forEach (native)
    at module.exports (/.../node_modules/why-is-node-running/index.js:69:9)
    at null._onTimeout (/.../index.js:18:5)
    at Timer.listOnTimeout (timers.js:92:15)

any idea what's causing this?

if I include why-is-node-running first in the file I get this error for change:

net.js:475
    this._handle.close(function() {
                 ^

TypeError: this._handle.close is not a function
    at TLSSocket.Socket._destroy (net.js:475:18)
    at connectErrorNT (net.js:997:8)
    at nextTickCallbackWith2Args (node.js:442:9)
    at process._tickCallback (node.js:356:17)

Code:

const log = require('why-is-node-running')
const FirebaseServer = require('firebase-server')
const Firebase = require('firebase')

const instance = new FirebaseServer(5000, 'test.firebaseio.localhost', {
    states: {
        CA: 'California',
        AL: 'Alabama',
        KY: 'Kentucky'
    }
});
const client = new Firebase('ws://test.firebaseio.localhost:5000');
client.once('value', function(snap) {
    console.log('Got value: ', snap.val());
});

setTimeout(function() {
    log()
}, 1000)

On a Mac.

Lots of RANDOMBYTESREQUEST handles of crypto since ~ node 15

I used why-is-not-running in node 12 with much satisfaction but now I've upgraded to the node 16 LTS it is not working anymore for my use-case.

The native Node crypto module now gives a lot of RANDOMBYTESREQUEST false positives.

I think this is related to an issue on Jest: jestjs/jest#11275. Their fix: https://github.com/facebook/jest/pull/11278/files

Is it possible to have more context?

I'm getting four Timer results back all in promise library internals. Its pretty unclear to me how these are related to my promise library. Is it possible to have more stack-context around these entries? If there was, I'd be able to see much more clearly where these things are coming from.

In Windows 10 the CLI version returns unknown PID

After running from CLI and getting this PID:

kill -SIGUSR1 11020 for logging

We can't find that PID in the active process:

$ ps
      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
    14264   13280   13280      15272  cons0    1049692 18:36:57 /c/Program Files/nodejs/node
    13280   11132   13280      15860  cons0    1049692 18:36:57 /usr/bin/sh
    11132       1   11132      11132  cons0    1049692 17:34:12 /usr/bin/bash

$ bash: kill: (11020) - No such process

Trying with the active PIDs we get some messages but not the log:

$ kill -SIGUSR1 14264
      1 [sig] sh 14264! sigpacket::process: Suppressing signal 30 to win32 process (pid 15272)

$ kill -SIGUSR1 13280
      User defined signal 1

Any idea?

Thanks

Logging multiple times over the course of a programs lifetime

With v2.0.3, invoking the exported log disables the hook. I needed a more complete picture of what was going on during closing of an application because the answer to "why is node running" kept changing. Hence, I tried to sample open handlers as shown below.

for (let i = 0; i < 10; i++) {
  setTimeout(log, (i + 1) * 500);
}

However, this was obviously not possible. It worked with the following patch, in case anyone also needs this, and I am lightly suggesting it as an addition.

--- index.js
+++ index.js
@@ -23,9 +23,8 @@
 function whyIsNodeRunning (logger) {
   if (!logger) logger = console
 
-  hook.disable()
   logger.error('There are %d handle(s) keeping the process running', active.size)
-  for (const o of active.values()) printStacks(o)
+  for (const o of [...active.values()]) printStacks(o)
 
   function printStacks (o) {
     var stacks = o.stacks.slice(1).filter(function (s) {

A few questions

Hi
I'm trying to understand the output of the log from why-is-node running. First of all I'm using node v8.9.4, and I'm trying to debug why tests for a project are not exiting. According to why-is-node-running there are 448 handles which are preventing the exit. It is heavily using async await and I see about 90+% are just promises, most of which have clearly resolved, since the code works and the tests passed.

1. Why are these promises appearing?
2. What should I do to resolve these promises so they do not maintain these handles?

I also see almost all of them twice at least.
3) Is this a bug or just reality? example:

# PROMISE
/Users/aaron/work/*/dist/test/mocha.js:27                                    - before(async () => {
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runnable.js:378 - var result = fn.call(ctx);
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runnable.js:370 - callFn(this.fn);
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runner.js:304   - hook.run(function (err) {
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runner.js:334   - next(0);

# PROMISE
/Users/aaron/work/*/dist/test/mocha.js:28                                    - await redis_1.default.hset("mission-events", "totalBalance", "[\"savings\"]");
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runnable.js:378 - var result = fn.call(ctx);
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runnable.js:370 - callFn(this.fn);
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runner.js:304   - hook.run(function (err) {
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runner.js:334   - next(0);

# PROMISE
/Users/aaron/work/*/dist/test/mocha.js:28                                    - await redis_1.default.hset("mission-events", "totalBalance", "[\"savings\"]");
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runnable.js:378 - var result = fn.call(ctx);
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runnable.js:370 - callFn(this.fn);
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runner.js:304   - hook.run(function (err) {
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runner.js:334   - next(0);

# PROMISE
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runnable.js:382 - .then(function () {
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runnable.js:370 - callFn(this.fn);
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runner.js:304   - hook.run(function (err) {
/Users/aaron/.nvm/versions/node/v8.9.4/lib/node_modules/mocha/lib/runner.js:334   - next(0);

Could you give a bit more info about what the following types of things are and how to resolve them? They are fairly suggestive but trying to banish any doubt.
4) # TickObject (unknown stack trace)
5) # immediate (setImmediate?)
6) # TCPWRAP

Requirements and impact

Is there a minimal Node version requirement for this module?

Is there any performance impact due to the use of this module?

Should it be used in production?

Error: Must give hashtype string as argument

require('why-is-node-running')
require('tls')

/tmp/node_modules/why-is-node-running/index.js:12
        var handle = new loaded[prop]()
                     ^

Error: Must give hashtype string as argument
    at Error (native)
    at new wrap (/tmp/node_modules/why-is-node-running/index.js:12:22)
    at new Hash (crypto.js:50:18)
    at Object.Hash (crypto.js:49:12)
    at getDefaultSessionIdContext (_tls_wrap.js:27:19)
    at _tls_wrap.js:17:33
    at NativeModule.compile (node.js:954:5)
    at NativeModule.require (node.js:902:18)
    at tls.js:221:21
    at NativeModule.compile (node.js:954:5)

Weird behaviour with stack-chain

require('why-is-node-running')
require('stack-chain')

console.log(process) // Accessing process!

> node index.js
/tmp/node_modules/stackback/index.js:33
    err.stack;
       ^

TypeError: Cannot redefine property: _sb_callsites

Heisenbug - hang disappears if I import this library

I'm trying to debug an issue where sending SIGINT to the running process results in a hang - the process refuses to exit.

However, the mere act of adding a require for this library causes the issue to disappear.

The actual hang is somewhere in a mess of webpack-serve, webpack-dev-middleware, webpack, and something called thread-loader.

Do you have any hypotheses for why that could happen?

Workaround for `Cannot find module 'internal/linkedlist'`

Until it's addressed, try https://github.com/myndzi/wtfnode instead.

(This was mentioned in a prior issue but deserves a little more exposure.)

Cannot find module 'internal/linkedlist'

Heyo, I just wanted to play around with this to see how it works.
Apparently I don't get it to work. :(

I've got a simple index.js.

var log = require('why-is-node-running') // should be your first require

log();

And why-is-node-running is available installed in my node_modules.

That's what I got:

stefan @ stefan-mac: ~/Downloads/test
> node --version
v5.0.0

stefan @ stefan-mac: ~/Downloads/test
> node ./index.js
module.js:339
    throw err;
    ^

Error: Cannot find module 'internal/linkedlist'
    at Function.Module._resolveFilename (module.js:337:15)
    at Function.Module._load (module.js:287:25)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at timers.js:4:11
    at NativeModule.compile (/Users/stefan/Downloads/test/node_modules/why-is-node-running/core.js:108:3)
    at Function.NativeModule.require (/Users/stefan/Downloads/test/node_modules/why-is-node-running/core.js:52:16)
    at Object.globalTimeouts (/Users/stefan/Downloads/test/node_modules/why-is-node-running/core.js:14:31)
    at Object.<anonymous> (/Users/stefan/Downloads/test/node_modules/why-is-node-running/index.js:50:6)
    at Module._compile (module.js:425:26)
FAIL: 1

Thanks.

Any hints are more than welcome.

This repo may be mis-reporting histogram references

This repo appears to be mis-reporting histogram.enable() as a lingering reference:

Related to siimon/prom-client#494

# ELDHISTOGRAM
node:internal/async_hooks:201                                                   
node:internal/perf/event_loop_delay:81                                          
node:internal/perf/event_loop_delay:78                                          
/var/app/example/node_modules/prom-client/lib/metrics/eventLoopLag.js:47 - const histogram = perf_hooks.monitorEventLoopDelay({
/var/app/example/node_modules/prom-client/lib/defaultMetrics.js:43       - metric(config.register, config);

This was reported upstream to nodejs nodejs/node#42132 and they concluded histograms should not be showing here since they are unref'd at the runtime level. Therefore we suspect that it may be a false positive here in this repo.

I see that you have a number of other types blocklisted here:

why-is-node-running/index.js

Lines 8 to 11 in 24fb4c8

	var hook = asyncHooks.createHook({
	init (asyncId, type, triggerAsyncId, resource) {
	if (type === 'TIMERWRAP' || type === 'PROMISE') return
	if (type === 'PerformanceObserver' || type === 'RANDOMBYTESREQUEST') return

I'm wondering if histogram's should be added here as well?

I need to figure out why an aws lambda is hanging

I can't add the flag --expose-internals to the call, is there any other way I can figure out what is hanging open?

Document usage of internals

It would be nice to warn users in README that why-is-node-running heavily relies on internals and undocumented APIs and can break with any node update.

Incorrectly detects unref'ed Workers

The logs include WORKER which has been unref'ed already and doesn't keep node running.

test.js

const log = require('why-is-node-running');
new (require('worker_threads').Worker)('', { eval: true }).unref();
log();

output

$ node test.js
There are 10 handle(s) keeping the process running

# WORKER
node:internal/async_hooks:201
node:internal/worker:185
/Users/raisinten/Desktop/temp/project/npm/test.js:2 - new (require('worker_threads').Worker)('', { eval: true }).unref();
node:internal/modules/cjs/loader:1103
node:internal/modules/cjs/loader:1157
node:internal/modules/cjs/loader:981
node:internal/modules/cjs/loader:822
node:internal/modules/run_main:77
node:internal/main/run_main_module:17

# MESSAGEPORT
node:internal/async_hooks:201
node:internal/worker:185
/Users/raisinten/Desktop/temp/project/npm/test.js:2 - new (require('worker_threads').Worker)('', { eval: true }).unref();
node:internal/modules/cjs/loader:1103
node:internal/modules/cjs/loader:1157
node:internal/modules/cjs/loader:981
node:internal/modules/cjs/loader:822
node:internal/modules/run_main:77
node:internal/main/run_main_module:17

# TTYWRAP
node:internal/async_hooks:201
node:internal/bootstrap/switches/is_main_thread:47
node:internal/bootstrap/switches/is_main_thread:127
node:internal/worker:213
/Users/raisinten/Desktop/temp/project/npm/test.js:2 - new (require('worker_threads').Worker)('', { eval: true }).unref();
node:internal/modules/cjs/loader:1103
node:internal/modules/cjs/loader:1157
node:internal/modules/cjs/loader:981

# SIGNALWRAP
node:internal/async_hooks:201
node:internal/process/signal:26
node:internal/bootstrap/switches/is_main_thread:132
node:internal/worker:213
/Users/raisinten/Desktop/temp/project/npm/test.js:2 - new (require('worker_threads').Worker)('', { eval: true }).unref();
node:internal/modules/cjs/loader:1103

# TickObject
node:internal/async_hooks:201
node:internal/async_hooks:506
node:internal/process/task_queues:133
node:internal/streams/readable:980
node:internal/streams/readable:971
node:internal/streams/readable:885
node:internal/streams/readable:751
node:internal/worker:426
node:internal/worker:213

# TTYWRAP
node:internal/async_hooks:201
node:internal/bootstrap/switches/is_main_thread:47
node:internal/bootstrap/switches/is_main_thread:139
node:internal/worker:218
/Users/raisinten/Desktop/temp/project/npm/test.js:2 - new (require('worker_threads').Worker)('', { eval: true }).unref();
node:internal/modules/cjs/loader:1103
node:internal/modules/cjs/loader:1157
node:internal/modules/cjs/loader:981

# TickObject
node:internal/async_hooks:201
node:internal/async_hooks:506
node:internal/process/task_queues:133
node:internal/streams/readable:980
node:internal/streams/readable:971
node:internal/streams/readable:885
node:internal/streams/readable:751
node:internal/worker:426
node:internal/worker:218

# MESSAGEPORT
node:internal/async_hooks:201
node:internal/worker:223
/Users/raisinten/Desktop/temp/project/npm/test.js:2 - new (require('worker_threads').Worker)('', { eval: true }).unref();
node:internal/modules/cjs/loader:1103
node:internal/modules/cjs/loader:1157
node:internal/modules/cjs/loader:981
node:internal/modules/cjs/loader:822
node:internal/modules/run_main:77
node:internal/main/run_main_module:17

# MESSAGEPORT
node:internal/async_hooks:201
node:internal/worker:223
/Users/raisinten/Desktop/temp/project/npm/test.js:2 - new (require('worker_threads').Worker)('', { eval: true }).unref();
node:internal/modules/cjs/loader:1103
node:internal/modules/cjs/loader:1157
node:internal/modules/cjs/loader:981
node:internal/modules/cjs/loader:822
node:internal/modules/run_main:77
node:internal/main/run_main_module:17

# TickObject
node:internal/async_hooks:201
node:internal/async_hooks:506
node:internal/process/task_queues:133
node:internal/worker:261
/Users/raisinten/Desktop/temp/project/npm/test.js:2 - new (require('worker_threads').Worker)('', { eval: true }).unref();
node:internal/modules/cjs/loader:1103
node:internal/modules/cjs/loader:1157
node:internal/modules/cjs/loader:981
node:internal/modules/cjs/loader:822

I'll try to open a PR in Node.js to implement the hasRef() method on Worker and if that gets merged, the only change required in this repository would be to additionally handle the 'WORKER' type in

why-is-node-running/index.js

Line 30 in 24fb4c8

r.type === 'Timeout' &&

.

EDIT:
PR opened in Node.js - nodejs/node#42756.

TypeError: self._handle.connect is not a function

Something went wrong on net module binding when using why-is-node-running with request+bluebird combo.

I got this error:

net.js:822
      err = self._handle.connect(req, address, port);
                         ^

TypeError: self._handle.connect is not a function
    at connect (net.js:822:26)
    at net.js:984:7
    at GetAddrInfoReqWrap.asyncCallback [as callback] (dns.js:63:16)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:82:10)

I tried to find the reason why it is fails, but i could't find.

This is test code which i used.

'use strict';

/**
 * Module dependencies.
 */
const why         = require('why-is-node-running');

const
  Promise     = require('bluebird'),
  request     = require('request');


const
  feeds = [
    'http://www.gojobs.go.kr/employ/rss.asp',
    'https://github.com/mooyoul.atom',
    'https://github.com/Flexget/Flexget/commits/develop.atom'
  ];

const fetch = (url) => {
  return new Promise((resolve, reject) => {
    request({
      method: 'GET',
      url: url
    }, (e, res, body) => {
      if (e) {
        return reject(e);
      }

      resolve(body);
    });
  });
};

Promise.map(feeds, (feed, index) => {
  console.log('fetching feed index %d: %s', index, feed);
  return fetch(feed);
});

Hangs in node v6.6.0?

I am trying to use this in node v6.6.0 but as soon as I require('why-is-node-running') the process hangs indefinitely.

Programatic usage

Instead of just print the results on the console, allow to get an object with them. This would allow to inspect them better combined with some testing framework, specially when tests pass but the test process don't exit due to some missing open handlers.

Unref'ed timers should be excluded as they do not keep Node process running

When a timer is unrefed, it will not keep the node process running. Therefore, unrefed timers should be excluded from the output.

Observed Behaviour

e.g, Consider the following example.

const log = require('./');

setTimeout(() => {}, 99999999).unref()
process.stdin.on('data', () => {});

setTimeout(function() {
    this.unref()
    log()
})

The output for the above script is:

There are 3 handle(s) keeping the process running

# Timeout
/Users/deepal/Projects/why-is-node-running/abc.js:3 - setTimeout(() => {}, 99999999)

# TTYWRAP
/Users/deepal/Projects/why-is-node-running/abc.js:4 - process.stdin.on('data', () => {});

# Timeout
/Users/deepal/Projects/why-is-node-running/abc.js:6 - setTimeout(function() {

Expected Behaviour

We should not see the two Timeouts as they are unrefed and are not keep the process from exiting.

Happy to raise a PR for this.