After updating to OpenNMS 24, when trying to start it runs for about a minute and stops

I am following the below guide:

and everything checks out fine. When I run systemctl start opennms it seems to start fine, and I can monitor the status for about a minute before it stops.

Initial check of logs seems to point towards an issue with the Jetty server, and presumably an issue with Java, though I don’t have enough experience yet with the backend of Linux, or OpenNMS and its interactions with Java to understand the issue or how to solve it.

Any help would be greatly appreciated, this is our corporate monitoring system for our divisions and we would really like to update it.

Can you check the manager.log and jetty’s logfile? What is your operating system, your Java environment? From which version did you an upgrade and what is the version you have now running?

We are using CentOS 7, current version of OpenNMS and Java environment:

We are trying to go to whatever version we get from yum update, I believe 24.0.0, but anything 24 and above is where we want to be.

jetty-server.log shows this error a few times:

manager.log shows a lot of errors around beans being unable to create an instance. Apologies, this is on a VM and I’m not sure how to get the files out of it easily.

Alternatively we can do a fresh installation if that is easier, though how do we best export our assets and settings?

Can you run /opt/opennms/bin/ -d and paste the output? If you don’t have it, you can easily download it with

cd /opt/opennms/bin

Here’s the output of that:

Did you ran the config-diff command before or after you did the upgrade? I’m wondering our screenshot shows version 23.0.2?

I ran that after the upgrade. I followed your guide on upgrading from 23 to 24 on CentOS 7, and when I start OpenNMS it runs for about a minute before it just unloads and stops.

Version 23.0.2 is there version we are running at the moment, pre upgrade. Did something go wrong with the upgrade and it didn’t actually take?

Any updates on this or next steps?

The messages you found in jetty-server.log, along with the webapp still identifying itself as 23.0.4, clearly point to a configuration problem. Most likely, you’ve carried over some local customizations that are no longer valid in Horizon 24, perhaps because they’re in a configuration file that changed upstream.

From the presence of a jetty.xml and jetty.keystore, I can infer that you’ve set up HTTPS for the webapp. I would try temporarily moving /opt/opennms/etc/jetty.xml out of the way and see if startup completes afterward. If it does, you’ve isolated one part of the fault and can proceed from there.

Thanks Jeff,

Disabling jetty.xml allowed it to start and run properly, albeit we cannot login with https, which for an internal system is probably fine.

If we did want to get https working, how would we go about doing that? Or did something go wrong during the update procedure that is causing this?