Ember-cli: `ember s` fails with `EADDRNOTAVAIL` after updating to `[email protected]`

[twokul]

[eriktrom]

Bringing over relevant information from issue #5602 to this issue (consolidating whats relevant)

• In portfinder 1.0.3 there we're 2 issues
  
  
  
  1. Starting in a recent version of MacOS the interfaces that will bind when starting a node server grew dramatically. To solve this portfinder 1.0.4 uses the built in node method os.networkInterfaces(), loops through the hosts found and (semi-smartly) filters out the hosts that are bindable.
  
  
  2. People wanted this to work within a VM. In other words, if running a VM that is bound to a shared or host only interface, handle accordingly(this is the same issue really as the mac os issue, so I wont elaborate)
  
  
• in portfinder 1.0.4 a new issue arrises, mainly the conjunction of:
  
  
  
  1. the netmask 255.255.255.0 was used in conjunction with internal: true when looping through os.networkInterfaces() to find hosts that will bind.
  
  
  2. When that netmask does not represent the 'what is bindable for a given computer' and when err.address is not available, a server will not start when using ember-cli period. (whether those two are related is YTBD)
  
  

I will ammend this with more information in a comment to follow within the next day. I need to look back through the issue list witihin node-portfinder as there was a similar issue about when err.address was and was not being thrown that came up previously in one or more issues within that repo. i don't recall it all off hand at the moment

[nathanhammond]

/cc @LisaManresa

[stefanpenner]

@eriktrom we may need to revert the recent portfinder release as we debug (unless a fix in near)

[eriktrom]

I'd prefer if we revert.

The fix may have to degrade gracefully b/c I haven't thought of a fool proof way to handle this completely yet. (Although I've only debugged in my head so far really, but in the end the solution will have to take into account all possibilities without having a full way to test them so...).

It also takes the pressure off fixing it this weekend.

I can revert tomorrow. Also feel free to revert tonight. All good, I agree.

[eriktrom]

Actually I need to revert portfinder itself b/c this will affect circle CI too. I'll do it tonight.

[stefanpenner]

Actually I need to revert portfinder itself b/c this will affect circle CI too. I'll do it tonight.

awesome thanks, really appreciate you owning this so well. It is a tricky but important part of our ecosystem, I am glad it is in good hands.

[tehviking]

Thanks for the quick response on this. Question: people that are prepping for Emberitas (a free women-focused workshop to learn web development with Ember here in Austin) tomorrow are running into this tonight. Should we worry/prep a workaround? Or is this likely to be a nonissue for them by tomorrow?

[eriktrom]

@stefanpenner - no problem - I think the next bump that tries to handle this should be a major release for portfinder and we'll just have to be careful to try to get some feedback from more people before letting it all the way out the door.

https://github.com/ember-cli/ember-cli/pull/6084 reverts this issue

[eriktrom]

Should we worry/prep a workaround? Or is this likely to be a nonissue for them by tomorrow?

Stef can u answer this. Did the last portfinder go out in a full release or just on master. What would be the plan for tonight to remedy this for their use tomorrow.

EDIT: to clarify - i'm not fully aware of the way the release cycle works ATM - i know some changes we're coming, but not sure how to answer that question correctly without reviewing the commit line. Also my answer would still be tenative

[tehviking]

it doesn't look like 1.0.4 made it even into beta. I'm not with the students who got this error, but it's possible they followed some bad instructions and got ember-cli master (???). Will look into it, but it's probably safe to assume this is a weird edge case and not some global NPM-pocalypse. Thanks for the responses :)

[eriktrom]

@tehviking - i believe the answer lies with the ^1.0.3 on release, which is why next time I'll bump to a major version.

When installing ember-cli previous to an hour or so ago portfinder 1.0.4 would have been installed. Now 1.0.5 will be installed.

I think the best answer for the students is to re-install ember-cli globally.

[eriktrom]

Also make sure to run 'npm cache clean' before running npm install ember-cli -g otherwise it will likely install a cached version of portfinder.

[stefanpenner]

Should we worry/prep a workaround? Or is this likely to be a nonissue for them by tomorrow?
Stef can u answer this. Did the last portfinder go out in a full release or just on master. What would be the plan for tonight to remedy this for their use tomorrow.

Sure, I believe a nom (npm cache clear; rm -rf node_modules; npm install) should fix any currently broken setups and future downloaders should be without error, as @eriktrom has just released v1.0.5 which reverts the offending code.

[stefanpenner]

@stefanpenner - no problem - I think the next bump that tries to handle this should be a major release for portfinder and we'll just have to be careful to try to get some feedback from more people before letting it all the way out the door.

I'm not sure that is necessary or even that valuable, as then we will still discover the issue when we bump the major version. Instead maybe a beta version should be released, we will attempt a wide variety of setups, and when we deem it to be good we can release it as stable.

It may also be a good idea to add https://github.com/visionmedia/debug to portfinder, and instrument it so that DEBUG=portfinder* yields some good details, and maybe can result is faster diagnosis.

[eriktrom]

Sure, I believe a nom (npm cache clear; rm -rf node_modules; npm install) should fix any currently broken setups and future downloaders should be without error

To be safe, b/c ember-cli is a command line utility, perhaps:

npm cache clear && rm -rf ./node_modules && npm install ember-cli -g && npm install

That's a mouthful. I believe only the global version is looked up, but better safe than sorry in a classroom

cc @tehviking - fyi for tomorrow

[eriktrom]

@stefanpenner

Both of our suggestions for the next release are relevant. Thanks for the feedback. We'll work through it next week.

[stefanpenner]

That's a mouthful. I believe only the global version is looked up, but better safe than sorry in a classroom

the part that runs port finder will only be the project local installation (unless npm link'd), but the above command won't hurt at all.

Both of our suggestions for the next release are relevant. Thanks for the feedback. We'll work through it next week.

Awesome, keep me in the loop. I'll gladly test (and get other co-workers to test as well). Very much appreciate all your help here!

[eriktrom]

I found an older laptop when a buddy came over this weekend. Pasting a gist link for later debugging. The os.networkInterfaces(), mac os version and the netmask within /etc/hosts are contained in the gist.

More of a note to self, but we'll need a decent pool of these to help make decisions later, so starting that process.

https://gist.github.com/eriktrom/88e28ad0bfa80b37ed6caecb743bf2ef

[eriktrom]

(there was a comment above this one, it had little value, I deleted it. whats relevant remains here)

Idea for fix for EADDRNOTAVAIL cases still out in the wild (very few less than before revert, but still possible)

• Filter out bad hosts(for all interfaces) before we begin checking ports. This can be done by trying each host out for whether it throws EADDRNOTAVAIL before continuing on, placing what we know is bindable in the defaultHosts array

This would be a relatively simple edit to the commit that was reverted on friday. Will even get to delete some code, wahoo :)

I will give that a shot and try to get it into a beta. One caveat - I leave for a week on the 31st(to somewhere rather remote) so I don't think we should push it out the door before then.

[stefanpenner]

@eriktrom the strategy sounds good, and ya good call it should likely wait until you return to release it. Although if a solution lands as a PR before some of us can test.

[eriktrom]

Just FYI on progress: https://github.com/indexzero/node-portfinder/pull/37

I've given the simple edit a go - it freezes travis - I will spin up an ubuntu box with the hope of finding the issue.

Anyone is free to review, comment, etc - explanation given in PR.

One thought/question: Can't the operating system tell us what host addresses are bindable?. Or better said, why does os.networkInterfaces() give me non-bindable addresses? And why does it not give me, for example, 0.0.0.0? Seems like a more true and tried way should exist, maybe I'll google around more. If you took Operating Systems in college, feel free to HALP! :)

[stefanpenner]

One thought/question: Can't the operating system tell us what host addresses are bindable?. Or better said, why does os.networkInterfaces() give me non-bindable addresses? And why does it not give me, for example, 0.0.0.0? Seems like a more true and tried way should exist, maybe I'll google around more. If you took Operating Systems in college, feel free to HALP! :)

i wish i had a good answer for you :(

[eriktrom]

Okay - finally I believe this works as expected - although I've said that one before 👍 This time though I'm 99% sure. Really. :)

To test (assumes ember-cli is npm linked to your project):

Inside ember-cli:

npm i --save [email protected]

Inside your project, open 2 terminal windows and run the following in each:

ember serve -p 0

Expected Output:

Terminal 1:

Livereload server on https://localhost:49153
Serving on https://localhost:49152/

Terminal 2:

Livereload server on https://localhost:49155
Serving on https://localhost:49154/

Note the port numbers, they are the variant.

Report back here with a 👍 or 👎 (with stack trace)

Thanks in advance to all those who participate, your awesome.

(related ember pr that will close this issue: https://github.com/ember-cli/ember-cli/pull/6180)
(related upstream changes: https://github.com/indexzero/node-portfinder/pull/37)

EDIT: In the event of a failure please run the above in debug mode - DEBUG=portfinder* ember serve -p 0 and paste a link to a gist with the output. This will help tremendously.

[stefanpenner]

only tested on OSX, I can test windows 10 tonight

[eriktrom]

awesome man thanks :)

[nathanhammond]

@eriktrom Works for me as well on OS X. However, because I'm a jerk, I checked to see if it is susceptible to race conditions:

[eriktrom]

@nathanhammond - yes that is possible - although its quite hard to do, so I'm impressed :)

The reason is that portfinder only looks for what 'may be open' by the time the real express server starts. If that is no longer the case later in the serve command, the error you show is what I have also been able to get (by doing the same sort of thing)

In reality, I don't think its a huge issue but we can tackle that if need be

Thanks for testing it out 👍

[nathanhammond]

@eriktrom I'm incredibly grateful for all of your work on this. I'm strongly in favor of releasing this as-is. There's no particular reason in this scenario to prevent port race conditions as you have to _try_ to trigger this behavior.

Just to confirm: if we were to decide to solve this we would address it in portfinder, correct?

[eriktrom]

Just to confirm: if we were to decide to solve this we would address it in portfinder, correct?

Actually - its tricky - portfinder only says 'hey, these ports are open for you express' - then portfinder shuts down the servers it used to test the ports, then later(not too long, but a bit later) in the serve command we actually use the ports it told us were open and boot express. The time gap there does exist - to solve it we'd have to probably catch the express error and recurse through the serve command again.

Make sense? Sure its possible if we want to do it.

[stefanpenner]

basically, portFinder is best effort. If we want to solve this, express and friends would need to basically use portFinder directly.

I am fine with the current state.

@eriktrom if we release this, we may want to do the following:

1. release as a semver breaking change
2. put into ember-cli canary / beta
3. let our users gradually use, and we can then slowly learn of any issues.

The alternative is to bump a minor version, and open potential flood gates. Although we will get a very quick answer (which I like :P)

thoughts?