On Sep 30, 2009, at 8:33 AM, Steve Loughran wrote:
Brian Bockelman wrote:On Sep 30, 2009, at 4:24 AM, Steve Loughran wrote:Todd Lipcon wrote:Yep, this is a common problem. The fix that Brian outlined helps a lot, but if you are *really* strapped for random bits, you'll still block. This is because even if you've set the random source, it still uses the real/dev/random to grab a seed for the prng, at least on my system.Is there anyway to test/timeout for this on startup and respond?The amount of available entropy is recorded in this file: /proc/sys/kernel/random/entropy_availThat's the number of bytes available in the entropy pool. From what I can see, 200 is considered a low number. It appears that the issue is deep within Java's security stack. I'm not sure how easy it is to turn it into non-blocking-I/O. If you've got a nice fat paid contract with Sun, you might have a chance...I could certainly do something to get that value and worry if it is low. But where to add more.
I would say it is outside our scope to increase entropy on entropy- poor systems. However, *if* we are on a linux system and *if* we can read the available entropy and *if* it is low, I would say that throwing a warning on datanode startup might be a good idea.
Brian, you are the physicist, do you have any strongly random numbers for us to use?
42? Brian
smime.p7s
Description: S/MIME cryptographic signature
