Description of problem: A yum update from today got stuck in a cleanup phase for 'vim-common' ( from 7.1.2-1.fc8 to 7.1.12-1.fc8). After 45 minutes that required killing yum job, followed by 'rpm --rebuilddb' and a cleanup of a buch of duplicates. During this cleanup it turned out that rpm -Uvh --force vim-common-7.1.2-1.fc8.x86_64.rpm does not go anywhere and '--v' shows locked it there: ..... D: erase: %postun(asymptote-1.30-1.fc8.x86_64) asynchronous scriptlet start D: erase: %trigger(asymptote-1.30-1.fc8.x86_64) execv(/bin/sh) pid 28585++ rpm -q '--qf=%{epoch}:%{version}\n' vim-common .... + ln -sf ../../../asymptote/asy.vim . D: erase: waitpid(28585) rc 28585 status 0 secs 0.124 D: --- h# 523 vim-common-7.1.2-1.fc8 Full -vv output attached. A subseqent attempt to 'rpm -e asymptote' also got nowhere and '-vv' for a change gave that: D: erase: %postun(asymptote-1.30-1.fc8.x86_64) execv(/bin/sh) pid 28808+ texhash + '[' 0 = 0 ']' + /sbin/install-info --delete asymptote /usr/share/info/dir + /sbin/install-info --delete asy-faq /usr/share/info/dir D: erase: waitpid(28808) rc 28808 status 0 secs 0.656 D: --- h# 778 asymptote-1.30-1.fc8 with no further activity. Only 'rpm -e --noscripts --notriggers asymptote' eventually worked and I was able to continue with a cleanup job for the remaining packages. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 158085 [details] results of 'rpm -vv -Uvh --force vim-common-7.1.12-1.fc8.x86_64.rpm'
Created attachment 158086 [details] results of 'rpm -vv -e asymptote'
Opps! Forgot to mention. All explicit rpm operations were done when all rpm packages were already updated to 4.4.2.1-0.2.rc1. I am not sure if 'yum update' used that when it got stuck but all releated rpm packages cleanups happened before a cleanup for vim-common was attempted. A cleanup for 'emacs-common', which also shows up in asymptote triggers and accidentally was in the same update transaction, was already finished before ab update tied itself in a knot.
Am seeing this as well - vim-common-7.1.12-1.fc8.x86_64.rpm causes both yum and rpm indigestion (found it first when 'yum update' against rawhide updated 83 packages and then cleaned up only 70 before wedging). I think asymptote is a red herring, or "just the trigger", as it's not installed on my machine at all. Also, I saw the same problem intermittently with other RPMS as well - scim-libs, popt and krb5-libs RPMs at least. It seemed to be *very* order-dependent. If I did 'rpm -Uvh --force [s-x]*.rpm' it would hang consistently on scim-libs, but then when I did 'rpm -Uvh --force s*' followed by '--force x*' in 2 seperate commands, it worked without complaint. Here's the tail end of 'rpm -Uvh --force -vv vim-common': ++ sort ++ head -n 1 ++ sed -e 's/[0-9]*://' ++ sed -e 's/\.[0-9]*$//' ++ sed -e 's/\.//' + VIMVEROLD=71 ++ rpm -q '--qf=%{epoch}:%{version}\n' vim-common ++ sort ++ tail -n 1 ++ sed -e 's/[0-9]*://' ++ sed -e 's/\.[0-9]*$//' ++ sed -e 's/\.//' + VIMVERNEW=71 + '[' 1 = 1 ']' + rm -f /usr/share/vim/vim71/syntax/syslog-ng.vim + '[' -d /usr/share/vim/vim71/syntax ']' + cd /usr/share/vim/vim71/syntax + ln -sf ../../../syslog-ng/syslog-ng.vim . D: erase: waitpid(23361) rc 23361 status 0 secs 0.126 D: --- h# 1875 vim-common-7.1.2-1.fc8 And then we're waiting for something to happen: # ps lax | grep rpm 4 0 23330 18552 20 0 130196 27532 futex_ S+ pts/1 0:03 rpm -Uvh --force -vv vim-common-7.1.12-1.fc8.x86_64.rpm No idea what that futex is attached to, though. If need be, I can strace it if that would help.
OK.. I'll bite. Looking back at Michal's comments, I got brave and tried 'rpm -Uvh --force --noscripts vim-common*'. And that worked. Unclear why adding --noscripts makes it work when 'rpm -q --scripts vim-common' says there *aren't* any scripts for the RPM.....
> I think asymptote is a red herring Quite possible and that is why I wrote "apparently". This was just one observation and in my particular case removing asymptote got things "unstuck". Also a quick peek on those triggers did not reveal any obvious "smoking gun". Something funny in a database? Order sensitivity as observed by Valdis would point in this direction.
Ok, something's busted, I can reproduce reasonably reliably here. Now to figure out what it is...
--notriggers appears to be enough to clear the stuck erase, and here's the smoking gun: [pmatilai@localhost ~]$ rpm -q --triggers asymptote|grep rpm VIMVERNEW=`rpm -q --qf='%{epoch}:%{version}\n' vim-common | sort | tail -n 1 | sed -e 's/[0-9]*://' | sed -e 's/\.[0-9]*$//' | sed -e 's/\.//'` VIMVEROLD=`rpm -q --qf='%{epoch}:%{version}\n' vim-common | sort | head -n 1 | sed -e 's/[0-9]*://' | sed -e 's/\.[0-9]*$//' | sed -e 's/\.//'` VIMVEROLD=`rpm -q --qf='%{epoch}:%{version}\n' vim-common | sort | head -n 1 | sed -e 's/[0-9]*://' | sed -e 's/\.[0-9]*$//' | sed -e 's/\.//'` VIMVERNEW=`rpm -q --qf='%{epoch}:%{version}\n' vim-common | sort | tail -n 1 | sed -e 's/[0-9]*://' | sed -e 's/\.[0-9]*$//' | sed -e 's/\.//' After muchos headscratching and bisecting and throwing away invalid test results, it turned out to me a seemingly unrelated change which caused the query within the trigger to leave a db iterator unfreed which then causes the lockup when running from within a transaction. Fun... Fixed in rpm.org and should be in tomorrows rawhide (4.4.2.1-0.3.rc1)
I also have the same kind of vim-common triggers in the syslog-ng package. The vim-common triggers are rather nasty as they have to invoke the rpm command to find the vim version being removed/installed/updated (the vim version is hardcoded in the shared directories - eg: /usr/share/vim/vim70/). jpo
I am not sure if that would help in the problem but the quoted code from asymptote triggers can be simplified somewhat like that: set_vversions () { VIMVEROLD="$2" VIMVERNEW="$4" } set_vversions `rpm -q --qf='%{epoch} %{version}\n' vim-common \ | sort | sed -e 's/\.//' -e 's/\..*$//'` At least a number of external processes there will be cut down.
... and, as a matter of fact, 'sort' in comment #10 should be 'sort -n'.
The sorts and such are irrelevant to this bug, the bad juju is in calling rpm from within rpm. It's supposed to work, but it's not a very good idea anyhow for various reasons. That said, I'm glad this bug was found now instead of after 4.4.2.1 final release :)
> The sorts and such are irrelevant to this bug ... That is clear. Only once you started to talk about "smoking gun" in comment #8 a suggestion was that maybe simpler scripts/triggers would make an rpm life easier. OTOH if that would be too plush then maybe the bug would hide better. :-)
*** Bug 246127 has been marked as a duplicate of this bug. ***
Hi, A new build of asymptote will be pushed into the development repository in a couple of hours (the {emacs,xemacs,vim}-common triggers are still all there). jpo
What asymptote triggers are doing is "bad", but the bug was in rpm. rpm-4.4.2.1-0.3.rc1 has now found it's way to rawhide, closing.