Launcher ECONNREFUSED flake

[devtools-bot]

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

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

Copied from original issue: GoogleChrome/lighthouse#2556

[devtools-bot]

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]

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]

From @brendankenny on June 29, 2017 0:11

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

[paulirish]

A lot more discussion of this in https://github.com/GoogleChrome/lighthouse/issues/2726

and related: when we let chrome pick the arbitrary port (via port=0) we can follow the pattern that https://github.com/devtrace/chrome-debugging-client/pull/30 uses.

[bendytree]

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'],
})

[joshontheweb]

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]

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

[susannakosic]

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 [email protected].

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

[patrickhulce]

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

as @bendytree said in https://github.com/GoogleChrome/chrome-launcher/issues/6#issuecomment-341491690 this is usually because Chrome crashes or is unable to start properly and so the connection fails.

[csvan]

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]

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?