Not enough entropy

I was writing documentation for using VNC to watch Behat tests being executed with the selenium2 driver on a remote server, when I ran into a strange behavior.

I'd set up Behat 3 on my desktop and was successfully running Selenium Server 2.42.2 with Firefox 31. After following the same setup process I'd used locally on a clean Digital Ocean VM, the Behat tests wouldn't run.

Everything seemed in order, but the example test failed with:

Could not open connection (Behat\Mink\Exception\DriverException)

Selenium wasn't giving me any error messages. I dinked around with the behat.yml a bit since there are a lot of new options. I also compared versions of the relevant software, environment variables and the like before a collegue suggested starting Selenium with the -debug option

DISPLAY=:1 java -jar /opt/selenium-server-standalone-2.42.2.jar -debug

The last line of the output read:

01:38:22.614 DEBUG - New random session seed

On the desktop, the output continued:

01:34:02.559 DEBUG - New random session seed
01:34:02.590 DEBUG - Started holder of class org.openqa.selenium.remote.server.DriverServlet
01:34:02.592 INFO - Started org.openqa.jetty.jetty.servlet.ServletHandler@200bd7c0
01:34:02.592 INFO - Started HttpContext[/wd,/wd]
01:34:02.595 DEBUG - Session scavenger period = 30s
01:34:02.597 INFO - Started SocketListener on 0.0.0.0:4444
01:34:02.597 INFO - Started org.openqa.jetty.jetty.Server@20c2b8eb

I googled "selenium socketlistener" to no avail. The results all described error conditions, not silent failure. They did give a hint, though, because they were all starting Selenium Server in hub mode.

I tried starting and connecting in hub mode, and the SocketListener started successfully.

This provided the clue: add "standalone" to the search terms. "selenium standalone doesn't start socketlistener" took me to this Stack Overflow issue: http://stackoverflow.com/questions/14058111/selenium-server-doesnt-bind-to-socket-after-being-killed-with-sigterm which, despite describing a different set of circumstances, provided the solution:

Java's RNG reds from /dev/random, and the entropy pool on the Digital Ocean instance was apparently exhausted. Using `/dev/urandom` solved the problem:

-Djava.security.egd=file:/dev/./urandom

The full command start command for Selenium Server

DISPLAY=:1 java -jar /opt/selenium-server-standalone-2.42.2.jar -Djava.security.egd=file:/dev/./urandom

There's some debate on the StackExchange issue as to whether the fix will work and whether it accurately describes the problem. It did consistently fix a reliably repeatable error with both Java HotSpot and OpenJDK.