Bug 811867 - Latest munin-node update clears all plugin settings
Latest munin-node update clears all plugin settings
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: munin (Show other bugs)
15
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-12 03:38 EDT by Adam Pribyl
Modified: 2012-05-13 11:05 EDT (History)
7 users (show)

See Also:
Fixed In Version: munin-1.4.7-3.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-13 11:05:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Pribyl 2012-04-12 03:38:35 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
Comment 1 d. johnson 2012-04-12 09:14:13 EDT
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?
Comment 2 Adam Pribyl 2012-04-12 09:59:16 EDT
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...
Comment 3 Till Maas 2012-04-12 12:11:59 EDT
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.
Comment 4 Till Maas 2012-04-12 12:17:21 EDT
(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.
Comment 5 Adam Pribyl 2012-04-12 13:31:39 EDT
(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.
Comment 6 Kevin Fenzi 2012-04-12 13:38:02 EDT
There's no way to 'push back' a stable update. Sorry. 

Will try and get this fixed asap tho. ;(
Comment 7 Kevin Fenzi 2012-04-12 13:50:03 EDT
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.
Comment 8 Till Maas 2012-04-12 14:30:37 EDT
(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 || :
Comment 9 Kevin Fenzi 2012-04-12 17:06:25 EDT
ok, that might work. The node post and posttrans though, right?
Comment 10 Till Maas 2012-04-12 17:29:28 EDT
(In reply to comment #9)
> ok, that might work. The node post and posttrans though, right?

yes
Comment 12 Adam Pribyl 2012-04-13 02:57:28 EDT
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
Comment 13 Kevin Fenzi 2012-04-13 13:58:14 EDT
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.
Comment 14 Adam Pribyl 2012-04-14 15:36:16 EDT
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
Comment 15 Kevin Fenzi 2012-04-14 18:29:45 EDT
Sigh. yeah. 

Try: http://koji.fedoraproject.org/koji/taskinfo?taskID=3991612

This should correctly conditionalize that chkconfig call (to use f15).
Comment 16 Adam Pribyl 2012-04-15 02:30:37 EDT
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.
Comment 17 Kevin Fenzi 2012-04-15 15:08:17 EDT
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...
Comment 18 Fedora Update System 2012-04-15 16:46:00 EDT
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
Comment 19 Fedora Update System 2012-04-15 16:57:24 EDT
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
Comment 20 Fedora Update System 2012-04-15 17:12:02 EDT
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
Comment 21 Fedora Update System 2012-04-15 17:21:53 EDT
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
Comment 22 Fedora Update System 2012-04-15 17:34:42 EDT
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
Comment 23 Fedora Update System 2012-04-16 13:56:55 EDT
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).
Comment 24 Fedora Update System 2012-04-19 23:09:33 EDT
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.
Comment 25 Tuomo Soini 2012-04-24 15:24:51 EDT
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 || :
Comment 26 Kevin Fenzi 2012-04-24 19:25:25 EDT
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
Comment 27 Tuomo Soini 2012-04-27 02:42:41 EDT
Yep. Something like that. Triggers are great tool for fixing bugs in specific package versions.
Comment 28 Fedora Update System 2012-04-27 12:42:48 EDT
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
Comment 29 Fedora Update System 2012-04-27 12:58:38 EDT
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
Comment 30 Fedora Update System 2012-04-27 13:14:07 EDT
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
Comment 31 Fedora Update System 2012-04-27 13:23:17 EDT
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
Comment 32 Kevin Fenzi 2012-04-27 13:26:30 EDT
ok, please heavily test the above updates. ;)
Comment 33 Fedora Update System 2012-04-27 19:09:04 EDT
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).
Comment 34 Fedora Update System 2012-05-12 15:54:47 EDT
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.
Comment 35 Fedora Update System 2012-05-12 15:55:30 EDT
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.
Comment 36 Fedora Update System 2012-05-12 21:51:48 EDT
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.
Comment 37 Fedora Update System 2012-05-12 21:57:31 EDT
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.
Comment 38 Jeff Sheltren 2012-05-13 10:26:42 EDT
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?
Comment 39 Tuomo Soini 2012-05-13 10:54:06 EDT
Hey, jeff - if you have a new bug, open one.
Comment 40 Kevin Fenzi 2012-05-13 11:05:36 EDT
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. ;)

Note You need to log in before you can comment on or make changes to this bug.