OpenFire 5.0.1 - No error logs, no env. variable, etc

Openfire Openfire Support
1

Hello. Good day to you.

I have installed OpenFire 5.0.1 on my Ubuntu 24.02 LTS, along with JDK 22 and MariaDB.
However, upon prompting ‘systemctl status openfire’, the activity status is set to “Active (stopped)”.
I tried re-executing OpenFire service by running ‘systemctl start openfire’, still no luck.

Then, I decided to look for OpenFire log files, but nothing was written to disk (I searched my whole OS using ‘find’ and ‘grep’ commands to look for OpenFire log files).

However, it seems that even $OPENFIRE_HOME environment variable is not set, as echoing it would output a blank line.

Could you possibly know the root of these causes?

Thanks a bunch in advance.

2

Hi Marco, sorry to hear that you’re running into issues.

Is there anything being written in syslog when you attempt to start Openfire?

1 Like
3

Thanks a million for your fast response.

There are some messages related to OpenFire, they are the same as running ‘systemctl status openfire’.

Here is the full response text:
openfire.service - LSB: Start/stop openfire jabber server
Loaded: loaded (/etc/init.d/openfire; generated)
Active: active (exited) since Wed 2025-07-09 08:12:19 UTC; 46min ago
Docs: man:systemd-sysv-generator(8)
Process: 804 ExecStart=/etc/init.d/openfire start (code=exited, status=0/SUCCESS)
CPU: 27ms

Jul 09 08:12:18 ubuntu systemd[1]: Starting LSB: Start/stop openfire jabber server…
Jul 09 08:12:19 ubuntu openfire[804]: best java alternative in:
Jul 09 08:12:19 ubuntu openfire[804]: Starting openfire: openfire.
Jul 09 08:12:19 ubuntu systemd[1]: Started LSB: Start/stop openfire jabber server.

4

Curious. Does something get logged if you invoke the startup command directly from the shell?

/etc/init.d/openfire start

You wrote earlier that you tried finding the Openfire log files. Didn’t you find them, or wasn’t there anything in them?

I expect them to live in either /var/log/openfire/ or /opt/openfire/logs (but that’s not certain, as I’m not sure what each installer uses).

1 Like
5

Thanks once again.

  1. I tried running directly from the shell using sudo and the path you kindly mentioned. Nothing is printed in response:
    openfire1
    And no, it doesn’t log anything, even in systemlog (repeats the response from systemctl status openfire.)

  2. I’m certain I don’t find them. Tried both paths but still no luck:
    openfire2
    openfire3

Also, it is worth noting that I installed v4.6.2 of OpenFire, and none of these issues happened. Not sure if it is related to OpenFire itself, or me taking a wrong step or two.

And this is the response from systemctl I wrote earlier:

openfire4
openfire4690×175 12.4 KB

(even when running it directly from shell or using systemctl start, the active timestamp doesn’t change at all.)

6

:thinking: Is it finding an ‘older’ service maybe, which confuses things? Can you try following the steps in Openfire 5.0.0: A New Era of Real-Time Communication - #18 by stokito to see if that makes a difference?

1 Like
7

TL;DR
This is a bug: the OpenFire service wasn’t able to detect Java location.
Workaround: You need to manually specify JAVA_HOME environment variable.
First execute update-alternatives --display java and copy the path to a JVM folder without the /bin/java.
Then edit /etc/environment and add the line:

JAVA_HOME="/usr/lib/jvm/java-17-openjdk-amd64"

You can use sudo -e /etc/environment to edit the file.
You’ll need to reboot after this so that the env var will be picked.
Alternatively you can change the JAVA_HOME in the /etc/default/openfire. Then you may avoid reboot.

You can restart the OpenFire with the /etc/init.d./openfire restart
With the /etc/init.d./openfire status you can check if it running.

Long description
I created the bug in Jira and made a PR with a fix
https://igniterealtime.atlassian.net/jira/software/c/projects/OF/issues/OF-3106

The old way of running the OF was to to call /etc/init.d/openfire script which uses old System V style. You can also call it with a command service openfire start.
The Debian migrated from the SysV to SystemD long time ago and the SystemD can run the old SysV scripts. But the preferred way for the SystemD is to use own daemon/service configuration in the INI-like file called unit. So in the OF 5.0.0 was added such a unit file in the /usr/lib/systemd/system/openfire.service. But the old /etc/init.d/openfire is installed too for those who may run it manually. The systemd should ignore the old /etc/init.d./openfire and use the unit file.

Note that there is an issue now that after installing OF debian package the openfire service is not registered so we need to run manually commands to enable it:

sudo systemctl daemon-reload
sudo systemctl enable openfire
sudo systemctl restart openfire

In the next releases the Debian package will do this itself in the post installation script.
Meanwhile you may need to run it manually. After this your SystemD shoud switch to use the unit file instead of SysV script, at least when making a fresh install. But maybe there is some problems during upgrade: maybe the SystemD will prefer the old SysV script instead. I checked this scenario but maybe missed something. Anyway normally you shouldn’t see the old SysV script.

So in your case the systemctl status openfireshows

/etc/init.d/openfire start (code=exited, status=0

This means that the systemd started the old SysV script /etc/init.d/openfire but it stopped with exit code 0 i.e. it was shut down without any problems. This is not true, in fact the script had an error but it wasn’t processed correctly.
All the printed messages to stdout and stderr the SystemD redirects to the own logging journal that you can read with journalctl -u openfire -f command. The last strings from the log you see in the systemctl status openfire: and you may the best java alternative in: i.e. it wasn’t able to detect the JVM folder from the update-alternatives command output.
Other details is described in the bug report and PR.

P.S. Thank you for mentioning me for the SystemD migration issues.

2 Likes
8

Hello again and sorry for my delayed response.

@stokito : In fact, it is correct that the issue was related to Java installation. Before you kindly responding to this thread, I did the following and it seemed to do the trick:

1- Instead of logging in as user and sudo su to root, I logged in as root itself.
2- Then, I uninstalled both OpenFire 5.0.1 installation and the version of Java installed at that time (22).
3- Afterwards, I ran dkpg -i OpenFire5.0.1.deb to install it again.
4- To my surprise, it returned a dependency error regarding package installation that it requires Java 11 (and probably 17) installation (it also helped me which commands to execute).
This didn’t happen if I logged in as ‘user’ and 'sudo’ing it.
5- After running the provided command, and then retrying installation, it worked like a charm and no issues arose.
I simply ran ‘systemctl restart openfire’ and everything started to work as it should.

Thank you @stokito and @guus for your co-operation on this matter.

9

The Java 22 is also supported. Did you installed it manually without apt/dpkg?

10

I installed it using apt install --default-jre and apt install --default-jdk, however these installed Java 11 on my Ubuntue. Then, I read the documentation that stated new OpenFires require at least Java 17, then thought about installing newer version of Java. I installed Java 22 by using apt install -openjdk-22-jre-headless, however, I still got dependency errors. Then, I used the instructions given by dpkg dependency errors on OpenFire package, then it worked.

1 Like
11

The package openjdk-22-jre-headless provides virtual package java-runtime that is used as a dependency in the openfire.deb. So it should work. Anyway I’m glad that you solved the issue. Please report any problems.

1 Like
12

Thank you.
Of course.