[checkmk-commits] [tribe29/checkmk] f11e5e: 12030 FIX NagVis: Updated to 1.9.24

Branch: refs/heads/master Home: https://github.com/tribe29/checkmk Commit: f11e5ee0078af5c94a326ca5ebf1411665eb308d https://github.com/tribe29/checkmk/commit/f11e5ee0078af5c94a326ca5ebf141166… Author: Lars Michelsen <lm(a)tribe29.com> Date: 2021-01-29 (Fri, 29 Jan 2021) Changed paths: A .werks/12030 R omd/packages/nagvis/nagvis-1.9.23.tar.gz A omd/packages/nagvis/nagvis-1.9.24.tar.gz M omd/packages/nagvis/nagvis.make Log Message: ----------- 12030 FIX NagVis: Updated to 1.9.24 Change-Id: I27b71a5f3d55f8d0da7c591618bd327b822fdfba Commit: 7f92534e220c3a176ea9954112c978c46448e55c https://github.com/tribe29/checkmk/commit/7f92534e220c3a176ea9954112c978c46… Author: Andreas Umbreit <andreas.umbreit(a)tribe29.com> Date: 2021-01-29 (Fri, 29 Jan 2021) Changed paths: A .werks/11722 Log Message: ----------- 11722 FIX Bug occuring on xinetd reload on agent update On (automatic) agent update on Linux, the update process includes the reload of the xinetd process, if running. This is done by the DEB maintainer scripts or RPM scriptlets, respectively. There are some rare situations (e.g., LCX containers with a running xinetd) that lead to a falsely detected xinetd process on the host system. In that case, the update process would crash on trying to reload xinetd. This behavior is mitigated with this werk, by only detecting running xinetd processes that run under root (uid 0). CMK-6617 Change-Id: I87910592313de97071c8ed01d5b808496ef91c9e Compare: https://github.com/tribe29/checkmk/compare/d5276fe6568a...7f92534e220c