Hide Forgot
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 indefinetly): [jan@jodocus /var/tmp 13] cat /proc/7146/status Name: rpm State: S (sleeping) Tgid: 7146 Pid: 7146 PPid: 7099 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 256 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 SigPnd: 0000000000000000 SigBlk: 0000000080000000 SigIgn: 8000000000000000 SigCgt: 000000038001400f CapInh: 0000000000000000 CapPrm: 00000000fffffeff CapEff: 00000000fffffeff 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 situation: 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.
jbj@redhat.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 erase.
*** 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 handling at ftp://ftp.rpm.org/pub/rpm/test-4.2 ftp://ftp.rpm.org/pub/rpm/test-4.1.1 Please do *NOT* reopen this bug, there are already too many variant problems to solve any. Instead, open an individual bug.