Hello! I’m using Openfire 3.7.1 on Debian 6 32-bit; configured with MySQL and had it running for quite some time.
About a week ago my vserver rebooted unexpectedly (still analyzing that) and everything but openfire went back up.
Since then I have not been able to start openfire again successfully. The configuration is unchanged and mysql is running and also being used successfully by other services.
When I try to start openfire it either doesn’t seem to do anything (no java process at all, but pidfile created), or the process is running (java with the expected options) and no ports are opened at all and sometimes some or all ports are being opened, looking like a successful start. However, you might be able to login to the admin webpage or not, connect successfully with a jabber client or not and it’s highly unstable mostly crashing after serving one connection.
To make matters worse, mostly there is nothing being logged at all!
The config looks ok, the database is okay too, I’ve reinstalled the package anyway without any change.
Has anyone encountered this or can give me a hint where to look?
I’m not 100% how the Debian init.d scripts are setup, but at least on RedHat the JVM writes stdout to openfire/logs/nohup.out - That should give you some indication of what is failing, even if it doesn’t get far enough to start using log4j to write to the regular log files.
First off, I have no idea why, but today I don’t have the Java deadlock anymore without me being aware why (the only notable thing I have changed is install sun-java6-fonts). Nonetheless, there are still issues.
When running ‘/usr/lib/jvm/java-6-sun/bin/java -server -DopenfireHome=/usr/share/openfire -Dopenfire.lib.dir=/usr/share/openfire/lib -classpath /usr/share/openfire/lib/startup.jar -jar /usr/share/openfire/lib/startup.jar -v’ now everyhing works - as root. When invoking the initscript, it does not. Manually switching to the openfire user and running it does not work either, as to be expected.
So I noticed several things being wrong regarding users and file permissions. The UID and GID were not unique - I fixed that and also the file permissions with the same commands from the post install script of the original package.
Nonetheless, I get no console output, error or logs when running in openfire user context.
I dabbled a bit, getting nowhere. I noticed that everything in my previous post didn’t seem true anymore, and was baffled and pondering why.
Then it hit me - I installed openjdk-6-jre, just to see if it made a difference. And it does! Somehow, that seems to resolve some requirements that aren’t covered by the dependencies!? And why did it work previously without a hitch?
I have no idea.
Anyway, after installing openjdk-6-jre (openfire is still using sun-java6-jre!) everything works yet again.
(I have tested this by uninstalling openjdk-6-jre and dependencies and then it didn’t work again)
I swear, everytime I think I’m on to something, test the theory and type it here, everything’s completely different upon completion of the post. Sigh.
So no, nothing.
All I have is rumors on OpenVZ VMs having issues with java, even though I had it running for quite some time…
Well, your java error is a totally different one. Besides, I didn’t receive any java error anymore.
Maybe my hoster was messing with the OpenVZ configuration.
Nevertheless, I never got it to work. I even reinstalled the debian package completely new, with default config, new database… no dice. Java errors are gone (without me really changing anything - hence I assume my hoster’s done something) but openfire still does not start stable. It just seems to stop working at some random point when starting up. Since it’s been a month now (since it went down, not since I posted) I opted to install ejabberd which works flawlessly.
Please don’t misinterpret this – I love openfire and I’ve been using it for around 2 years. Something must have happened to my OpenVZ Server VM to introduce major openfire issues. I am just circumventing this now by using ejabberd.