On 17 April 2018 at 11:32, Neil MacGregor <nmacgreg@xxxxxxxxxxx> wrote: > Hi folks, we are giant fans of your work! Here's an idea on how to make it better. > > We received an update to Nagios on Friday, last week: > [root@albion ~]# rpm -q --last nagios > nagios-4.3.4-5.el7.x86_64 Fri 13 Apr 2018 04:21:00 AM MDT > > After a reboot, Nagios didn't automatically restart. It's apparent the service has been "disabled" after the upgrade. That's unexpected! > [root@albion nagios]# systemctl status nagios > ● nagios.service - Nagios Network Monitoring > Loaded: loaded (/usr/lib/systemd/system/nagios.service; disabled; vendor preset: disabled) > Active: inactive (dead) > Docs: https://www.nagios.org/documentation/ > > I'm certain that it was set to "enabled" before the update, because I have Dev, Test, and 2xProd instances, all managed by Ansible, and the Prod systems are set to auto-reboot each week. The Prod systems have been in place for 2 years, so we'd have noticed if Nagios wasn't starting at boot time. Of course, I just used our playbook to reset it to "enabled", so our systems are fine. > > Perhaps examine the .spec file for this RPM... it can certainly have a "vendor default" set to "disabled", but the expected behavior is that when I apply an update, it should remain "enabled", if it was set that way before the update. > > Please let me know if you have any questions. Our systems are on CentOS7. > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx We have been getting a couple of reports of this, but I have not been able to duplicate it on my test systems. Here is what the RPM spec file says it is doing with service files install -D -m 0644 -p %{SOURCE7} %{buildroot}%{_unitdir}/%{name}.service /usr/bin/systemctl --no-reload preset %{name}.service > /dev/null 2>&1 || : %systemd_post %{name}.service > /dev/null 2>&1 || : /usr/bin/systemctl condrestart httpd > /dev/null 2>&1 || : /usr/bin/systemctl reload nagios > /dev/null 2>&1 || : %systemd_preun %{name}.service /usr/bin/systemctl condrestart httpd > /dev/null 2>&1 || : /bin/systemctl try-restart %{name}.service >/dev/null 2>&1 || : %systemd_postun_with_restart %{name}.service %systemd_postun_with_restart %{name}.service Looking through the macros, the one I have seen which would actually disable is: %systemd_preun %{name}.service which comes from this section: %preun %if 0%{?el7}%{?fc20}%{?fc21}%{?fc22}%{?fc23}%{?fc24} %systemd_preun %{name}.service %else if [ $1 -eq 0 ]; then # Package removal, not upgrade /sbin/service %{name} stop >/dev/null 2>&1 || : /sbin/chkconfig --del %{name} || : fi %endif The systemd_preun should only happen when a package is being uninstalled and not upgraded.. but I think something is squirrelly in our logic. I will work on what I can to fix this and get it out to testing. -- Stephen J Smoogen. _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
