Docker-selenium: node-chrome with --headless rather than XVFB

[graingert]

Run node-chrome with --headless rather than XVFB, to reduce resource usage.

[graingert]

Users don't browse in xvfb, what's your point?

[ddavison]

no, users use the physical browser. Xvfb allows the rendering of said physical browsers.

[graingert]

Are you suggesting that chrome --headless behaves differently from chrome
under xvfb?

On 12 Apr 2017 02:29, "Dj" [e-mail] wrote:

no, users use the physical browser. Xvfb allows the rendering of said
physical browsers.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-293446550,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTMWyJFMfal-UsVak1INjMBFNCeS7ks5rvCkKgaJpZM4MusZ3
.

[SpencerMalone]

PhantomJS' solo maintainer is leaving because of headless chrome. Can we reopen this discussion? (source: https://groups.google.com/forum/#!topic/phantomjs/9aI5d-LDuNE)

[ddavison]

i guess i'm not familiar with chrome's headless mode.. tell me more, @graingert

[graingert]

@ddavison you run chrome --headless and it manages its own internal framebuffer, rather than needing X11

It should massively simplify the default node-chrome.

Also it's got a VNC like protocol over the chrome debug socket, so you wouldn't need node-chrome-debug either

[ddavison]

I think the biggest benefit that users find with the debug, is that you can VNC into it. You're saying that this could be eliminated? If that's the case, ok then. sign me up - apologies for the abrupt closing. An issue file with a very small description is dangerous as it leaves everything up to speculation :)

I wasn't familiar with chrome --headless (hence why i asked you to elaborate)

If this is possible, then yes.. we'll go this route. I'll keep this issue open and i'll mark as investigating.

[madhavajay]

I think most automated testing will use chrome headless going forwards, and using docker for automated testing is a perfect fit, so this just seems like an obvious thing, in fact, iv been asking about it for the last few months and even tried to roll my own but chrome --headless was buggy. Big +1 from me on this as PhantomJS 2.5 release isn't even available and maybe we won't see it now that the maintainer has stepped down.

The main reason is quite simple.... Chrome uses a lot of memory and cpu and that should be lower without Xvfb and real rendering.

[SpencerMalone]

So, I just put in some time into this. XVFB will still be required for almost all projects, sadly (unless someone finds a workaround)

In general it wasn't too rough to get running, but I get thrown the following when I try to use it for tests that have keyCode interactions (aka, any sendkeys stuff):

unknown error: an X display is required for keycode conversions, consider using Xvfb
        (Session info: content shell=)
        (Driver info: chromedriver=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5),platform=Linux 4.9.4-moby x86_64) (WARNING: The server did not provide any stacktrace information)
      Command duration or timeout: 26 milliseconds
      Build info: version: '2.52.0', revision: '4c2593c', time: '2016-02-11 19:06:42'
      System info: host: '1d5acd9906ce', ip: '172.17.0.4', os.name: 'Linux', os.arch: 'amd64', os.version: '4.9.4-moby', java.version: '1.8.0_121'
      Driver info: org.openqa.selenium.chrome.ChromeDriver

EDIT: Throwing XVFB in and using that to run the SE process (like normal), it all works properly, I'm just not sure that we're gaining much if we do that.

I haven't poked around with this repo in ages. Do y'all have a standardish way of measuring performance?

[SpencerMalone]

I guess the XVFB thing is a chromedriver requirement, so I opened a ticket here: https://bugs.chromium.org/p/chromedriver/issues/detail?id=1772

If you wanna reproduce / help out with finding a fix, you can find steps to make an easy one-off container that runs selenium locally (without a hub/node configuration) in that issue. It's easy enough to convert those steps into the docker-selenium containers, but the send key stuff still exists.

[elgalu]

Indeed, I managed even to set the Chrome browser window size but once I removed Xvfb from docker-selenium I was also bitten by @SpencerMalone error:

Failed: unknown error: an X display is required for keycode conversions, consider using Xvfb
  (Session info: headless chrome=58.0.3029.81)
  (Driver info: chromedriver=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5),platform=Linux 4.4.0-72-generic x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 22 milliseconds
Build info: version: '3.3.1', revision: '5234b32', time: '2017-03-10 09:04:52 -0800'
System info: host: 'ccd8e5f77172', ip: '172.17.0.2', os.name: 'Linux', os.arch: 'amd64', os.version: '4.4.0-72-generic', java.version: '1.8.0_121'
Driver info: org.openqa.selenium.chrome.ChromeDriver
Capabilities [{applicationCacheEnabled=false, rotatable=false, mobileEmulationEnabled=false, networkConnectionEnabled=false, chrome={chromedriverVersion=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5), userDataDir=/tmp/.org.chromium.Chromium.u1tWQG}, takesHeapSnapshot=true, pageLoadStrategy=normal, databaseEnabled=false, handlesAlerts=true, hasTouchScreen=false, version=58.0.3029.81, platform=LINUX, browserConnectionEnabled=false, nativeEvents=true, acceptSslCerts=true, locationContextEnabled=true, webStorageEnabled=true, browserName=chrome, takesScreenshot=true, javascriptEnabled=true, cssSelectorsEnabled=true, unexpectedAlertBehaviour=}]
Session ID: a7bc6bb38644f13e7a9c9b2c33fbcd61

[testphreak]

I like the idea but please do not remove the current node-chrome and node-chrome-debug images when creating the headless images. I still like the idea of using real browsers inside containers.

[diemol]

I think there won't be need to remove them, or even create a new image, you just need to pass some specific capabilities to Chrome, I think @elgalu showed them to me yesterday, can you share them?

[elgalu]

Correct, this works already:

capabilities: {
    browserName: 'chrome',
    chromeOptions: {
        args: ['headless', 'window-size=1920x1080']
    }
}

[erithmetic]

Using the selenium node base image, I've found the following configuration works best:

capabilities: {
    browserName: 'chrome',
    chromeOptions: {
        args: ['headless','no-sandbox','disable-gpu','window-size=1920x1080']
    }
}

Keeping the sandbox enabled caused an exception when selenium tried to start chrome.

I put together an example app that extends the selenium node base image, installs latest snapshot of chromium (with headless bugfixes), and installs a recent build of chromedriver which allows chrome > 59. Unfortunately, I also discovered xvfb is required for sendKeys to work.

[graingert]

Would be good to have a separate image node-chrome-headless to save space
on xvfb and deps

On 22 Apr 2017 16:10, "Derek Kastner" [e-mail] wrote:

Using the selenium node base image, I've found the following configuration
works best:

capabilities: {
browserName: 'chrome',
chromeOptions: {
args: ['headless','no-sandbox','disable-gpu','window-size=1920x1080']
}
}

Keeping the sandbox enabled caused an exception when selenium tried to
start chrome.

I put together an example app
https://github.com/dkastner/headless-chromium-selenium that extends the
selenium node base image, installs latest snapshot of chromium (with
headless bugfixes), and installs a recent build of chromedriver which
allows chrome > 59. Unfortunately, I also discovered xvfb is required for
sendKeys to work.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-296379624,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTF5zuwN0IBMsL9Bq1m1B9eulvid5ks5ryhhOgaJpZM4MusZ3
.

[alippai]

Awesome! This sounds like it requires half the resources of selenium/standalone-chrome (e.g. disk, RAM)

[ghost]

yes, which would be super useful as we're hitting the resource limits on our aws instances using the standard selenium images. Headless should help there.

[diemol]

@graingert, is it possible already to run Chrome headless without xvfb?

[graingert]

Yes

On 28 May 2017 18:31, "Diego Molina" [e-mail] wrote:

@graingert https://github.com/graingert, is it possible already to run
Chrome headless without xvfb?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-304528556,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTGeJl_QBzx8dASjI8P2XPBjTHTWYks5r-a-CgaJpZM4MusZ3
.

[diemol]

@graingert I was asking because if this https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-296379624
Do you have an example of an image running Chrome headless without xvfb?

[jorgeluisdelgado]

@diemol @graingert

I would also like to know this.

[SpencerMalone]

It was recently mentioned here:
https://bugs.chromium.org/p/chromedriver/issues/detail?id=1772#c12 that you
might be able to use a different flag when chrome is compiled to fix the
sendkeys issue, but I've yet to try it.

On May 29, 2017 9:53 PM, "Jorge Delgado" [e-mail] wrote:

@diemol https://github.com/diemol @graingert
https://github.com/graingert

I would also like to know this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-304755902,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIYTQMj741-drZH33CdZiQHQH3DboI-jks5r-3aFgaJpZM4MusZ3
.

[jorgeluisdelgado]

I have found a workaround. It is simply to not use send key and instead use Javascript. Here is an example:

driver = webdriver.Chrome()
driver.find_elements_by_id('solveme').send_keys(Solution)

becomes:

driver = webdriver.Chrome()
Command = "document.getElementById('solveme').value='"+ Solution +"';"
driver.execute_script(Command)

There are multiple selectors for javascript you can use including name, id, class, etc. The above example is with python but it should work with all languages that allow javascript executions using selenium. This is an extremely frustrating issue as the majority of my tests required inputting text into some field. As a temporary workaround, I would suggest using this.

[BluePhoenix]

This link was shared with me, and seems to have a lot of nice details that might help with what we are trying to achieve here.

Getting Started with Headless Chrome
By Eric Bidelman
https://developers.google.com/web/updates/2017/04/headless-chrome

[UsainBloot]

I found this to be the best solution to running chrome headless.

https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-296379624

Chromedriver 2.30 which was released a couple of days ago allows for the resizing of the browser window (as it was previously done via an extension which are not allowed in headless and since moved to a dev tools API).

However, even with this setup I am still seeing an issue with sendKeys without Xvfb.
Annoyingly the blog post above states that you do not require Xvfb at all to use headless chrome but that does not seem to be the case.

[graingert]

You've got to hack sendKeys via JavaScript

On 12 Jun 2017 21:54, "Jack Palmer" [e-mail] wrote:

I found this to be the best solution to running chrome headless.

429 (comment)

https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-296379624

Chromedriver 2.30 which was released a couple of days ago allows for
the resizing of the browser window (as it was previously done via an
extension which are not allowed in headless and since moved to a dev
tools API https://sites.google.com/a/chromium.org/chromedriver/downloads
).

However, even with this setup I am still seeing an issue with sendKeys
without xvfb setup.
Annoyingly the blog post above states that you do not require xvfb at
all to use headless chrome but that does not seem to be the case

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-307908991,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTINi_BUAaT0VgDHCGg-QFDzUPkiFks5sDZpMgaJpZM4MusZ3
.

[UsainBloot]

I understand that you can use JavaScript as a work around but as I am using selenium to recreate user journeys then the steps should reflect how a user is interacting with a webpage, rather than using a hack to get by.

I really hope chromium address this issue soon, otherwise I don't see headless chrome being a viable headless browser anytime soon.

[ari-el-muhandiz]

@Rosefox911 thanks, your solution is working for me

[guillaumevincent]

@UsainBloot Do you solve your issue? Because even with Xvfb installed in my docker container my chromedriver is not working

[UsainBloot]

@guillaumevincent, I haven't look at it since because in my own opinion, having to use xvfb with chrome headless does not make the browser headless.

Chromium devs have said that they will look into it, but have not given a timeframe.

[SpencerMalone]

It's supposedly fixed if you build chrome with ozone. Currently working on pushing up an image with those build args so that we can play with it. Sadly, the chrome build process is a 🐢

[guillaumevincent]

I confirm @UsainBloot answer. Here an error on docker centos 7 running chromedriver 2.30:

unknown error: an X display is required for keycode conversions, consider using Xvfb\n  (Session info: headless chrome=59.0.3071.109)\n  (Driver info: chromedriver=2.30.477691 (6ee44a7247c639c0703f291d320bdf05c1531b57),platform=Linux 3.10.0-514.21.2.el7.x86_64 x86_64)

So the only gain for now to use Chrome headless is to no longer need Java.
We still need fonts and Xvfb running. Here a solution on docker centos 7:

yum install -y Xvfb libXfont Xorg
/usr/bin/Xvfb :99 -ac -screen 0 1920x1080x24 &
export DISPLAY=:99

I will check on chrome-unstable to see if there is any improvement

[tabiodun]

@SpencerMalone which args and which environment are you trying to use to build chrome. I can't seem to get it to work after building with the ozone flag on Ubunutu 14.04

[SpencerMalone]

I don't have it working yet either, I was going off of reports from the chromium ticket I opened here: https://bugs.chromium.org/p/chromedriver/issues/detail?id=1772

I'm still struggling with getting a fast and repeatable build for chrome in docker. Currently it takes many hours and can't even be done on a default devicemapper file system because the dang image ends up so large.

[tabiodun]

I finally got a build of chrome using docker that seems to confirm that the ozone flag does fix this issue. I haven't run it against my test suite, but the sample selenium python example that uses sendKeys works.

[SpencerMalone]

I'm at the same point. For those following along, my final dockerfile for building chrome/chromedriver w/ ozone: https://gist.github.com/SpencerMalone/6f764a101c9ffd4a86829f158eef9d41

I must have screwed up something along the way as I cannot copy the final artifacts (chrome+chromedriver) into another image as use them. None of the libraries seem linked properly?

Regardless, if you feel like doing the many hour build, at the end you can put chromedriver and chrome into your docker container's path and start up chromedriver+selenium (after installing selenium) with the chromedriver arguments... --headless --no-sandbox --disable-gpu

[tabiodun]

Looks like the latest revision has fixed this issue https://codereview.chromium.org/2952383002 and https://bugs.chromium.org/p/chromedriver/issues/detail?id=1772#c28. I've built a version of this and it seems to now work WITHOUT the ozone flag. I'm hoping the next PPA for google-chrome-unstable will have the changes and there will be no need for these long builds.

BTW your Dockerfile looks VERY similar to what I have. I used gn gen to do the args though.

[UsainBloot]

Great find @tabiodun, hopefully the next build will solve our issues!

[graingert]

Yeah and it would be super cool to get this available out of the box in docker selenium

[tabiodun]

After playing around a bit and looking at the commit for the fix, it looks like this is a chromedriver only problem, which means it it much easier to just build chromedriver standalone to use for any selenium tests you want to run. However, I think chromedriver is on a release schedule that is a bit less frequent so getting an official fix will have to wait for the next chromedriver release.

In case this is useful to anyone, I have a working build of chromedriver for ubuntu which I built in an ubuntu 14.04 docker container here

[graingert]

@tabiodun probably best to have this on docker hub.

[tabiodun]

@graingert Good call

https://hub.docker.com/r/tabiodun/selenium-chrome-headless/

[pumano]

Good news guys:
according to: https://bugs.chromium.org/p/chromedriver/issues/detail?id=1772#c29
it fixed with : https://codereview.chromium.org/2952383002

as mentioned here: https://bugs.chromium.org/p/chromedriver/issues/detail?id=1772#c31

The fix will be included in ChromeDriver 2.31. Its release date hasn't been determined yet.

[bbuchalter]

I don't see any way to subscribe to notifications for when a new version of chromedriver is released. Anyone have thoughts on that?

[tabiodun]

If anyone needs to build the latest chromedriver for testing with the fixes in place, I have a Dokcerfile for this. Once the chromedriver here is generated, it is portable.

https://gist.github.com/tabiodun/e4204ab83b3b7cfd2d28b478cf441162

[jalexvig]

Using this dockerfile, here is a compiled chromedriver for linux.

https://github.com/jalexvig/build_chromium_docker

[bbuchalter]

https://github.com/jalexvig/build_chromium_docker

Does anyone have something like this that's built on jessie instead of ubuntu? I'm having trouble porting this one. Alternatively, could I just use the binary in that repo safely on a different container?

[Shyam-Chen]

# Dockerfile

[...]

# chrome --
ENV CHROME_BIN /usr/bin/chromium
ENV DISPLAY :99

RUN \
  apt-get update && \
  apt-get install -y xvfb chromium libgconf-2-4

ENTRYPOINT ["Xvfb", "-ac", ":99", "-screen", "0", "1280x720x16"]
# -- chrome

[...]

[fiedl]

As mentioned in the bug report, @davidthornton has compiled a binary of chromedriver-2.31, which includes the fix.

https://github.com/davidthornton/chromedriver-2.31

I've successfully used this by adding this oneliner to my ci install script:

mkdir -p ~/chromedriver && wget https://github.com/davidthornton/chromedriver-2.31/blob/master/chromedriver\?raw\=true -O ~/chromedriver/chromedriver && chmod a+x ~/chromedriver/chromedriver && export PATH="$HOME/chromedriver:$PATH"

Let's hope they'll release chromedriver 2.31 soon!

Check the releases here: https://sites.google.com/a/chromium.org/chromedriver/downloads

[boonyasukd]

homebrew just got updated to include chromedriver 2.31 around 17 minutes ago. Apparently the builds had been completed for a few days now, but chromedriver site doesn't get updated yet.

Grab the binary here.

[UsainBloot]

For anyone using vvo/selenium-standalone I have a PR that defaults to the new version of chromedriver.

https://github.com/vvo/selenium-standalone/pull/290

[guillaumevincent]

npm install chromedriver install version 2.31 and download the good version for your system

Downloading https://chromedriver.storage.googleapis.com/2.31/chromedriver_linux64.zip

Thank you guys

[stguitar]

I was also having this issue and can confirm simply updating chromedriver to 2.31 removed the need to use Xvfb

[cbrevik]

Is people getting --headless to work with this library? Keep getting unknown error: Chrome failed to start: exited normally as noted in #520

[guillaumevincent]

@cbrevik don't know if it's the solution but on centos 7 container I added liberation-mono-fonts package to avoid this error

[cbrevik]

Thanks for the suggestion @guillaumevincent! Ran fc-list on the container, and it seems like Liberation Mono is already installed.

[ttretau]

I updated image to Chromedriver 2.31 and received errors like @cbrevik, WebDriverError: unknown error: Chrome failed to start: exited abnormally. I think from chromedriver logs RESPONSE InitSession unknown error: Chrome failed to start: exited abnormally.
I used args '--headless', '--disable-gpu', '--window-size=800,600' via protractor.

[Nighthawk22]

I get the following exception if i run chrome headless

13:22:32.631 INFO - Executing: [new session: Capabilities [{rotatable=true, locationContextEnabled=true, loggingPrefs=org.openqa.selenium.logging.LoggingPreferences@3631f3e0, browserName=chrome, javascriptEnabled=true, chromeOptions={args=[--window-size=1280,800, --disable-gpu, --headless]}, handlesAlerts=true, requestOrigins={name=webdriverio, version=4.6.2, url=http://webdriver.io}}]])
13:22:32.650 INFO - Creating a new session for Capabilities [{rotatable=true, locationContextEnabled=true, loggingPrefs=org.openqa.selenium.logging.LoggingPreferences@3631f3e0, browserName=chrome, javascriptEnabled=true, chromeOptions={args=[--window-size=1280,800, --disable-gpu, --headless]}, handlesAlerts=true, requestOrigins={name=webdriverio, version=4.6.2, url=http://webdriver.io}}]
Starting ChromeDriver 2.30.477691 (6ee44a7247c639c0703f291d320bdf05c1531b57) on port 13834
Only local connections are allowed.
13:23:32.925 WARN - Exception thrown
java.util.concurrent.ExecutionException: org.openqa.selenium.WebDriverException: java.lang.reflect.InvocationTargetException
Build info: version: '3.4.0', revision: 'unknown', time: 'unknown'
System info: host: 'chrome-4040051761-dgtxj', ip: '192.168.249.212', os.name: 'Linux', os.arch: 'amd64', os.version: '4.10.0-30-generic', java.version: '1.8.0_131'
Driver info: driver.version: unknown
    at java.util.concurrent.FutureTask.report(FutureTask.java:122)
    at java.util.concurrent.FutureTask.get(FutureTask.java:192)
    at org.openqa.selenium.remote.server.DefaultSession.execute(DefaultSession.java:183)
    at org.openqa.selenium.remote.server.DefaultSession.<init>(DefaultSession.java:119)
    at org.openqa.selenium.remote.server.DefaultSession.createSession(DefaultSession.java:95)
    at org.openqa.selenium.remote.server.DefaultDriverSessions.newSession(DefaultDriverSessions.java:131)
    at org.openqa.selenium.remote.server.handler.NewSession.handle(NewSession.java:59)
    at org.openqa.selenium.remote.server.handler.NewSession.handle(NewSession.java:36)
    at org.openqa.selenium.remote.server.rest.ResultConfig.handle(ResultConfig.java:111)
    at org.openqa.selenium.remote.server.JsonHttpCommandHandler.handleRequest(JsonHttpCommandHandler.java:190)
    at org.openqa.selenium.remote.server.DriverServlet.handleRequest(DriverServlet.java:222)
    at org.openqa.selenium.remote.server.DriverServlet.doPost(DriverServlet.java:184)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
    at org.openqa.selenium.remote.server.DriverServlet.service(DriverServlet.java:150)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.seleniumhq.jetty9.servlet.ServletHolder.handle(ServletHolder.java:841)
    at org.seleniumhq.jetty9.servlet.ServletHandler.doHandle(ServletHandler.java:543)
    at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
    at org.seleniumhq.jetty9.server.handler.ContextHandler.doHandle(ContextHandler.java:1228)
    at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
    at org.seleniumhq.jetty9.servlet.ServletHandler.doScope(ServletHandler.java:481)
    at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
    at org.seleniumhq.jetty9.server.handler.ContextHandler.doScope(ContextHandler.java:1130)
    at org.seleniumhq.jetty9.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at org.seleniumhq.jetty9.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.seleniumhq.jetty9.server.Server.handle(Server.java:564)
    at org.seleniumhq.jetty9.server.HttpChannel.handle(HttpChannel.java:320)
    at org.seleniumhq.jetty9.server.HttpConnection.onFillable(HttpConnection.java:251)
    at org.seleniumhq.jetty9.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
    at org.seleniumhq.jetty9.io.FillInterest.fillable(FillInterest.java:112)
    at org.seleniumhq.jetty9.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
    at org.seleniumhq.jetty9.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
    at org.seleniumhq.jetty9.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
    at java.lang.Thread.run(Thread.java:748)
Caused by: org.openqa.selenium.WebDriverException: java.lang.reflect.InvocationTargetException
Build info: version: '3.4.0', revision: 'unknown', time: 'unknown'
System info: host: 'chrome-4040051761-dgtxj', ip: '192.168.249.212', os.name: 'Linux', os.arch: 'amd64', os.version: '4.10.0-30-generic', java.version: '1.8.0_131'
Driver info: driver.version: unknown
    at org.openqa.selenium.remote.server.DefaultDriverProvider.callConstructor(DefaultDriverProvider.java:110)
    at org.openqa.selenium.remote.server.DefaultDriverProvider.newInstance(DefaultDriverProvider.java:96)
    at org.openqa.selenium.remote.server.DefaultDriverFactory.newInstance(DefaultDriverFactory.java:60)
    at org.openqa.selenium.remote.server.DefaultSession$BrowserCreator.call(DefaultSession.java:222)
    at org.openqa.selenium.remote.server.DefaultSession$BrowserCreator.call(DefaultSession.java:209)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at org.openqa.selenium.remote.server.DefaultSession$1.run(DefaultSession.java:176)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    ... 1 more
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.openqa.selenium.remote.server.DefaultDriverProvider.callConstructor(DefaultDriverProvider.java:102)
    ... 9 more
Caused by: org.openqa.selenium.WebDriverException: unknown error: Chrome failed to start: exited normally
  (Driver info: chromedriver=2.30.477691 (6ee44a7247c639c0703f291d320bdf05c1531b57),platform=Linux 4.10.0-30-generic x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 60.07 seconds
Build info: version: '3.4.0', revision: 'unknown', time: 'unknown'
System info: host: 'chrome-4040051761-dgtxj', ip: '192.168.249.212', os.name: 'Linux', os.arch: 'amd64', os.version: '4.10.0-30-generic', java.version: '1.8.0_131'
Driver info: driver.version: ChromeDriver
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:215)
    at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:167)
    at org.openqa.selenium.remote.JsonWireProtocolResponse.lambda$new$0(JsonWireProtocolResponse.java:53)
    at org.openqa.selenium.remote.JsonWireProtocolResponse.lambda$getResponseFunction$2(JsonWireProtocolResponse.java:91)
    at org.openqa.selenium.remote.ProtocolHandshake.lambda$createSession$22(ProtocolHandshake.java:365)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
    at java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958)
    at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
    at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
    at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
    at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
    at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
    at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:368)
    at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:159)
    at org.openqa.selenium.remote.HttpCommandExecutor.execute(HttpCommandExecutor.java:142)
    at org.openqa.selenium.remote.service.DriverCommandExecutor.execute(DriverCommandExecutor.java:82)
    at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:637)
    at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:250)
    at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:236)
    at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:137)
    at org.openqa.selenium.chrome.ChromeDriver.<init>(ChromeDriver.java:184)
    at org.openqa.selenium.chrome.ChromeDriver.<init>(ChromeDriver.java:148)
    ... 14 more
13:23:32.934 WARN - Exception: unknown error: Chrome failed to start: exited normally
  (Driver info: chromedriver=2.30.477691 (6ee44a7247c639c0703f291d320bdf05c1531b57),platform=Linux 4.10.0-30-generic x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 60.07 seconds

[uday-rayala]

Even I am getting the above error. Does anyone know how to avoid this error?

Following are chrome and chromedriver versions:

seluser@b5289d951007:/$ chromedriver --version
ChromeDriver 2.31.488763 (092de99f48a300323ecf8c2a4e2e7cab51de5ba8)

seluser@b5289d951007:/$ ./opt/google/chrome/chrome --version
Google Chrome 61.0.3163.79 unknown

I am using 3.5.3 version of https://hub.docker.com/r/selenium/standalone-chrome-debug/tags/

[csvan]

+1

[diemol]

Hi,

After reading all the thread again it looks like this should work already, right? Has someone achieved it and wants to send a PR?

[diemol]

Does anyone know if this is the current status for headless?
https://bugs.chromium.org/p/chromium/issues/detail?id=775911

I checked around and I didn't find any more updates. If this stays like that, it wouldn't make so much sense to have headless as default.

[lmtierney]

I believe it is going to stay that way, at least until https://bugs.chromium.org/p/chromium/issues/detail?id=617931 has some movement

[tnguyen14]

Looks like 617931 is fixed, but 775911 is marked as "WontFix"

[graingert]

Have you got URLs for those tix?

On 15 Feb 2018 19:45, "Tri Nguyen" [e-mail] wrote:

Looks like 617931 is fixed, but 775911 is marked as "WontFix"

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-366040090,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTCYIUhH1SYUh02piQ_hwQTXzbkgzks5tVIk9gaJpZM4MusZ3
.

[tnguyen14]

I was referring to these 2 previous comments:

I believe it is going to stay that way, at least until https://bugs.chromium.org/p/chromium/issues/detail?id=617931 has some movement

and

Does anyone know if this is the current status for headless?
https://bugs.chromium.org/p/chromium/issues/detail?id=775911

[diemol]

Hi all,

We just made a change in the images and introduces the env var START_XVFB, you can set it to false(or anything different to true when starting the container, and then Xvfb won't be started.

docker network create grid
docker run -d -p 4444:4444 --net grid --name selenium-hub selenium/hub
docker run -d --net grid -e HUB_HOST=selenium-hub -e START_XVFB=false -v /dev/shm:/dev/shm selenium/node-chrome
docker run -d --net grid -e HUB_HOST=selenium-hub -e START_XVFB=false -v /dev/shm:/dev/shm selenium/node-firefox

If you do that, and check the running processes in the container, you'll see:

seluser@6c5028fb1dad:~$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
seluser      1  0.2  0.1  58660 18484 ?        Ss   20:30   0:00 /usr/bin/python /usr/bin/supervisord --configuration /etc/supervisord.conf
seluser     13  0.0  0.0  20988  3364 ?        S    20:30   0:00 /bin/bash /opt/bin/start-selenium-node.sh
seluser     26  5.1  1.2 7244440 129376 ?      Sl   20:30   0:03 java -jar /opt/selenium/selenium-server-standalone.jar -role node -hub http://selenium-hub:4444/grid/register -nodeConfig /opt/selenium/config.json
seluser     55  0.0  0.0  21188  3792 pts/0    Ss   20:31   0:00 bash
seluser    774  0.0  0.0  37360  3244 pts/0    R+   20:32   0:00 ps aux

So Xvfb won't run and you'll need to run tests with the headless flag set to true, e.g. in Java:

    @Test()
    public void firefoxTest() throws Exception {
        FirefoxOptions firefoxOptions = new FirefoxOptions();
        firefoxOptions.setHeadless(true);
        WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), firefoxOptions);
        driver.get("http://the-internet.herokuapp.com");
        Assert.assertEquals(driver.getTitle(), "The Internet");
        driver.quit();
    }

and for Chrome:

    @Test()
    public void chromeProfile() throws Exception {
        ChromeOptions chromeOptions = new ChromeOptions();
        chromeOptions.setHeadless(true);
        WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), chromeOptions);
        driver.get("http://the-internet.herokuapp.com");
        Assert.assertEquals(driver.getTitle(), "The Internet");
        driver.quit();
    }

Therefore you can now run the images without Xvfb. I will comment again when the images with this change are released and pushed to Docker Hub.

[diemol]

Released https://github.com/SeleniumHQ/docker-selenium/releases/tag/3.14.0-francium

[tnguyen14]

@diemol if I understand this correctly, I can use headless, but in order to do debugging (with VNC), I would still need xvfb?

[graingert]

No, with Chrome you can pass video with the devtools protocol

On Wed, 3 Oct 2018, 22:38 Tri Nguyen, [e-mail] wrote:

@diemol https://github.com/diemol if I understand this correctly, I can
use headless, but in order to do debugging (with VNC), I would still need
xvfb?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-426810786,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTHvNL4kDKaQrSwBAV-2VWNhOlkdfks5uhS5IgaJpZM4MusZ3
.

[tnguyen14]

Is there any specific instruction for how I can do that (open and see the video feed)?

[graingert]

https://developers.google.com/web/updates/2017/04/headless-chrome#frontend

On Wed, 3 Oct 2018, 22:48 Tri Nguyen, [e-mail] wrote:

Is there any specific instruction for how I can do that (open and see the
video feed)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/429#issuecomment-426814911,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTDHXLHAg9o-whjbCeNWlN85vJsdeks5uhTCSgaJpZM4MusZ3
.