That’s some good info… but if the user running OF couldn’t read whatever file it needs, root should have been able to, right? The second thread dump was obtained while running OF as root. Maybe there’s not enough entropy on the box?
I’d love to google for more info, but with nothing in the logs, I didn’t know what to google for. Any suggestions?
I found the following link that provides a solution that, at least, worked for some people. http://forum.java.sun.com/thread.jspa?threadID=230198&messageID=820456
Let me know if that helped. BTW, I see that Jetty devs have already filed an issue for this problem. http://jira.codehaus.org/browse/JETTY-331.
Regards,
– Gato
Thanks for the pointers. I did some reading and fiddling, but I’m still not able to get Openfire running on this machine.
Here are some of the things I’ve tried:
Upgrading to java version 1.6.0_02
Setting INSTALL4J_ADD_VM_PARAMS="-Djava.security.egd=file:/dev/urandom" in /opt/openfire/bin/openfire
After I did this and restarted Openfire, I waited for it to hang, then I used lsof and observed that java still opens /dev/random for reading twice and /dev/urandom for reading once. This is consistent with the server where Openfire is working, though.
Configuring org.mortbay.jetty.servlet.HashSessionIdManager to use java.util.Random instead of java.security.SecureRandom
I don’t think I ever really got this to work, unfortunately. The APIs have changed since JETTY-331 was created, and while I tried to adapt the example, I never got the admin console to come up properly. I was able to get it to bind to port 9090, but then I just got HTTP 500 errors.
Compiling/running a modified version of the “seed” test program. The test program does not hang; it prints a random number. I chose java.util.Random.nextLong() because it’s mentioned in the stack trace I posted earlier. Here’s the source:
import java.util.Random;
class seed {
public static void main(String args[]) {
try {
Random r = new Random();
long l = r.nextLong();
System.out.println(l);
} catch (Exception e) {
e.printStackTrace();
}
}
}
As both of the links you posted are quite old and issues are purportedly fixed in later java releases, I’m not sure what else to try.
Hey Jonathan,
Have you read and tried this section in the link that I gave you?
The problem seemed to be that the security provider used /dev/random as an entropy generator, and it somehow wasn’t working. By editing the $JAVA_HOME/jre/lib/security/java.security file and changing the property:
securerandom.source=file:/dev/random
to:
securerandom.source=file:/dev/urandom
the problem disappeared for me. So there seems to be some issue with the OS access to /dev/random. Hope this helps with your issue.
Regards,
– Gato
In the java.security file, securerandom.source was already set to file:/dev/urandom. Also, passing “-Djava.security.egd=file:/dev/urandom” to java (which I tried) is supposed to override that setting.
Hi,
for me this looks a lot like a problem with /dev/random or something like this, where ever “sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator .java:453)” tries to get the seed.
Which Linux distribution and kernel are you using? (I should write that your kernel and distribution is not compatible with Java based products instead of asking which one you are using (; )
LG
Edited: The forum did display only the thread dump and no further threads (probably a very small link to page 2), so forget about this post as it will likely not help you.
I’m also running Openfire on a linode.com virtual machine (Ubuntu 7.10). I had the same “setup appears right but no port listening ever occurs” symptoms. I quit working on the problem one night and found the admin console awake the next morning. An Openfire restart takes about 20 minutes to “start listening”. I looked into the /dev/urandom vs /dev/random setting, but like you I found that the security files were already set to urandom and explicitly setting the java.security.egd property to urandom made no difference…
When /dev/random is low on entropy and that holds up Openfire’s JETTY then one possible fix is:
mv /dev/random /dev/randomOftenDepleted
ln -s /dev/urandom /dev/random
With this fix my Openfire went from a 20 minute start to < 5 secs.