Red Hat Bugzilla – Bug 811867
Latest munin-node update clears all plugin settings
Last modified: 2012-05-13 11:05:36 EDT
Description of problem: I am not sure exactly why, but it looks like the POSTUN script is triggered and all node plugin information is deleted on munin-node-1.4.7-1.fc16.noarch.rpm update. I noticed some changes in a yum behaviour with latest updates, but it may not be related. Version-Release number of selected component (if applicable): 1.4.7-1 How reproducible: Always on yum update
Could you check 'grep munin-node /var/log/yum.log' or 'yum history info munin-node |grep munin-node' and see if it did an uninstall/install or if it did an update?
Apr 09 21:05:36 Updated: munin-node-1.4.7-1.fc16.noarch yum history Updated munin-node-1.4.6-5.fc16.noarch ? Update 1.4.7-1.fc16.noarch @updates looks like update to me. This problem I have also on F15 installations. There was no yum package update. Acctualy this happend to me on F16 and F15 installations at once with the update as of 09 April. Just one machine was off and the update was not applied there, so munin works there. I may try to debug the update somehow there. I've checked the package scripts in 1.4.6 and 1.4.7 and they look same to me...
According to https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax the %postun script needs to be if [ "$1" = "0" ]; then find /etc/munin/plugins/ -maxdepth 1 -type l -print0 |xargs -0 rm fi But I am not sure, that deleting symlinks from /etc is a good idea at all. Maybe the symlinks would better be saved with a .rpmsave suffix. Btw. ASFAICS the bug was introduced with munin-1.4.6-5.fc15.
(In reply to comment #3) > According to https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax > the %postun script needs to be > > if [ "$1" = "0" ]; then > find /etc/munin/plugins/ -maxdepth 1 -type l -print0 |xargs -0 rm > fi Btw. since the current package is broken, the next update needs to take care with %post and %posttrans scripts that the symlinks are restored when the 1.4.7-1.fc16.noarch package is uninstalled for an update.
(In reply to comment #3) > Btw. ASFAICS the bug was introduced with munin-1.4.6-5.fc15. Thanks, this makes the thing clear. The package should be pushed back as soon as possible from updates. I had to dig backups to restore the links. Fixed package should work around the 1.4.6-5,1.4.7-1 bug. I would also preferre not to delete the settings at removal of package.
There's no way to 'push back' a stable update. Sorry. Will try and get this fixed asap tho. ;(
Well, we can fix the underlying issue with the change suggested in comment #3. Sadly, I don't see any easy way to fix it so this last upgrade won't mess things up. (since the postun from the last package runs when it's uninstalled). Anyone have brilliant ideas? Otherwise I will just push this fix out and we can have folks fix their plugins one last time and be back on track.
(In reply to comment #7) > Anyone have brilliant ideas? Otherwise I will just push this fix out and we can > have folks fix their plugins one last time and be back on track. Something like this should work in the new update: %post test "$1" = "2" && mv /etc/munin/plugins /etc/munin/plugins.bak || : %postrans test "$1" = "0" && mv /etc/munin/plugins.bak /etc/munin/plugins || :
ok, that might work. The node post and posttrans though, right?
(In reply to comment #9) > ok, that might work. The node post and posttrans though, right? yes
Can you try these: f18/rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=3986484 f16: http://koji.fedoraproject.org/koji/taskinfo?taskID=3986492 f15: http://koji.fedoraproject.org/koji/taskinfo?taskID=3986514 Feedback welcome before pushing.
This is the transaction output. Better would be to cp instead mv so rm does not fail. Also posttran was not triggered - probably due to error. By the way, in POSTUN there is: %postrans node test "$1" = "0" && mv /etc/munin/plugins.bak /etc/munin/plugins || : Thats probably not correct as per comment 10. Running Transaction Updating : munin-common-1.4.7-2.fc16.noarch 1/4 Updating : munin-node-1.4.7-2.fc16.noarch 2/4 warning: /etc/munin/munin-node.conf created as /etc/munin/munin-node.conf.rpmnew error reading information on service munin-node: No such file or directory Cleanup : munin-node-1.4.7-1.fc16.noarch 3/4 Non-fatal POSTUN scriptlet failure in rpm package munin-node-1.4.7-1.fc16.noarch Cleanup : munin-common-1.4.7-1.fc16.noarch 4/4 find: `/etc/munin/plugins/': No such file or directory rm: missing operand Try `rm --help' for more information. warning: %postun(munin-node-1.4.7-1.fc16.noarch) scriptlet failed, exit status 123 Verifying : munin-node-1.4.7-2.fc16.noarch 1/4 Verifying : munin-common-1.4.7-2.fc16.noarch 2/4 Verifying : munin-common-1.4.7-1.fc16.noarch 3/4 Verifying : munin-node-1.4.7-1.fc16.noarch 4/4
Oops. Try: http://koji.fedoraproject.org/koji/taskinfo?taskID=3989028 Fixed typo in posttrans. (it's posttrans, not postrans) Fixed the rm to not exit incorrectly.
Result is still more or less the same. The problem is in may opinion in usage of /sbin/chkconfig --add munin-node in POSTIN as munin-node is not handled by chkconfig but by systemd at f16. As POSTIN fails, the move is not done and the rest failes too. Messages: warning: /etc/munin/munin-node.conf created as /etc/munin/munin-node.conf.rpmnew error reading information on service munin-node: No such file or directory Non-fatal POSTUN scriptlet failure in rpm package munin-node-1.4.7-1.fc16.noarch find: `/etc/munin/plugins/': No such file or directory rm: missing operand Try `rm --help' for more information. warning: %postun(munin-node-1.4.7-1.fc16.noarch) scriptlet failed, exit status 123
Sigh. yeah. Try: http://koji.fedoraproject.org/koji/taskinfo?taskID=3991612 This should correctly conditionalize that chkconfig call (to use f15).
OK, this way it may work. Just there is still Non-fatal POSTUN scriptlet failure in rpm package munin-node-1.4.7-1.fc16.noarch find: `/etc/munin/plugins/': No such file or directory rm: missing operand Try `rm --help' for more information. warning: %postun(munin-node-1.4.7-1.fc16.noarch) scriptlet failed, exit status 123 from a previous package. This could help to draw the admins attention to the problem in the package.
I suppose we could fix those by using cp/rm... but thats getting more and more complex and prone to failure. I'll go and spin some updates based on this one...
munin-1.4.7-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/munin-1.4.7-2.fc17
munin-1.4.7-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/munin-1.4.7-2.fc16
munin-1.4.7-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/munin-1.4.7-2.fc15
munin-1.4.7-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/munin-1.4.7-2.el6
munin-1.4.7-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/munin-1.4.7-2.el5
Package munin-1.4.7-2.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing munin-1.4.7-2.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5573/munin-1.4.7-2.el5 then log in and leave karma (feedback).
munin-1.4.7-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
The fix is suboptimal because it affects every update in the future... I'd suggest following fix instead so it triggers only on old versions. %triggerun node -- munin-node < 1.4.7-2 mv -f %{_sysconfdir}/munin/plugins %{_sysconfdir}/munin/plugins.bak || : %triggerpostun node -- munin-node < 1.4.7-2 mv -f %{_sysconfdir}/munin/plugins.bak %{_sysconfdir}/munin/plugins || :
Triggers are something I've always avoided... you mean something like: diff --git a/munin.spec b/munin.spec index d01f0fa..63f76fe 100644 --- a/munin.spec +++ b/munin.spec @@ -1,6 +1,6 @@ Name: munin Version: 1.4.7 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Network-wide graphing framework (grapher/gatherer) License: GPLv2 and Bitstream Vera Group: System Environment/Daemons @@ -263,7 +263,6 @@ exit 0 if [ "$1" = "1" ]; then /usr/sbin/munin-node-configure --shell 2> /dev/null | sh >& /dev/null || : fi -test "$1" = "2" && mv /etc/munin/plugins /etc/munin/plugins.bak || : %preun node %if 0%{?rhel} > 6 || 0%{?fedora} > 15 @@ -278,8 +277,11 @@ if [ "$1" = "0" ]; then find /etc/munin/plugins/ -maxdepth 1 -type l -print0 |xargs -0 rm || : fi -%posttrans node -test "$1" = "0" && mv /etc/munin/plugins.bak /etc/munin/plugins || : +%triggerun node -- munin-node < 1.4.7-2 +mv -f %{_sysconfdir}/munin/plugins %{_sysconfdir}/munin/plugins.bak || : + +%triggerpostun node -- munin-node < 1.4.7-2 +mv -f %{_sysconfdir}/munin/plugins.bak %{_sysconfdir}/munin/plugins || : # # main package scripts @@ -375,6 +377,9 @@ exit 0 %changelog +* Tue Apr 24 2012 Kevin Fenzi <kevin@scrye.com> - 1.4.7-3 +- A better for for 811867 with triggers. + * Sun Apr 15 2012 Kevin Fenzi <kevin@scrye.com> - 1.4.7-2 - Fix node postun from messing up plugins on upgrade. Works around bug #811867
Yep. Something like that. Triggers are great tool for fixing bugs in specific package versions.
munin-1.4.7-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/munin-1.4.7-3.fc16
munin-1.4.7-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/munin-1.4.7-3.fc15
munin-1.4.7-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/munin-1.4.7-3.el6
munin-1.4.7-3.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/munin-1.4.7-3.el5
ok, please heavily test the above updates. ;)
Package munin-1.4.7-3.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing munin-1.4.7-3.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5721/munin-1.4.7-3.el5 then log in and leave karma (feedback).
munin-1.4.7-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
munin-1.4.7-3.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
munin-1.4.7-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
munin-1.4.7-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
On EL5 (and it looks like other versions too?), this change looks to have removed: %attr(-, munin, munin) %dir /var/run/munin from the spec and now it is default owned by root. That caused my munin cron runs to fail as they no longer had permissions to remove/create locks in that directory. Shouldn't that directory get munin:munin ownership?
Hey, jeff - if you have a new bug, open one.
Sigh. Yes, this is a problem for sure. Please see bug 821204 reported about this, will fix today and push out new updates. I would _really_ appreciate feedback on the new packages when they are in testing... and/or karma so they could go stable faster if they fix the issue. ;)