Bugzilla – Bug 2651
/dev/random vs. /dev/urandom
Last modified: 2006-09-20 23:03:25
You need to log in before you can comment on or make changes to this bug.
Several people have now noticed this: ----------------------------------------------------------- From: Scott Gose Subject: [Globus-discuss] container doesn't list services To: discuss@globus.org Date: Tue, 25 Jan 2005 20:12:56 -0600 If you start a globus container and it doesn't list the services, but apparently hangs: $ $GLOBUS_LOCATION/bin/globus-start-container // it apparently hangs here Then it's possible you need to set this environment variable: export GLOBUS_OPTIONS=-Djava.security.egd=file:/dev/urandom Jarek pointed me to the fix which works on a host where /dev/random has run out of entropy and we have to point things to /dev/urandom. You can test this with: $ more /dev/random // If it doesn't return stuff, you need the above fix $ more /dev/urandom // Should return stuff I experienced this on a Fedora Core 1 machine that has a pretty high uptime (267 days). ----------------------------------------------------------- The problem is that there is no warnings about the container stopping (or not starting at all). This might affect the performance campaigns currently going on. There should be warnings in the logfile about this. Also, it would be nice if there was an option allowing the container to fall back on /dev/urandom in case of /dev/random not being able to deliver the entropy. It really should be an option, as some people do not want that to happen.
Just to be a bit more specific, as far as I know this only happens when running the container with java 1.3.1. So what should be done (if anything) is probably to add some code to our startup that checks if the java version is 1.3 and if /dev/urandom exists then it should add is as the entropy source. /Sam
Hmm, so what is the default behavior with 1.4.2? I have a container on a fairly busy host, and used to have problems with it hanging until we added -Djava.security.egd=file:/dev/urandom. The hanging stopped around the time we added the option, but maybe it was a coincidence.
Looks like I got this backwards. 1.4 seems to have /dev/random as the default. Maybe 1.3 does the correct thing (or I was just confused). /Sam
Checked in a patch from the GridWise folks.
Let me write a few words about solution we chose and implemented. When the Globus container is about to be start shell script $GLOBUS_LOCATION/bin/globus-start-container checks if there is /dev/urandom device available in the system. If yes, it forces org.globus.bootstrap.Bootstrap Java class to use this entropy generator. This is done with java.security.egd Java property. If no, it forces Bootstrap class to use /dev/random device. After having started the container, org.globus.wsrf.container.ServiceContainer Java class prints logging (log4j) information about the entropy generator it uses.
See Bug 4721, this configuration requires a URL scheme ("file:" or "file://")
