New issue
Advanced search Search tips

Issue 845980 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Devtools socket not responding for a very long time

Reported by gam...@elastic.co, May 23 2018

Issue description

We are using headless chromium to generate screenshots. On most OS's it's running as expected, but on one Ubuntu linux 16.04, we are running into problems.

A bit of a shot in the dark but posting here to see if anyone has any ideas. More details can be found here: https://github.com/elastic/kibana/issues/19351

We see the `DevTools listening on ws://127.0.0.1:${bridgePort}` line after booting up chromium. However, a subsequent curl command to `http://127.0.0.1:${bridgePort}/json` takes 25 seconds to return a value.


 
Labels: Needs-Milestone

Comment 2 by gam...@elastic.co, May 23 2018

We determined the issue when running strace during a slow start up.  It appears font-config is taking a very long time loading fonts into a cache. It only runs slow the first time around, after which, once the cache is loaded, it's fine. This became a problem in our test environment because the cache was cleared at the start of each run.

The problem remains that chrome-remote-interface times out with a socket hang up because chromium is taking so long to boot up during this initial run (despite spitting out the 'listening on ws...' line).

We may create a PR against chrome-remote-interface to add a timeout parameter, or add in a retry somehow.
Status: WontFix (was: Unconfirmed)
Thanks for the update! It does indeed sound like chrome-remote-interface should introduce a timeout for this.

Comment 4 by gam...@elastic.co, Jun 15 2018

Or another potential solution is to show "DevTools listening on ws://127.0.0.1:${bridgePort}" after the font config loading, not before, and then it is accurate that the port is actually ready and listening. :)

Sign in to add a comment