I got ECONNREFUSED error running from `npm start` despite Chrome is running about rendertron

[andresrl]

I was having this issue running with npm start and now I solved it.

I've tried the modified version of isDebuggerReady() made in chrome-launcher.js by @hekod777 at GoogleChrome/chrome-launcher#30 and I can see that the Port is being assigned.
Also i have: "chrome-launcher": "^0.8.0",

net.createConnection(this.port) is rejecting the connection. WHY?

Also, I've tried to increase the pollInterval, with no success.

It's a dedicated server with Ubuntu 16.04 and Plesk and Google Chrome 63.0.3239.108

What I did to solve it is to add the '--no-sandbox' to the chromeFlags at main.js, I mean:
const appPromise = chromeLauncher.launch({
chromeFlags: ['--headless', '--disable-gpu', '--remote-debugging-address=0.0.0.0', '--no-sandbox'],

And solved!!!

[hekod777]

looks like the same problem as my last reply in this post

#90

if so, it's the problem of chrome launcher.

you can try to either

1. set the pollInterval to 10000 in chrome-launcher.js

or

2. update the chrome-launcher dependency in Rendertron to 0.8.0 (Currently is 0.3.x)

Though I tried both. and still failed. But some people are saying this fixed the problem.

@RIP21 What is the OS you are using for your digital ocean deployment?

[RIP21]

@hekod777 chrome-launcher.js? Where I can find it. He is not in the repo.

Okay, I found it. It's a dependency. Both fixes didn't worked for me.

[hekod777]

Good.

We are now on the same boat.

I posted this issue on chrome-launcher github page 4 days.

Hopefully they can give a fix soon.

PS: if the performance issue of dockerized Rendertron can be fixed, it will be the best. then I don't have to use this npm start work around ~

[samuelli]

@RIP21: add your site to #113. It can be used for other sites, but I think I'm seeing some issues with the running instance right now.

[samuelli]

It sounds like chrome-launcher only supports some environments and maybe not the DigitalOcean one that you mentioned? The only real dependency is Chrome, so if you have Chrome, maybe we can configure chrome-launcher to point to exactly where it is.

npm start should be fine as long as it can find Chrome.

[RIP21]

It can find Chrome and it even says in which port it was launched, but then failed to succeed.

[RIP21]

@samuelli about my site that was unable to be loaded via your instance, it was a no detection of the page load for some reason. I fixed that using code that is in the Chrome using stupi 5 second timeout to be sure it loaded :)

[hekod777]

the problem of chrome launcher is the debugger

isDebuggerReady(){}

you can find more details about this issue here

GoogleChrome/chrome-launcher#30

[hekod777]

Actually with the newest version of Rendertron, I am able to run Rendertron on an EC2 instance using npm start.

This is the guide I used to install Chrome on EC2 instance.
https://intoli.com/blog/installing-google-chrome-on-centos/

[samuelli]

@hekod777: is that without the docker container then?

[hekod777]

@samuelli

Yes, without docker container.

[hekod777]

@samuelli

This is something I found regarding this --no-sandbox flag

It is not a good fix because sandbox is one of the reasons why chrome is one of the safest browser around. No sandbox mode is just a temporary fix and doesn't really solve the problem. It is like a bypass on chrome so troubleshooters can still look more into chrome so they can better assess the situation. 
I suggest solving the main problem that caused your chrome to stop functioning. You can post more about the details of your problem in the forums.

This is the comic explaining --no-sandbox flag.

https://www.google.com/googlebooks/chrome/big_26.html

As for rendertron, since it's only rendering pages for bots and it's rendering the pages we want it to render, I think it's safe to use for rendertron.

[itmayziii]

It's not fair to say no sandbox is bad and not provide a solution