GoogleChrome/chrome-launcher

Launcher ECONNREFUSED flake

devtools-bot opened this issue · 11 comments

devtools-bot commented

From @paulirish on June 20, 2017 21:59

This is a bit of carryover from #2544. It was failing 100% of the time and now its more like 5%.

Example build: https://travis-ci.org/GoogleChrome/lighthouse/jobs/245116083
image

Things to note:

  • Last night, this error thrown for EVERY chrome launch, like all smokehouse runs. After ward's fix it appears to only affect the Launcher tests
  • It's intermittent. On this build, only 1 of the 3 travis jobs had a problem.

There might be still a bug on the travis/chrome side, but seems like we have room to handle this from within launcher. (port sniffing & retry logic?)
At the very least, more usable error messages and extra logging.

wdyt @samccone

edit: he said..

image

Copied from original issue: GoogleChrome/lighthouse#2556

devtools-bot commented

From @wardpeet on June 21, 2017 4:52

not sure it's relevant but in smokehouse we have

// Lighthouse sometimes times out waiting to for a connection to Chrome in CI.
  // Watch for this error and retry relaunching Chrome and running Lighthouse up
  // to RETRIES times. See https://github.com/GoogleChrome/lighthouse/issues/833

just a sidenote on smoke tests we add a delay of 0.5s which maybe gives travis some extra room to breath between runs?

devtools-bot commented

From @paulirish on June 28, 2017 23:59

pwmetrics has had a workaround for this issue for a long time now: https://github.com/paulirish/pwmetrics/blob/2eb1266f0997050dd56435a2dac5b34dd26e1b82/lib/index.ts#L129-L154 (basically just adding retry logic. )

I've put up a proposed fix in #2616

devtools-bot commented

From @brendankenny on June 29, 2017 0:11

hey now, smokehouse has had a workaround for even longer :P

paulirish commented

A lot more discussion of this in GoogleChrome/lighthouse#2726

and related: when we let chrome pick the arbitrary port (via port=0) we can follow the pattern that TracerBench/chrome-debugging-client#30 uses.

bendytree commented

This may be amiss, but for anyone debugging an ECONNREFUSED error, i think this happens if chrome fails to launch - which could be any number of reasons.

We ran into it on Ubuntu 16.04, and it winds up that we needed the --no-sandbox flag:

chromeLauncher.launch({
  chromeFlags: ['--disable-gpu', '--headless', '--no-sandbox'],
})
  • 👍7
joshontheweb commented

I was getting this error and the problem was that I was passing in the debugging port as a chrome flag. Chrome Launcher ignores this and sets the flag on its own later. You need to pass the port in as a separate argument outside of the chrome flags for this to work. Perhaps it would make sense for Chrome Launcher to check for the existence of of the --remote-debugging-port=9222 chrome flag before setting its own random port? Happy to submit a pull request for this if its helpful.

jasonwilliams commented

@bendytree thank you soo much
I was getting this error on Centos

susannakosic commented

Hi, I am running into this issue as well, and I am not sure what is the root cause.
I am using a visual testing library named loki over CI/Jenkins, and getting this error:

Chrome (app) ✖ Start → connect ECONNREFUSED 127.0.0.1:41862 Fetch list of stories Test chrome.laptop Stop connect ECONNREFUSED 127.0.0.1:41862 Error: connect ECONNREFUSED 127.0.0.1:41862 at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1107:14

The process works as expected on MacOs Catalina, issue only happens on CentOS/CI.
System is running CentOS Linux release 7.6.1810 (Core) and has Google Chrome 80.0.3987.106.
loki has a dependency on chrome-launcher@0.10.5.

Can someone provide some guidance on how to investigate / find a fix?

patrickhulce commented

@susannakosic are you able to start and run Chrome on that machine without chrome-launcher/loki involved?

as @bendytree said in #6 (comment) this is usually because Chrome crashes or is unable to start properly and so the connection fails.

csvan commented

People getting this error in your CI environments, check if your process is running as root. In that case you need to pass the Chrome flag --no-sandbox

wkolcz-UMHS commented

I am getting the issue when I try to fire it from node via an api call. There is no issue when I log into my Ubuntu 20 server and fire the node script from the CL. Only when the node script is executed without being logged in.

I am using the flags:
{chromeFlags: ['--headless','--no-sandbox']}

Is there an issue with permissions to launch the chrome headless as non root user?