Bug 246044 - rpm gets stuck - apparently on asymptote package triggers
Summary: rpm gets stuck - apparently on asymptote package triggers
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
: 246127 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-28 01:14 UTC by Michal Jaegermann
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-02 10:57:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
results of 'rpm -vv -Uvh --force vim-common-7.1.12-1.fc8.x86_64.rpm' (134.84 KB, text/plain)
2007-06-28 01:14 UTC, Michal Jaegermann
no flags Details
results of 'rpm -vv -e asymptote' (64.60 KB, text/plain)
2007-06-28 01:15 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2007-06-28 01:14:06 UTC
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

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Michal Jaegermann 2007-06-28 01:14:06 UTC
Created attachment 158085 [details]
results of 'rpm -vv -Uvh --force vim-common-7.1.12-1.fc8.x86_64.rpm'

Comment 2 Michal Jaegermann 2007-06-28 01:15:41 UTC
Created attachment 158086 [details]
results of 'rpm -vv -e asymptote'

Comment 3 Michal Jaegermann 2007-06-28 01:27:51 UTC
Opps!  Forgot to mention.  All explicit rpm operations were done when
all rpm packages were already updated to  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.

Comment 4 Valdis Kletnieks 2007-06-28 04:59:32 UTC
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/\.//'
++ 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/\.//'
+ '[' 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.

Comment 5 Valdis Kletnieks 2007-06-28 05:06:12 UTC
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.....

Comment 6 Michal Jaegermann 2007-06-28 05:44:42 UTC
>  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.

Comment 7 Panu Matilainen 2007-06-28 07:33:07 UTC
Ok, something's busted, I can reproduce reasonably reliably here.

Now to figure out what it is...

Comment 8 Panu Matilainen 2007-06-28 12:05:23 UTC
--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 (

Comment 9 Jose Pedro Oliveira 2007-06-28 13:57:38 UTC
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/).


Comment 10 Michal Jaegermann 2007-06-28 15:14:54 UTC
I am not sure if that would help in the problem but the quoted
code from asymptote triggers can be simplified somewhat like

   set_vversions () {
   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.

Comment 11 Michal Jaegermann 2007-06-28 17:00:22 UTC
... and, as a matter of fact, 'sort' in comment #10 should be
'sort -n'.

Comment 12 Panu Matilainen 2007-06-28 17:50:29 UTC
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 final release :)

Comment 13 Michal Jaegermann 2007-06-28 18:13:11 UTC
> 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. :-)

Comment 14 Paul Nasrat 2007-06-28 19:39:56 UTC
*** Bug 246127 has been marked as a duplicate of this bug. ***

Comment 15 Jose Pedro Oliveira 2007-06-30 21:15:49 UTC

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).


Comment 16 Panu Matilainen 2007-07-02 10:57:47 UTC
What asymptote triggers are doing is "bad", but the bug was in rpm.
rpm- has now found it's way to rawhide, closing. 

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