Details
-
Bug
-
Status: Resolved (View Workflow)
-
Critical
-
Resolution: Fixed
-
26.1.1
-
Security Level: Default (Default Security Scheme)
-
Verified on CentOS 7 and CentOS 8
-
Horizon 2020 - June 24, Horizon 2020 - July 8, Horizon 2020 - July 22, Horizon 2020 - August 5, Horizon 2020 - August 19
-
Backlog NG
Description
When OpenNMS is started by Systemd, it never writes an opennms.pid file to /opt/opennms/logs as it should. The file is completely missing even after stopping OpenNMS (normally it should be present but empty if I'm reading the start script correctly).
If I start OpenNMS by directly invoking /opt/opennms/bin/opennms start, the PID file gets written as expected, so I suspect something about running under Systemd blocks the PID file being written.
If I start it by directly invoking /opt/opennms/bin/opennms -f start, as is now the case since commit bc9c14e7e81b when we are started by Systemd, the PID is once again not written. A look at the startup script seems to show that the code responsible for writing the PID file is unreachable when the -f flag is specified (maps to $BACKGROUND being 1 in the script).
Important: When fixing this problem, take care not to introduce a regression on NMS-12226 with the use of the runCmd() function.
I may have also seen this problem in installations of Horizon 25.2.0, but it does not seem to affect Meridian 2019.1.8 (whose foundation branch was made from 25.0.0 IIRC).
As a side curiosity, we now (since at least Meridian 2019.1.8) write karaf.pid directly in /opt/opennms which is a change from the previous behavior of writing it in /opt/opennms/logs. Probably unrelated but worth mentioning.