Openfire starts, but doesn't listen on any ports

jon@thebox:/opt/openfire/bin$ ps aux | grep ^openfire

openfire 20231 17.3 10.8 207840 27448 pts/0 Sl 11:07 0:04 /usr/bin/java -server -Dinstall4j.jvmDir=/usr -Dexe4j.moduleName=/opt/openfire/bin/openfire -classpath /opt/openfire/.install4j/i4jruntime.jar:/opt/openfire/lib/activation.jar:/opt/o penfire/lib/bouncycastle.jar:/opt/openfire/lib/commons-el.jar:/opt/openfire/lib/ hsqldb.jar:/opt/openfire/lib/jasper-compiler.jar:/opt/openfire/lib/jasper-runtim e.jar:/opt/openfire/lib/jdic.jar:/opt/openfire/lib/jtds.jar:/opt/openfire/lib/ma il.jar:/opt/openfire/lib/mysql.jar:/opt/openfire/lib/openfire.jar:/opt/openfire/ lib/postgres.jar:/opt/openfire/lib/servlet.jar:/opt/openfire/lib/startup.jar com.install4j.runtime.Launcher start org.jivesoftware.openfire.starter.ServerStarter false false /opt/openfire/bin/…/logs/stderror.log /opt/openfire/bin/…/logs/stdoutt.log true true false true true 0 0 20 20 Arial 0,0,0 8 500 version 3.3.3 20 40 Arial 0,0,0 8 500 -1 -DopenfireHome=/opt/openfire -Dopenfire.lib.dir=/opt/openfire/lib

Hrm… do you happen to run a wrong version/distribution of Openfire? cause, you’re not supposed to see install4j when you run on Linux.

I got it from here: http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_3_3_3.t ar.gz

(http://www.igniterealtime.org/ => Downloads => Openfire 3.3.3 => Linux => openfire_3_3_3.tar.gz)

On the other machine where Openfire is running fine, ps gives:

jon 22040 0.0 38.5 357476 100528 ? Sl Sep30 0:11 /usr/bin/java -server -Dinstall4j.jvmDir=/usr -Dexe4j.moduleName=/opt/openfire/bin/openfire -classpath /opt/openfire/.install4j/i4jruntime.jar:/opt/openfire/lib/activation.jar:/opt/o penfire/lib/bouncycastle.jar:/opt/openfire/lib/jdic.jar:/opt/openfire/lib/mail.j ar:/opt/openfire/lib/startup.jar com.install4j.runtime.Launcher start org.jivesoftware.openfire.starter.ServerStarter false false /opt/openfire/bin/…/logs/stderror.log /opt/openfire/bin/…/logs/stdoutt.log true true false true true 0 0 20 20 Arial 0,0,0 8 500 version 3.3.3 20 40 Arial 0,0,0 8 500 -1 -DopenfireHome=/opt/openfire -Dopenfire.lib.dir=/opt/openfire/lib

So I didn’t think install4j was out of the ordinary.

I just saw this post in the More Like This section on the right… in f8arr’s case it seems like he just didn’t wait long enough for Openfire to start up. I waited the better part of an hour, so I hope that’s not it… although the whole time (while Openfire was running but not yet (?) listening on any ports) it seemed to be using a good deal of CPU.

Could you create a thread dump so we can see what the server is doing? Execute kill -3 to get a thread dump. The dump info will be stored in the stdout.

– Gato

Sorry Jonathan, can’t help you much. Frankly, I’ve never known of the need to have install4j as a launcher for Openfire in Linux. Gato should be able to help.

I didn’t see an attachment feature, so here it is:

2007-10-01 13:02:38

Full thread dump Java HotSpot™ Server VM (1.6.0-b105 mixed mode):

“btpool0-0” prio=10 tid=0x084ef000 nid=0x7cd3 in Object.wait() http://0x4baee000…0x4baeeeb0

java.lang.Thread.State: TIMED_WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

  • waiting on <0x43d24bc8> (a org.mortbay.thread.BoundedThreadPool$PoolThread)
    at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:469)
  • locked <0x43d24bc8> (a org.mortbay.thread.BoundedThreadPool$PoolThread)

“DestroyJavaVM” prio=10 tid=0x08059400 nid=0x7cc8 waiting on condition http://0x00000000…0x40200108

java.lang.Thread.State: RUNNABLE

“pool-1-thread-1” prio=10 tid=0x08300000 nid=0x7cd2 runnable http://0x4ba94000…0x4ba94e30

java.lang.Thread.State: RUNNABLE

at java.io.FileInputStream.readBytes(Native Method)

at java.io.FileInputStream.read(FileInputStream.java:199)

at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)

at java.io.BufferedInputStream.read(BufferedInputStream.java:317)

  • locked <0x43404488> (a java.io.BufferedInputStream)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
  • locked <0x433f6f38> (a java.io.BufferedInputStream)
    at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator. java:453)
    at sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)
    at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)
    at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)
    at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:171)
  • locked <0x433f6bb0> (a sun.security.provider.SecureRandom)
    at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
  • locked <0x433f6e30> (a java.security.SecureRandom)

at java.security.SecureRandom.next(SecureRandom.java:455)

at java.util.Random.nextLong(Random.java:284)

at org.mortbay.jetty.servlet.HashSessionIdManager.doStart(HashSessionIdManager.jav a:105)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.servlet.AbstractSessionManager.doStart(AbstractSessionManager .java:166)

at org.mortbay.jetty.servlet.HashSessionManager.doStart(HashSessionManager.java:53 )

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.servlet.SessionHandler.doStart(SessionHandler.java:115)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)

at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:500)

at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)

at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191)

at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)

at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)

at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollec tion.java:120)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)

at org.mortbay.jetty.Server.doStart(Server.java:210)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlug in.java:140)

at org.jivesoftware.openfire.container.AdminConsolePlugin.initializePlugin(AdminCo nsolePlugin.java:175)

at org.jivesoftware.openfire.container.PluginManager.loadPlugin(PluginManager.java :404)

at org.jivesoftware.openfire.container.PluginManager.access$200(PluginManager.java :46)

at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:916)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101 (ScheduledThreadPoolExecutor.java:98)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodi c(ScheduledThreadPoolExecutor.java:181)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:205)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

at java.lang.Thread.run(Thread.java:619)

“Thread-0” daemon prio=10 tid=0x08119400 nid=0x7cd1 waiting on condition http://0x4b932000…0x4b932db0

java.lang.Thread.State: TIMED_WAITING (sleeping)

at java.lang.Thread.sleep(Native Method)

at com.install4j.runtime.Launcher$StopWatcherThread.run(Unknown Source)

“Low Memory Detector” daemon prio=10 tid=0x08102400 nid=0x7ccf runnable http://0x00000000…0x00000000

java.lang.Thread.State: RUNNABLE

“CompilerThread1” daemon prio=10 tid=0x08100c00 nid=0x7cce waiting on condition http://0x00000000…0x4b7fd5c8

java.lang.Thread.State: RUNNABLE

“CompilerThread0” daemon prio=10 tid=0x080ff800 nid=0x7ccd waiting on condition http://0x00000000…0x4b77c548

java.lang.Thread.State: RUNNABLE

“Signal Dispatcher” daemon prio=10 tid=0x080fe400 nid=0x7ccc runnable http://0x00000000…0x00000000

java.lang.Thread.State: RUNNABLE

“Finalizer” daemon prio=10 tid=0x080ebc00 nid=0x7ccb in Object.wait() http://0x4b6aa000…0x4b6aaeb0

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

  • waiting on <0x43aa5b50> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
  • locked <0x43aa5b50> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)

at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

“Reference Handler” daemon prio=10 tid=0x080eb000 nid=0x7cca in Object.wait() http://0x4b659000…0x4b659e30

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

  • waiting on <0x43aa5be0> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:485)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
  • locked <0x43aa5be0> (a java.lang.ref.Reference$Lock)

“VM Thread” prio=10 tid=0x080e8800 nid=0x7cc9 runnable

“VM Periodic Task Thread” prio=10 tid=0x08103c00 nid=0x7cd0 waiting on condition

JNI global references: 834

Heap

def new generation total 960K, used 710K [0x43360000, 0x43460000, 0x43a70000)

eden space 896K, 79% used [0x43360000, 0x434118d0, 0x43440000)

from space 64K, 0% used [0x43450000, 0x43450000, 0x43460000)

to space 64K, 0% used [0x43440000, 0x43440000, 0x43450000)

tenured generation total 5508K, used 3304K [0x43a70000, 0x43fd1000, 0x47360000)

the space 5508K, 59% used [0x43a70000, 0x43daa020, 0x43daa200, 0x43fd1000)

compacting perm gen total 16384K, used 7458K [0x47360000, 0x48360000, 0x4b360000)

the space 16384K, 45% used [0x47360000, 0x47aa8918, 0x47aa8a00, 0x48360000)

No shared spaces configured.

Ok, that thread dumps shows that there are no listener threads running in the JVM. Many things are missing there. I’m not sure how you installed and set up the server but could you edit the file config/openfire.xml and the set setup property to false? Restart the server and see if you can access the admin console?

Regards,

– Gato

I added in the config file and restarted the server - no change in behavior. It doesn’t listen on any ports, so I can’t connect to the admin console.

As for how I installed Openfire - I just followed the installation document. I downloaded the tarball, unpacked it, and moved it over to /opt. I took the additional steps of adding an “openfire” system user and then (as root) chown -R openfire:openfire /opt/openfire. I start the server as the openfire user (not as root).

And what happens if you run it as root? Could you post another thread dump with the setup in false?

Thanks,

– Gato

Ran as root, still won’t listen on any ports. Here’s the trace when openfire is running as root.

2007-10-01 17:04:47

Full thread dump Java HotSpot™ Server VM (1.6.0-b105 mixed mode):

“btpool0-0” prio=10 tid=0x0851b000 nid=0x3a0a in Object.wait() http://0x4baee000…0x4baeef30

java.lang.Thread.State: TIMED_WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

  • waiting on <0x43dce6c0> (a org.mortbay.thread.BoundedThreadPool$PoolThread)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:469)

  • locked <0x43dce6c0> (a org.mortbay.thread.BoundedThreadPool$PoolThread)

“DestroyJavaVM” prio=10 tid=0x08059400 nid=0x39ff waiting on condition http://0x00000000…0x40200080

java.lang.Thread.State: RUNNABLE

“pool-1-thread-1” prio=10 tid=0x084b2400 nid=0x3a09 runnable http://0x4ba94000…0x4ba94db0

java.lang.Thread.State: RUNNABLE

at java.io.FileInputStream.readBytes(Native Method)

at java.io.FileInputStream.read(FileInputStream.java:199)

at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)

at java.io.BufferedInputStream.read(BufferedInputStream.java:317)

  • locked <0x434106f0> (a java.io.BufferedInputStream)

at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)

at java.io.BufferedInputStream.read(BufferedInputStream.java:317)

  • locked <0x43410330> (a java.io.BufferedInputStream)

at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator. java:453)

at sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)

at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)

at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)

at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:171)

  • locked <0x4340ffa8> (a sun.security.provider.SecureRandom)

at java.security.SecureRandom.nextBytes(SecureRandom.java:433)

  • locked <0x43410228> (a java.security.SecureRandom)

at java.security.SecureRandom.next(SecureRandom.java:455)

at java.util.Random.nextLong(Random.java:284)

at org.mortbay.jetty.servlet.HashSessionIdManager.doStart(HashSessionIdManager.jav a:105)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.servlet.AbstractSessionManager.doStart(AbstractSessionManager .java:166)

at org.mortbay.jetty.servlet.HashSessionManager.doStart(HashSessionManager.java:53 )

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.servlet.SessionHandler.doStart(SessionHandler.java:115)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)

at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:500)

at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)

at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191)

at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)

at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)

at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollec tion.java:120)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)

at org.mortbay.jetty.Server.doStart(Server.java:210)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlug in.java:140)

at org.jivesoftware.openfire.container.AdminConsolePlugin.initializePlugin(AdminCo nsolePlugin.java:175)

at org.jivesoftware.openfire.container.PluginManager.loadPlugin(PluginManager.java :404)

at org.jivesoftware.openfire.container.PluginManager.access$200(PluginManager.java :46)

at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:916)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101 (ScheduledThreadPoolExecutor.java:98)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodi c(ScheduledThreadPoolExecutor.java:181)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:205)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

at java.lang.Thread.run(Thread.java:619)

“Thread-0” daemon prio=10 tid=0x08119400 nid=0x3a08 waiting on condition http://0x4b932000…0x4b932e30

java.lang.Thread.State: TIMED_WAITING (sleeping)

at java.lang.Thread.sleep(Native Method)

at com.install4j.runtime.Launcher$StopWatcherThread.run(Unknown Source)

“Low Memory Detector” daemon prio=10 tid=0x08102400 nid=0x3a06 runnable http://0x00000000…0x00000000

java.lang.Thread.State: RUNNABLE

“CompilerThread1” daemon prio=10 tid=0x08100c00 nid=0x3a05 waiting on condition http://0x00000000…0x4b7fd548

java.lang.Thread.State: RUNNABLE

“CompilerThread0” daemon prio=10 tid=0x080ff800 nid=0x3a04 waiting on condition http://0x00000000…0x4b77c5c8

java.lang.Thread.State: RUNNABLE

“Signal Dispatcher” daemon prio=10 tid=0x080fe400 nid=0x3a03 runnable http://0x00000000…0x00000000

java.lang.Thread.State: RUNNABLE

“Finalizer” daemon prio=10 tid=0x080ebc00 nid=0x3a02 in Object.wait() http://0x4b6aa000…0x4b6aaf30

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

  • waiting on <0x43aa8100> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)

  • locked <0x43aa8100> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)

at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

“Reference Handler” daemon prio=10 tid=0x080eb000 nid=0x3a01 in Object.wait() http://0x4b659000…0x4b659db0

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

  • waiting on <0x43aa8190> (a java.lang.ref.Reference$Lock)

at java.lang.Object.wait(Object.java:485)

at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)

  • locked <0x43aa8190> (a java.lang.ref.Reference$Lock)

“VM Thread” prio=10 tid=0x080e8800 nid=0x3a00 runnable

“VM Periodic Task Thread” prio=10 tid=0x08103c00 nid=0x3a07 waiting on condition

JNI global references: 820

Heap

def new generation total 960K, used 790K [0x43360000, 0x43460000, 0x43a70000)

eden space 896K, 88% used [0x43360000, 0x43425540, 0x43440000)

from space 64K, 2% used [0x43450000, 0x434506a8, 0x43460000)

to space 64K, 0% used [0x43440000, 0x43440000, 0x43450000)

tenured generation total 4096K, used 4008K [0x43a70000, 0x43e70000, 0x47360000)

the space 4096K, 97% used [0x43a70000, 0x43e5a180, 0x43e5a200, 0x43e70000)

compacting perm gen total 16384K, used 7458K [0x47360000, 0x48360000, 0x4b360000)

the space 16384K, 45% used [0x47360000, 0x47aa8918, 0x47aa8a00, 0x48360000)

No shared spaces configured.

Ok, I missed this one in your previous post. In both thread dumps the server halted while starting up the admin console. More precisely, the server is trying to start up Jetty (the embedded web server) and while trying to generate a random number the server waits and waits and waits. Based on the stack trace it seems like Java is trying to read a file (?) to be able to generate a random number. For some reason that operation never ends thus the entire server is not being able to fully start up. My only guess is that the user running OF does not have enough permissions to read some file. Which file is that I don’t know. Could you check that the folder where Java is installed can be fully read by the user running the server? You can also google this problem and see what we find.

– Gato

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.