Ember-cli: portfinder not working with Touchbar Macbook Pro

[HeroicEric]

Update

With help from @max & @nathanhammond this seems to have been narrowed down to some kind of incompatibility between portfinder and new Macbook Pros with the touchbar.

It seems to be reproducible by restarting the MBP, making sure that the lid is opened so the touchbar process (eoshostd) is using the default livereload port (49152).

I believe the intended behavior is that portfinder should detect that this port is in use and find another one that is available, which is not happening automatically or when forced using --live-reload-port=0.

Original issue

After restarting my computer this morning I started running into the following whenever trying to run ember server:

Serving on http://localhost:4200/
Livereload failed on http://localhost:49152.  It is either in use or you do not have permission.

I'm not sure if something is running on this port or if it's a permissions error but I think it's a permissions error because running with sudo works.

Can somebody point me in the right direction for debugging this?

Things I've Tried

• Restarting again
• Reinstalling node & anything node related
• Tried on multiple apps (with different ember-cli versions), including a brand new one
• Using sudo, it works.

Running live reload on a different port

This works but doesn't really fix anything.

> ember server --live-reload-port 49153

Livereload server on http://localhost:49153
Serving on http://localhost:4200/

Finding what's running on that port

I tried to find the process running on this port but I'm not sure if anything is? Since it works with sudo, it makes me think it's the permissions causing a problem.

> lsof -i:49152 # returns nothing
> lsof -n -i4TCP:49512 # returns nothing

# idk what this means or if it's helpful
> netstat -anp tcp | grep 49152
tcp6       0      0  fe80::aede:48ff:.49152 fe80::aede:48ff:.61000 ESTABLISHED

---

Output from ember version --verbose && npm --version:

ember-cli: 2.10.0
http_parser: 2.7.0
node: 6.9.1
v8: 5.1.281.84
uv: 1.9.1
zlib: 1.2.8
ares: 1.10.1-DEV
icu: 57.1
modules: 48
openssl: 1.0.2j
os: darwin x64
3.10.8

OS X Sierra 10.12.1

[HeroicEric]

Awesome. I took a break for an hour and when I came back it works... 😕 🐑

[max]

Just ran into this issue. Same steps as @HeroicEric. I guess I too shall take a break.

[max]

After doing some digging:

$ sudo lsof -i:49152     
COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
eoshostd 179 root    3u  IPv6 0xa0004c9e18bfb671      0t0  TCP [fe80:4::aede:48ff:fe00:1122]:49152->[fe80:4::aede:48ff:fe33:4455]:61000 (ESTABLISHED)

It looks like this happens only on TouchBar Macs and it's some sort of communication layer between the TouchBar's "EmbeddedOS" and macOS.

[HeroicEric]

Reopening this since it seems to still be an issue worth looking into further

[eriktrom]

Livereload failed on http://localhost:49152. It is either in use or you do not have permission.

without any new knowledge, or debugging, this means that

a) between the time portfinder checked to see if that port was open and when livereload started on the same port(there is a real delay here, perhaps 1s), the port became in use. You can manually produce this error by running ember s w/ 2 different addons at the same time(with very little luck needed)

b) b/c portfinder checks for an open port by listening on the port+host, but does not actually send anything through the socket, its possible macOS is allowing a socket connection, but throws when sending data through - which throws a node syserr, which is caught and re-thrown as the above generic error - i've tried sending data through but it fails if bluetooth is enabled(for example), so had to revert that idea. NOTE - this is likely the issue, or the issue is related in nature to this 'way of checking' for an open port

so -- how to solve this problem - i will think about it - windows 10 has an un-related issue where it allows over-taking an already in use port + host - which means there may be a 2 birds w/ one stone approach here - either way, if portfinder fails on macOS with touchbar, the issue becomes more serious (b/c most of us use mac TBF)

[eriktrom]

moving further discussion to https://github.com/indexzero/node-portfinder/issues/47 until a solution is found, fyi

[stefanpenner]

windows 10 has an un-related issue where it allows over-taking an already in use port + host - which means there may be a 2 birds w/ one stone approach her

woah that is unexpected.

---

As usual @eriktrom, you have my admiration and respect for your continued and ongoing support with all things portfinder!

[stefanpenner]

A "quickfix haxor" may be to start our portfinding afew ports higher? Although detecting this case if possible would obviously be the better choice.

[eriktrom]

@stefanpenner - how about port 49153 - @HeroicEric has shown that to work

PS -

regarding the windows bug - its related in that if portfinder actually tried to pipe a stream of data through, the over-taking of a port can be identified. So could this issue. The windows open issue can be found here, most of the code for the fix here(w/ just added new comment) and the day i deployed that code here

[eriktrom]

fix submitted in https://github.com/ember-cli/ember-cli/issues/6545

[stefanpenner]

@eriktrom are you able to share a TL;DR why portfinder was unable to detect this. Or do you believe it was a race between portfinder finding the open port and the port being consumed.

[eriktrom]

@stefanpenner - its b/c portfinder (from the beginning) looks for an open port by trying to listen on the connection - when in fact to be completely accurate we need to use the connection - aka - pipe through it and ensure we get back what we put in.

This code is here https://github.com/indexzero/node-portfinder/pull/42/files#r91562324 but in order to use it we need to handle the OS errors that will be thrown - i'm not sure what they are which is why i haven't pursued it. The only way to find out is maybe to put it out in the wild, or be more greedy when an error is thrown. (maybe whitelist the errors we know of, catch everything else, hard to know)

At this point im not sure if not breaking it or not improving it is worse.

Thats the tl;dr of it.

[stefanpenner]

@stefanpenner - its b/c portfinder (from the beginning) looks for an open port by trying to listen on the connection - when in fact to be completely accurate we need to use the connection - aka - pipe through it and ensure we get back what we put in.

ah, this makes sense. Thanks!

[eriktrom]

I think i see the solution now - portfinder can catch any OS error as long as its after the listening event has fired.

This would allow us to accurately test a port by piping text through, iterating to the next port if any error is thrown or the text does not pipe back.

I will move forward with this - it should take us all the way home (aka, no bugs waaat).

Btw, thanks for the emotional support. ❤️

[renatocarvalho]

Wow, I was experiencing this issue over here and had no idea why. Changing the port to 49153 did the trick. Was this fix released?

[stefanpenner]

@renatocarvalho yes on master, I believe it will be in the next beta.

[eriktrom]

and fwiw - sorry i got busy over the holidays making the patch to prevent this kind of thing in the future - i will push it back up the priority list - my bad all

[stefanpenner]

@eriktrom you have been rocking this portfinder stuff, thanks for all your help!

[ownsourcing]

Same error with newer versions.

$ ember version --verbose && npm --version
ember-cli: 2.11.0
http_parser: 2.7.0
node: 7.4.0
v8: 5.4.500.45
uv: 1.10.1
zlib: 1.2.8
ares: 1.10.1-DEV
modules: 51
openssl: 1.0.2j
icu: 58.2
os: darwin x64
4.1.2

It does not look like the issue has actually been resolved with a commit to any (future) version. Instead it appears deferred until error handling solutions are more fleshed out (i.e. suspect most accurate to say 'open' with tag of 'needs dependency fix' --cc @homu to consider).

[acorncom]

@ownsourcing it looks like it's on the beta branch, should be testable by installing it using npm install -g ember-cli@beta

[jamesstonehill]

I have this issue! I'm running:

ember-cli: 2.8.0
node: 7.5.0

[rwjblue]

ZOMG! UPDATE EMBER-CLI! 😸

[jamesstonehill]

Ok guys, a colleague of mine found a workaround for the issue:
ember server --live-reload-port 49153

[rwjblue]

@jamesstonehill - Not sure if you noticed, but this issue is closed since it is fixed in [email protected]. The fix landed in https://github.com/ember-cli/ember-cli/pull/6763 and bumped the starting port for live reload to 49153 as you have discovered.

Update to [email protected] and you won't have to manually specify the port number.

[ksnyde]

@rwjblue I am using cli 2.11.1 and still getting this. Admittedly this issue had disappeared off my radar for a number of weeks but just now after restarting my computer I immediately ran into this. Maybe this is another edge case?

Workaround above works fine if choosing something other than 49153 which clearly must be held by OS.

Note: paranoia set in and I did nombom the deps, and did another yarn install to ensure all was up to date with deps:

[eriktrom]

Sup guys. So 49153 is not always open either on MacBook Pro touch bar it seems.

I've really been putting off an update to portfinder that should fix this.

I'm also super busy with client work. And it's hard to test this as I've got one of those old school macs still. 😉

So... what if push the proposed solution and someone willing help test it can pair with me or try it out.

I'll post back when I push a non released branch to portfinder. I'll try to do it today.

[eriktrom]

I recant that statement - I won't have time today. The breadcrumbs for digging in and fixing it should all be in thread though if someone wants to pick it up. Otherwise I'll have to come back to it. We're shipping stuff and I just can't get distracted from that ATM. My apologies in advance.

[Turbo87]

indeed I just ran into the same issue again with the most recent Ember CLI release:

Livereload failed on http://localhost:49153.  It is either in use or you do not have permission.

[stefanpenner]

If anyone has cycles, I suspect we can actually remove the need for the second part at all. And merely multiplex across the same one used for serving the index.html. (typically 4200)

[eriktrom]

And merely multiplex across the same one used for serving the index.html

@stefanpenner - by multiplex - do u mean the proposed solution i laid out e.g.

This would allow us to accurately test a port by piping text through, iterating to the next port if any error is thrown or the text does not pipe back.

---

also, what do u mean by

I suspect we can actually remove the need for the second part at all

FYI - I'm gonna spike this right now - it's the verifying that i don't break things I don't know about that worries me - hopefully those on this thread can help verify that things work - the release will be portfinder 2.0 though, which won't help until we do a major bump, which won't hit downstream consumers of ember-cli until the next full release comes out (that includes the bump) <-- if those here think this should be a minor bump then I will need a lot of support ensuring nothing breaks

[eriktrom]

I suspect we can actually remove the need for the second part at all

U mean use the same open connection then... Interesting.

Also we need -tp to not be something people always type in (im getting sick of doing it for sure) - we can't multiplex that b/c it's a different command - lets address this separately but given i don't know which port and why apple binds the touch bar too - and the fact that windows 10 can override a port means portfinder needs to check for a port and actually use it before saying its open (and closing it) - just fyi thoughts

EDITED: changed -lrp to -tp my bad

[eriktrom]

progress - have to switch to something else - just fyi

https://github.com/indexzero/node-portfinder/pull/53

it might work as is, doubt it though yet

[mupkoo]

I haven't experienced this after updating to macOS 10.12.4

(I am with a MacBook Pro with a touch bar)

[eriktrom]

@mupkoo - thanks for reporting that - honestly :)

[mupkoo]

It is back -> Livereload failed on http://localhost:49153. It is either in use or you do not have permission. :|

Sorry for the false positive

[allthesignals]

I'm seeing this now too.
Livereload failed on http://localhost:49153. It is either in use or you do not have permission.

I have no idea what I did. Last thing I remember, I ember install ember-composable-helpers, it started screaming about some other addon and Gulpfiles (ember-semantic-ui). I'm totally locked out of my project now!

ember-cli: 2.13.0
node: 7.7.4
os: darwin x64

[eriktrom]

@allthesignals - try ember s -lrp 5500 which will set the livereload port to 5500 - or choose a port of liking

@stefanpenner - maybe we just start at 59153 for now?

also - i have a buddy who just got a touch bar, but he has yet to reproduce this - once he does, i'll pair with him and try my idea out - but have no way of verifying any fix ATM till then

[Turbo87]

maybe we just start at 59153 for now?

that is actually what we are doing right now, but it seems that the MacBook is not always using the same port and we've hit the same issue on 59153 too.

[allthesignals]

@eriktrom thank you! any ideas what's going on? I can't seem to start any apps with the default port. I also have new MBP with touch strip, but not relevant. Maybe I'll switch node versions...

[eriktrom]

@allthesignals -

I can't seem to start any apps.

does this work?:

ember s -p 4210 -lrp 4211

if not, do these work:

python2 -m SimpleHTTPServer 4210
python2 -m SimpleHTTPServer 4211

if those work but the ember s command with same ports does work, let me know....

you can also run netstat, paste the output, i'll take a look

netstat -an | grep <PORT>

also, fyi - i just updated https://github.com/indexzero/node-portfinder/pull/53 which doesn't catch any specific error, but if there are 20 errors on the same host, it will ditch it, move to the next - iterating through all possible hosts. Also, if listen says the port is open, and we pipe text through, we assume the host is something like touchbar.... random hosts that i know dont work here are being filtered out via 20 EADDRNOTAVAIL errors. Others, like EAFNOSUPPORT(ipv6) would do the same.

However, TBD if this fix is in the right direction as i dont have any hosts that say 'yes, im listening' but then fail when used, like touchbar does. @eccegordo - lets try tonight 👍 ?

Also, this would not be a full fix windows overwriting its in use ports 'issue', but there have only been 3 known cases, so we'll worry about that later. (if at all)

example from ember-cli master, yarn linked to a ember new blah --yarn, and portfinder yarn linked inside ember-cli master branch

DEBUG=portfinder* ember s -p 0 -> https://gist.github.com/eriktrom/3fc0e5afe8eb399c60b7c1f3d3f9d97c

Sorry for the issues folks, I think there is a path forward, we'll get there soon

[allthesignals]

Found the issue... I think it isn't related to any of the points above, but maybe it will help someone. For some reason, bower was installing bower_components inside /app instead of the project root. I never saw it in sublime because those directories are hidden from me. Not sure why this was happening - the .bowerrc file looked about right. Anyway, my theory is the sudden appearance of several megabytes of dependencies were throwing livereload, causing a huge bottleneck. I think the path forward is to manually address there for existing bower project or migrate away from bower if possible (although many project dependencies won't allow for this).

[stefanpenner]

bower if possible (although many project dependencies won't allow for this).

open an issue on those dependencies, so they can start getting fixed

[eriktrom]

there is progress on this btw - its open on @eccegordo's laptop - we intend to finish this week - sorry for the delay - i've been out

[stefanpenner]

@eriktrom https://github.com/ember-cli/ember-cli/pull/7020 may be another good venue, remove the need for live-reload portfinding alltogther? Thoughts?

[eriktrom]

That's a good pr - thanks for link - this line https://github.com/mklabs/tiny-lr/blob/master/lib/server.js#L25 suggests that we may still need to pass in a port - if one is given via -lrp 5555 for example, otherwise it'll fallback to 35729 - and also if no port is passed - this means that the automatic behavior of 'use the next available port' when running ember s without specifying an -lrp port would still need to use portfinder c/d?

also - more info about whats up with the Livereload failed on http://localhost:49153. It is either in use or you do not have permission. is explained, with a way to repro deterministically here: https://gist.github.com/eriktrom/c1625e6c41e796f76422dcebbc3039c6 fyi

[rwwagner90]

Just hit this issue as well Livereload failed on http://localhost:49154. It is either in use or you do not have permission.

[eriktrom]

Thanks for commenting.

Plan b while plan a pans out (a requires I have a touchbar mac in front of me - which I've had once - and thus is taking too long. )

Plan b - set the base port to start at 5020 - which is open in general and from observation, touchbar has only ever started in the 40,000-50,000 range. This would remove this particular issue. I still plan to make a full fix when I can.

Any objections?

[thommahoney]

My sense is that this is a race condition where both applications are seeking an ephemeral port at the same time.

Starting at 5020 might solve this bug but only coincidentally since it's less likely for two processes to be requesting that port at the same time.

Would it be difficult to arrange the code in such a way that it attempts to find a new port after it fails to attach to the one that was previously open?

[eriktrom]

Would it be difficult to arrange the code in such a way that it attempts to find a new port after it fails to attach to the one that was previously open?

I appreciate your feedback - this is actually what portfinder is designed to do. The issue that is occurring with the touchbar has to do with the sid/gid given to the net.createServer call used to make the socket that we use to test the port + host.

When running portfinder itself, from a file that you start from bash, portfinder works correctly (at least the latest wip branch linked above). When the same exact code is run from within the commands/serve.js inside ember-cli(i've hard coded this all to prove it), the permissions given to the socket used to test the port are not the same, and we get the error Livereload failed on http://localhost:49154. It is either in use or you do not have permission.

If anyone can provide context, even links to linux man docs, or anything at all that would help immensely.

@thommahoney - thanks for taking the time to think through the problem.

A port like 7020 or 5020 or anything not in the range of 40,000-59,999 would fix this more quickly, especially as more touchbar macs come into the world, the odds 1/20,000 for having this conflict will increase.

[eriktrom]

Worth noting that running ember s in two separate terminals at almost the same time will also reproduce this. It's the same underlying principal though.

[thommahoney]

@eriktrom Thanks for your detailed writeup. Until you have the appropriate hardware to diagnose the problem further, using the lower port number seems like a fine workaround.

[simontseng]

Changing the default to 49153 did help when touchbar related function are using 49153.

on my macbook it end up using 49154, so when running more then one ember app in development, the second instance ends up not starting

could we change the default to some other port number to avoid this whole segment in the mean time?

biometric 195 root 5u IPv6 0x4c732aab024c27a7 0t0 TCP [fe80:4::aede:48ff:fe00:1122]:49154->[fe80:4::aede:48ff:fe33:4455]:52032 (ESTABLISHED)

[stefanpenner]

could we change the default to some other port number to avoid this whole segment in the mean time?

sure, would welcome a PR.

[eriktrom]

@simonihmig - coming soon to stable - we changed the default starting port to 7020 - see the message at the top of the commit, i found the same results u show, 7020 is outside the touchbar range

https://github.com/ember-cli/ember-cli/pull/7065

let me know if u see further problems when using this change. Thanks 👍

[eriktrom]

whoops @simontseng :) ^^

[simontseng]

thanks @eriktrom for pointing out the new changes, just upgraded to 2.16.0-beta.1, it works brilliantly.

[jhirbour]

I had similar symptoms to this issue. I was able to fix the issue by doing the following:

• reinstalling watchman (via homebrew)
• running brew prune (to cleanup some bad symlinks from uninstalling/reinstalling node/npm/nvm

[eriktrom]

yarn global add ember-cli@latest or npm i -g ember-cli@latest should do the trick too in the future. With npm you might have more issues depending on ...

[Paul-Pushkarov]

I just got the same issue on Windows 10 with Ubuntu in WSL.
Solved it by closing all the WSL windows and opening again.

[eriktrom]

Inside where you enabled WSL for Ubuntu there was (at one time) a setting that said something like “allow port rebinding”. I have windows on an external drive — I can take a look but see if that is checked — let me know.

Thanks for reporting the issue. It’s come up only once before and I don’t have a known hack, except to change portfinder to echo back a string to ensure a port is really open, which increases its internal complexity. (A branch that has been sitting for some time solves this, but isn’t bullet proof, due to reasons I won’t dive into).

[Paul-Pushkarov]

It is not a problem for me, happened just once. I wanted to mention it here in case someone else will have the same and finds this page with google.
I can check regarding allow port rebinding but I am not sure where to look for it.

[eriktrom]

@Paul-Pushkarov - thanks and don't worry about finding that setting, I do know that there is a port rebinding issue in windows, under certain conditions, that can really only be solved for the masses by echo'ing back text to ensure a port is really open. Same thing goes for mac touch bar. Although we start at a port so low now, that you'll never iterate to hit that one anymore (never say never but likely never)

at any case, just wanted to clear the air. yes portfinder could handle this. But no, it's not "a problem" that I've seen to be of any priority that is high, based on the tradeoff of handling a bunch of new errors when "listening" on a port does not mean "the port is actually useable".

fwi for those who hit this sometime later in the future. drop a comment if this affects you, i'm am keeping an internal tally. If we do need to fix this, it is technically possible.

[Turbo87]

closing as resolved by https://github.com/ember-cli/ember-cli/pull/7065