[SNMP4J] SecureRandom freezes JVM

Sasa Markovic saxon at eunet.yu
Tue Jan 25 14:44:03 CET 2005


Philip Yarra wrote:

> I think this will be because by default, Java will get entropy data from 
> /dev/random, which blocks until data is available. We had a similar issue on 
> an extremely busy system, where the pool would be emptied faster than it 
> could be filled... after a while, Java simply stopped. In your case, maybe 
> there is some problem with /dev/random?
> 
> In any case, the simple workaround is to use /dev/urandom, which is 
> non-blocking. Hopefully /dev/urandom is okay too. See 
> http://forum.java.sun.com/thread.jspa?threadID=230198&messageID=820456 for 
> more detail. Note that other utilities (ssl, ssh, etc) will also rely on 
> /dev/random, so the best course might be to make sure that /dev/random works 
> properly.

I have replaced /dev/random with /dev/urandom (it's possilbe to do this 
from the java command line) but /dev/urandom does not work either. JVM 
freezes and 'fuser' finds that both /dev/random and /dev/urandom are 
'open'. I know that 'urandom' should not block, but it happens.

I think this is some Gentoo-related problem. Here is an interesting 
thread which helped me a lot to understand the problem in detail (it's 
all about apache and /dev/random, but the story is still relevant):

http://www.linode.com/forums/viewtopic.php?t=650

According to this, /dev/random should be populated by random bytes 
generated by some low-level events, like disk I/O or NIC utilization. 
It's fun to know that the number of bytes currently available in the 
/dev/random entropy generator can be found with:

cat /proc/sys/kernel/random/entropy_avail

On our Gentoo server, it returns '2', probably not enough for a single 
successful seed retrieval. A book says that this value should rapidly 
increase over time (I/O intensive operations might help, like "du 
/usr"), but Gentoo keeps returnig '2' forever. I have replaced the 
kernel with a newer one, but all I got so far was '0' instead of '2' :)

A tough nut to crack.

Greetings,
Sasa

> 
> Regards, Philip.
> 
> On Tue, 25 Jan 2005 01:05 am, Sasa Markovic wrote:
> 
>>Hi.
>>
>>Did anyone get into problems with the org.snmp4j.security.Salt class?
>>
>>Basically, I had no problems with SNMP4J on any platform until I tried
>>to port my application to a Gentoo Linux box (Linux collector
>>2.6.9-gentoo-r13 #1 SMP Sat Jan 8 21:54:05 CET 2005 i686 Intel(R)
>>Xeon(TM) CPU 2.40GHz GenuineIntel GNU/Linux). Apparently, my JVM freezes
>>somewhere in the Snmp() constructor. All JVM versions are affected (1.4,
>>1.5).
>>
>>I had a hard time trying to locate the "freezing point" in the SNMP4J
>>source code. Well, I am quite sure that it happens on the next two lines
>>of the Salt class:
>>
>>...
>>SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
>>sr.nextBytes(rnd);   <------- THIS LINE FREEZES JVM
>>...
>>
>>Ok, it's easy to skip these two lines and force code to work. I am just
>>curious why this happens. Any ideas?
>>
>>Greetings,
>>Sasa Markovic.
>>
>>_______________________________________________
>>SNMP4J mailing list
>>SNMP4J at agentpp.org
>>http://p15141779.pureserver.info/mailman/listinfo/snmp4j




More information about the SNMP4J mailing list