Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 20.0.1, Meridian-2017.1.0
-
Component/s: Build / Packaging
-
Security Level: Default (Default Security Scheme)
-
Labels:None
-
Sprint:Horizon - April 12th, Horizon - April 19th, Horizon - April 26th, Horizon - May 3rd, Horizon - May 10th, Horizon - May 17th
Description
If OpenNMS is running and you do an "rpm/yum/dnf" update of the opennms packages, OpenNMS stays running even though the files associated for it get removed due to the package update.
opennms.spec should use %pretrans or %pre to verify OpenNMS isn't running to ensure the package update won't unexpectedly cause problems.
Activity
Maybe we just keep this open for later then?
If we want to suggest that we exclude it from normal upgrades, then our installation instructions should mention that.
Maybe once we get the configuration to a point where its fully modularized, then we could review this again?
Ron Roskens
added a comment - Maybe we just keep this open for later then?
If we want to suggest that we exclude it from normal upgrades, then our installation instructions should mention that.
Maybe once we get the configuration to a point where its fully modularized, then we could review this again? I'll just update the documentation to discuss excluding opennms from upgrades and close this. If things become fully modularized, then staying running shouldn't be an issue, so it would fix itself. 
Seem reasonable?
Benjamin Reed
added a comment - I'll just update the documentation to discuss excluding opennms from upgrades and close this. If things become fully modularized, then staying running shouldn't be an issue, so it would fix itself. Seem reasonable? Yep!
Ron Roskens
added a comment - Yep! Benjamin Reed
added a comment - PR: https://github.com/OpenNMS/opennms/pull/1494 Merged to foundation-2017
Ronny Trommer
added a comment - Merged to foundation-2017 
Similar packages (databases, X window managers, etc) do not attempt to shut down running processes before upgrading packages, even though this may lead to failures or unexpected behavior in the running processes. My vote is to maintain the current behavior because trying to do process management inside packaging is unexpected.