native-dns throwing when offline

[sindresorhus]

Try turning off your connection then running the tests or the binary.

/Users/sindresorhus/dev/is-online/node_modules/native-dns/lib/platform.js:166
      throw err;
            ^
Error: ENOENT, open '/etc/resolv.conf'

@silverwind This kinda looks like a native-dns bug. Thoughts?

[silverwind]

Is there really no /etc/resolv.conf on your system?

[sindresorhus]

Yes, but it only exists when the wireless is turned on. OS X 10.9. Works fine when on.

~/dev/is-online master  
❯ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 8.8.8.8
nameserver 8.8.4.4

~/dev/is-online master  
❯ cat /etc/resolv.conf
cat: /etc/resolv.conf: No such file or directory

[silverwind]

Reproduced it on 10.10 too. /etc/resolv.conf is only symlinked when either Ethernet or Wireless is up. It links to

lrwxr-xr-x  1 root  wheel  22 Jul 24 23:51 /etc/resolv.conf@ -> ../var/run/resolv.conf

Definately looks like a bug in native-dns.

[sindresorhus]

Yup. tjfontaine/node-dns#63

I guess we can just try/catch it for now.

[silverwind]

That is a pretty show-stopping bug on OSX. We could try catching the error and return an offline status.

[silverwind]

Hmm, try/catch on the require doesn't seem to catch it, suggestions?

    try {
        var dns = require('native-dns');
    } catch (err) {
        return cb(null, false);
    }

[sindresorhus]

@silverwind Yeah, try/catch doesn't work on async code. native-dns is throwing in async code, wtf...

I think the easiest would be to just fork native-dns, apply a fix and depend on that. I don't foresee that PR being merged soon.

[silverwind]

Well, I've found a dirty way to catch it:

process.on("uncaughtException", function(e) {
    if (err.code === "ENOENT" && path: '/etc/resolv.conf') {
        // return offline
    }
});

We'd have to immediatly unregister that handler, and I'm not even sure if using uncaughtException inside a module could catch other errors inside the parent module, which could cause a lot of havoc.

Forking it may be the way to go, given that @tjfontaine is probably pretty busy on node.

[sindresorhus]

@silverwind I'd prefer just forking and fixing. uncaughtException is really bad.

[silverwind]

There's another maintainer on native-dns, let's give it a few days before we fork.

[silverwind]

For a short-term fix, we could fork the repo with the fix and include it as a git dependency. I'd set up an upstream remote to native-dns, so I can pull in changes. Does that sound acceptable?

[sindresorhus]

Yup, but I prefer depending on a tarball: https://github.com/greggman/node-dns/tarball/8b75198dd8

[silverwind]

This should be resolved. I used my own fork for the case when the forked repo ever gets deleted.

Once tjfontaine/node-dns#63 gets merged, we shall switch back to the original version.

[silverwind]

Also, I just verified that the DNS request runs into the timeout when all network interfaces are down, so the behaviour with that patch is fine.

[sindresorhus]

@silverwind released https://github.com/sindresorhus/is-online/releases/tag/v3.0.0 ;)

[silverwind]

👍