ember-cli: portfinder not working with Touchbar Macbook Pro

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

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 6
  • Comments: 63 (46 by maintainers)

Commits related to this issue

Most upvoted comments

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. ❤️

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

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

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

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

@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 👍

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)

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

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

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!

whoops @simontseng 😃 ^^

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

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

@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

@mupkoo - thanks for reporting that - honestly 😃

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.

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.

@jamesstonehill - Not sure if you noticed, but this issue is closed since it is fixed in ember-cli@2.11.1. 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 ember-cli@2.11.1 and you won’t have to manually specify the port number.

@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.

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.