On 15.07.2011 04:19, Kevan Miller wrote:
> From time to time I encounter a problem starting a Geronimo server on a Linux 
> system (I've always seen it on Ubuntu -- but the problem could exist on other 
> distributions). The server start seems to hang. However, if you're patient, 
> which I rarely am, the server will eventually start. If you're inquisitive, 
> and dump the stack traces of the java process, you'll see something like:
> 
> "main" prio=10 tid=0x0000000040c0d800 nid=0xa79 runnable [0x00007f57a04fb000]
>    java.lang.Thread.State: RUNNABLE
>       at java.io.FileInputStream.readBytes(Native Method)
>       at java.io.FileInputStream.read(FileInputStream.java:220)
>       at 
> sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:185)
>       at 
> sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(NativePRNG.java:202)
>       - locked <0x00000000daad63e0> (a java.lang.Object)
>       at 
> sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:108)
>       at 
> sun.security.provider.NativePRNG.engineGenerateSeed(NativePRNG.java:102)
>       at java.security.SecureRandom.generateSeed(SecureRandom.java:495)
>       at 
> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.getSalt(PKCS12KeyStore.java:477)
>       at 
> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.calculateMac(PKCS12KeyStore.java:834)
>       at 
> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineStore(PKCS12KeyStore.java:788)
>       - locked <0x00000000d3b5a768> (a 
> com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore)
>       at java.security.KeyStore.store(KeyStore.java:1117)
> ...
> 
> This problem isn't Geronimo specific. But since I see it from time to time, 
> thought it would be worth passing along to the community...
> 
> The Sun/Oracle-based JVM is attempting to generate a pseudo-random number to 
> be used as a seed for an SSL server socket. To generate the pseudo-random 
> number, the JVM is reading from the /dev/random device to obtain some random 
> information for the seed. The problem is that reads from the /dev/random 
> device will block if the system does not have a good source of random events. 
> So, the Geronimo server startup is blocked waiting for enough random 
> information to be returned from /dev/random. This article may be help 
> understand the basic issue -- http://en.wikipedia.org/wiki//dev/random#Linux
> 
>  I'm no security expert. And I don't know the potential implications, but the 
> simplest way that I've found to avoid the problem is to use the /dev/urandom 
> device, instead of /dev/random. Do this by specifying the following java 
> property '-Djava.security.egd=file:/dev/./urandom'. So, the following should 
> work well:
> 
> $ GERONIMO_OPTS="-Djava.security.egd=file:/dev/./urandom" ./geronimo run 
> --long
> 
> Note to self -- would be nice to record this on our Wiki somewhere. Anyway, 
> hope this is useful...

And note that due to a bug in the JDK you really need to use

/dev/./urandom

or

/dev//urandom

and not

/dev/urandom.

Oracle themselves already internally use "dev/urandom, but later they
switch from /dev/urandom to /dev/random if the setting is trsingwise
identical to /dev/random. That's why you need to use some different
string that's equivalent to /dev/urandom after path normalization.

We had the same problem for Tomcat, mostly when starting two instances
in parallel.

Regards,

Rainer

Reply via email to