ECONNREFUSED When launching multiple Chrome instances #2462
Comments
|
How are you launching and consuming chrome? Lighthouse as a node module? If you're using the latest chrome-launcher module, it should be waiting until the port is available but you'll have to make sure you're awaiting for the promise resolution before connecting. |
|
Thanks for your answer Patrick! I'm using the NPM version of lighthouse 2.0.0. Then, I'm launching chrome here: Then I connect to that instance here: (I use "Chrome Remote Interface" for that: https://github.com/cyrus-and/chrome-remote-interface) |
|
So far, It appears to be an specific Linux problem (because it works fine in our macs, but not on our servers): We're basically reproducing this on Linux when: Can you help us to reproduce if you're getting the same error on your Linux env? |
|
Any comments will be really appreciated! We're currently blocked with this! Anyone? @patrickhulce? |
|
@ezesculli it looks like you're using some old flags:
Can you try this: const CDP = require('chrome-remote-interface');
const chromeLauncher = require('lighthouse/chrome-launcher/chrome-launcher');
// Turn on logging for chromeLauncher.
// const log = require('lighthouse/lighthouse-core/lib/log');
// log.setLevel('info');
async function launchChrome(headless = true) {
const chrome = await chromeLauncher.launch({
// port: 9222, // uncomment to force a port of your choice.
chromeFlags: [
'--disable-gpu',
'--enable-logging',
headless ? '--headless' : '',
]
});
return chrome;
}
launchChrome(true).then(async chrome => {
// Make sure to use the same debugging port that chromeLauncher used/selected.
CDP({port: chrome.port}, DTP => {
...
});
}); |
|
Thanks @ebidel ! We updated those parameters, but still getting the ECONNREFUSED error: Besides that, I forced the opening of several instances, and I also get this: |
|
Hmm, ok. I'll have to test on Linux. Do you think you could post a snippet of code that repros the problem? |
|
@ebidel I think that with the code that @ezesculli posted before it's enough, but I've launched a EC2 instance in AWS to test this (which gives me the ECONNREFUSED error even in the first attempt of launching a chrome instance). If you want, I can privately send you the access credentials so you can test it there. |
|
I don't know if this helps, but on Linux I ran the code you gave us: const CDP = require('chrome-remote-interface');
const chromeLauncher = require('lighthouse/chrome-launcher/chrome-launcher');
// Turn on logging for chromeLauncher.
const log = require('lighthouse/lighthouse-core/lib/log');
log.setLevel('info');
async function launchChrome(headless = true) {
const chrome = await chromeLauncher.launch({
// port: 9222, // uncomment to force a port of your choice.
chromeFlags: [
'--disable-gpu',
'--enable-logging',
headless ? '--headless' : '',
]
});
return chrome;
}and then ran this several times: launchChrome(true).then(async chrome => {
// Make sure to use the same debugging port that chromeLauncher used/selected.
CDP({port: chrome.port}, DTP => {
console.log('DTP', DTP.port)
});
});and after a few runs, I've got this: |
|
@LucianoGanga that EventEmitter leak is a known leak with the SIGINT handling (you can flip the I'm assuming with these cases that you're observing a significant delay while it waits for the port to be available and it finally fails sometime later? Or is it immediately returning CONNREFUSED (meaning that Chrome Launcher thinks it was able to connect but CRI failed to connect)? |
|
@patrickhulce I just tested it again, It takes between 10 and 20 seconds since the chromeLauncher is excecuted until I get the error. I made some new tests in a new ubuntu server (instead of using the Heroku instance) and it fails after 10/15 new instances. In my mac, I can run it more than 30 times without any problem. |
|
@patrickhulce I lied. Wasn't able to take a look today and I'm gone tomorrow for a wedding. Feel free to test if you get a chance. Otherwise, I can get to it next week. |
|
We added more and better hardware and the problem seems to be solved... I think there's a OS limitation that prevents the instances from opening ports on time, or something around that (I'm not an expert in OS). If you want, we can close this issue. |
|
Thanks for circling back around to let us know! That certainly would explain my difficulty reproing on a 64-core linux box :) Feel free to reach out again if you run into new issues! |
|
Hi @patrickhulce ! We're having the issue again, but this time I can't even run one instance of chrome. This is the code: const chromeLauncher = require('chrome-launcher');
chromeOptions = {
port: 0,
autoSelectChrome: true, // False to manually select which Chrome install.
additionalFlags: ["--disable-gpu", "--headless", "--enable-logging"]
}
// Launch chrome
chromeLauncher.launch(chromeOptions)Which gives me this error: Any ideas? The error seems to be happening here: Any ideas? Thanks! |
|
I am able to reproduce this. here's the steps install travis node-js imagedocker run --name travis-debug -dit travisci/ci-garnet:packer-1496954857 /sbin/init
docker exec -it travis-debug bash -lsetup things within the travis shell:su - travis
mkdir tempproj && cd tempproj
yarn init # enter, enter, enter, enter...
yarn add chrome-launcherthen create an index.js with the code from @LucianoGanga's comment above. and run: |
|
you have an error in your code when you upgraded to latest chrome-launcher. heres the launch options you want: chromeOptions = {
chromeFlags: ["--disable-gpu", "--headless", "--enable-logging"]
}you may also want |
|
@paulirish I feel really lame now... Sorry for the trouble! The issue wasn't the name of the properties (I had them right in my production code), but the thing was that the "--headless" flag depended on a variable that was set to false. It didn't cause any kind of problem in my pc, but it did in Linux through command line (still don't know why) I'm really sorry for this, really! You can close this issue. Cheers, PS: at least now you know the trick to get an extra piece of stack in an error ! :P |
|
I'm getting some reports in Navalia with similar error types. I haven't been able to repro myself, but I'll post in this issue if I uncover something 🐟 |
|
@LucianoGanga, you said after upgrading your hardware the problem was gone. We are running into the exact same problems when doing more than four lighthouse runs in parallel. Thank you for your feedback. |
I also get same problems |
Hello!
I don't know why, but when I try to execute multiple instances of Chrome in a Linux env, I get this error:
I've been trying to find more information about this, but I don't know where to start from.
Any idea about what may be the problem?
The text was updated successfully, but these errors were encountered: