On Tue, 7 Sep 2004, Igor Zlatkovic wrote: | I have found the solution and will share it here incase someone | encounters a similar problem in the future. | | The solution is: | | # cd /dev | # mv random random-old | # ln -s urandom random | | however bizarre that may sound. It seems that the recent Linux kernel | update wasn't up to Tomcat's liking. For whatever the reason, Tomcat's | initialising of the TLS connector blocks in a read from /dev/random, | always. Ensuring that it reads from /dev/urandom instead makes it happy | again.
( Nothing very valuable in the following, really, I've just had the exact same situation with a SecureRandom in my application that I seeded with /dev/random.. ) /dev/random has an "entropy pool" that may get depleted, in which case it'll block till it has gotten more bits of entropy. I've experienced that on a server standing in a corner, w/o keyboard or other "direct human input", this might take forever (for example, it doesn't use ethernet traffic, as this can become non-random at times..) I guess the TLS Connector (where is that?) uses /dev/random for its initialization for its instance of a java.security.SecureRandom. However, I believe that on new VMs the default initialization (default == no seeding on creation) of SecureRandom is pretty good, utilizing the OS's native random mechanisms. I think that 1.3 has been like this on windows for some time, while maybe 1.4 fixed this for Linux? However, if the linux-default init uses /dev/random (instead of urandom), then this might be the problem? The TLS Connector might be changed to use a configurable source for randomness for seeding, e.g. either a file, or default init. Endre --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
