2651 2005-01-27 15:34 /dev/random vs. /dev/urandom 2006-09-20 23:03:25 1 1 1 Unclassified Java WS Security Authentication unspecified PC Linux RESOLVED FIXED P3 major --- 1 rynge@isi.edu ranantha@mcs.anl.gov chris@gridwisetech.com gawor@mcs.anl.gov gose@mcs.anl.gov meder@mcs.anl.gov slang@mcs.anl.gov rynge@isi.edu 2005-01-27 15:34:26 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. meder@mcs.anl.gov 2005-03-24 14:32:07 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 rynge@isi.edu 2005-03-24 15:16:01 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. meder@mcs.anl.gov 2005-03-24 15:33:51 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 meder@mcs.anl.gov 2005-04-05 08:03:58 Checked in a patch from the GridWise folks. chris@gridwisetech.com 2005-04-21 05:55:19 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. tfreeman@mcs.anl.gov 2006-09-20 23:03:25 See Bug 4721, this configuration requires a URL scheme ("file:" or "file://")