Selenium hangs when launching Firefox on Ubuntu

Question

My end goal is to have Selenium running 'within' Jenkins. My Jenkins installation runs within an Ubuntu virtual machine.

After some issues with the jenkins selenium setup (stemming from permissions for the user that jenkins runs under) I switched to running the command from the command line to see what was happening. My aim is to get the test running here, and then to get it working within Jenkins.

Here's the command and responses I'm currently using and seeing.

resn@resn-VirtualBox:~$ sudo java -jar /var/lib/jenkins/tools/selenium/selenium-server.jar -htmlSuite *firefox http://google.com "/var/lib/jenkins/jobs/Selenium setup test/workspace/tests/test-testsuite.html" "/var/lib/jenkins/jobs/Selenium setup test/workspace/results/results.html" -log=/tmp/selenium.log -debug=true -firefoxProfileTemplate "/home/resn/.mozilla/firefox/6f2um01h.Selenium"

23/08/2011 11:19:51 AM org.openqa.grid.selenium.GridLauncher main
INFO: Launching a standalone server
11:19:52.172 INFO - Java: Sun Microsystems Inc. 19.0-b09
11:19:52.173 INFO - OS: Linux 2.6.35-28-generic i386
11:19:52.223 INFO - v2.4.0, with Core v2.4.0. Built from revision 13337
11:19:52.488 INFO - RemoteWebDriver instances should connect to: http://127.0.0.1:4444/wd/hub
11:19:52.491 INFO - Version Jetty/5.1.x
11:19:52.491 INFO - Started HttpContext[/selenium-server/driver,/selenium-server/driver]
11:19:52.501 INFO - Started HttpContext[/selenium-server,/selenium-server]
11:19:52.501 INFO - Started HttpContext[/,/]
11:19:52.520 INFO - Started org.openqa.jetty.jetty.servlet.ServletHandler@15b7986
11:19:52.521 INFO - Started HttpContext[/wd,/wd]
11:19:52.530 INFO - Started SocketListener on 0.0.0.0:4444
11:19:52.530 INFO - Started org.openqa.jetty.jetty.Server@54172f
11:19:53.379 INFO - Preparing Firefox profile...
11:19:55.949 INFO - Launching Firefox...

The Ubuntu virtual machine is not a headless instance, so AFAIK I don't need to install xvfb (as is mentioned in some blog posts on the same topic).

Previous to this issue, I had an issue with Firefox profiles, which I fixed using the approach I answered with here : Jenkins can't launch selenium tests (Timed out waiting for profile to be created)

Firefox opens fine when launched using the shortcut within the Applications menu, and from just entering 'firefox' on the command line.

I've tried adding the full path to the Firefox application, in numerous ways :

• In the command '... *firefox /usr/lib/firefox-3.6.20/firefox.sh ..." Which results in "Can't find HTML Suite file:/home/resn/http:/google.com:" - it seems to get the firefox path mixed up with the next parameter

• In the command, without a space '... "firefox/usr/lib/firefox-3.6.20/firefox.sh ...' Which results in

  "HTML suite exception seen: java.lang.RuntimeException: Browser not supported: *firefox/usr/lib/firefox-3.6.20/firefox.sh

  Supported browsers include: *firefox"

• In grid_configuration.yml ' ... browser: "*firefox /usr/lib.firefox-3.6.20/firefox.sh". Which didn't have any impact.

Also, because the process just hangs, and doesn't actually fail, the log file (/tmp/selenium.log) isn't created.

Any ideas, tips or debugging suggestions would be very welcome!

Answer 1

The problem seems to be when running in a headless environment. If you don't have a window for it to render your browser in, it will hang. You can test this by pasting the same command when you ssh into your machine, but instead do ssh -X [email protected]

I found this documentation on what you can do to fix this: http://www.alittlemadness.com/2008/03/05/running-selenium-headless/

Answer 2

I had the same problem too and none of the solutions I found worked:

• No issue with the firefox executable path
• Headless display was already running
• There was no issue with browser profile

What I did, was try to run firefox manually (after setting the DISPLAY) - upon which I got the error:

D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open /var/lib/dbus/machine-id

I had no idea how this issue occurred out of the blue, but it was relatively simple to fix:

dbus-uuidgen > /var/lib/dbus/machine-id

according to http://www.torkwrench.com/2011/12/16/d-bus-library-appears-to-be-incorrectly-set-up-failed-to-read-machine-uuid-failed-to-open-varlibdbusmachine-id