I’ve got openfire 3.6.4 installed on a distro of Raspberrian and I’ve been seeing an issue where spontaneously after a system reboot openfire acts as though it has no configuration anymore and goes endlessly through a setup loop even if I restart both the service or the server it’s running on. Anyone got any ideas to help figure out what is going on?
Thanks!
one possibility is that the openfire.xml file in the config folder does not have write permissions
I will look into that, however what is the file path for locating the config.xml file (assuming default install locations). Also why would the permissions on that file have changed when it was functioning originally through multiple restarts of the service prior to this issue?
Thanks!
Just a possibility. Not sure it is the case. I have experienced it before. No logical explanation for why file lost the write permission
location is OPENFIRE_HOME\conf
Ok, got into the system and the openfire.xml file was blank. I’ve tried recreating it and extending it’s permissions to 777 via chmod but so far no luck, anywhere else we can look to understand this?
Thanks!
-Simon
I just had this happen with a test install on a Mac OSX system. The openfire.xml file was owned by root, where the other files in the conf directory were owned by openfire. I chowned the file to make it owned by openfire, restarted the service, and all was well.
Tried that, didn’t work unfortunately, but I’ll give it another shot just in case.
Simon, another thing I did (forgot to mention) is I killed the service, moved the openfile.xml to another name, tried to start the service (that failed), then moved the file back in place (chowned as the openfire user), then started the server (sucessfully this time). I don’t know why that helped, but that was the magic incantation. I’m new at this openfire business though, so my advice and a $1.75 will get you a double-double at Tim Hortons.
Paste your log file. It sure beats this “guess where is the bug” game.
Where can I find the log?
OPENFIREHOME/logs
on mine its /usr/local/openfire/logs.
Here’s the logs… I think…
Let me know if you can’t get at it.
-Simon
So any thoughts?
Too many errors. It would seemed there are problems from your setup. The domain name does not have a DNS entry and the database connection you specified is failing.
That still does not explain why your openfire.xml file is empty, but fixing these issues might get you a steop closer to the root problem
-dele
So I’m doing an embedded database and all the rest of the setup options by default. As for the Domain name, it’s the box itself (net.local) which also hosts the dns service it’s using. Again, this was all working fine until suddenly after a reboot it stopped working. If you guys don’t think there’s any other option I’ll blow it all away for now to the working image I have but I’m hoping to find a solution for when it inevitably goes and dies again.
it does look like you are dealing with a Linux or even hardware issue and not an Opennfire issue and that is outside my area of expertise. I think blowing it away migh be your best shot right now.
IF a reboot killed it then you might have gotten a service up and running in real time but neglected to save your changes to the appropriate config files so that whatever that service was didn’t start back up properly. Maybe DNS? Or perhaps did you inadvertently disable a service start script before the reboot?
Alas too late to look now it’s being rewriten as we speak however the configuration was running from an SD card in an Rasberry Pi in a headless configuration so the common shutdown method for the box is to literally yank the power (I know, but I’m not building this thing for techy folks). On the otherhand it works pretty well when it’s all working most of the time.