This is a category bug for a class of "hangs"
that are new in rpm-4.1.
rpm-4.1 orders packages differently than previously,
putting all erased packages at the end of a
transaction, rather than interleaving installs and
erasures like previous versions of rpm.
So, if you are seeing an upgrade apparently "hang"
at the end of a transaction, with the screen displaying
100%, take a look at top to see if rpm is using cpu
cycles. If so, then rpm is not really hung at all,
just busy doing erasures. If not, you have some other
problem, go to the bug that looks like
rpm-4.1 hangs: READ THIS FIRST
to see the categories of "hangs" in rpm-4.1.
Yes, rpm needs to supply better user feedback during
erasures, but that's a different problem, probably also
somewhere here in bugzilla.
I have _this_ type of hanging problem.
My box is a rawhide machine which is daily updated.
I have seen this kind of problem more and more often over the past 2 or 3
months. It occurs about 5% of the times, and it has more chance to happens if
lots of package are upgraded at the same time. That's all about I can say, but
really there is hanging problem in "rpm -Uvh".
I've experienced the same problems as described above using the rpm version
from RedHat 8.0.
I ran rpm -Uvvh (upgrading several rpms). This showed were the rpm stopped:
D: erase: %postun(xawtv-3.73-3) asynchronous scriptlet start
D: erase: %postun(xawtv-3.73-3) execv(/bin/sh) pid 7375
+ '[' 1 = 0 ']'
At this time the child process is gone.
At the same time the process is in the following state (it stays there
[jan@jodocus /var/tmp 13] cat /proc/7146/status
State: S (sleeping)
Uid: 0 0 0 0
Gid: 0 0 0 0
Groups: 0 1 2 3 4 6 10
VmSize: 11540 kB
VmLck: 0 kB
VmRSS: 7476 kB
VmData: 4856 kB
VmStk: 280 kB
VmExe: 1772 kB
VmLib: 2840 kB
I couldn't find any documentation on the coding of the signalmasks in /proc,
but my guess from here would be that the sigchld signal from the postuninstall
script gets blocked/is ignored, leaving rpm to wait for it.
Another sideeffect I'v encountered after stopping rpm with kill -9 in this
The upgraded packages suddenly have 2 installed instances in the rpm database:
the old version and the new version:
The fix for this is to 'rpm -e package-oldversion'. The files and database
entries for the new version are apparently already in place, but the entries
from the old version are still in the database.
rpm -ql & rpm -V show that it's alright after the rpm -e.
If needed I can provide the whole output of rpm -Uvvh.
email@example.com said: "rpm-4.1 orders packages differently than previously,
putting all erased packages at the end of a transaction, rather than
interleaving installs and erasures like previous versions of rpm."
That is bad news I am afraid - this would mean that much more space on /usr is
needed to complete rpm -U with a significant number of packages than what was
needed with previous versions of rpm ... Or does this refer to removing entries
from rpm database only?
On upgrade, files are mostly replaced, so not very
much more diskspace is is needed and/or required.
Remember, rpm installs before removing, marking
files that have just been replaced to be skipped during
*** Bug 76635 has been marked as a duplicate of this bug. ***
Any news on this widespread issue in RPM 4.1? All of our RH 8 boxes here are
having problems with rpm crashing, partial failures, etc.
Me too [TM]
Time to close this umbrella bug too.
There are test packages that fix missed SIGCLD and SIGPIPE
Please do *NOT* reopen this bug, there are already too
many variant problems to solve any. Instead, open an