Red Hat Bugzilla – Bug 87812
rpm hangs during up2date
Last modified: 2007-04-18 12:52:41 EDT
This is on a fresh RHL 9 install, + Jakub's proposed glibc errata (glibc-2.3.2-22.9.i686.rpm) up2date hangs: [cricker@winsucks tmp]$ sudo up2date --nox -u Password: Fetching package list for channel: redhat-linux-i386-9... ######################################## Fetching Obsoletes list for channel: redhat-linux-i386-9... ######################################## Fetching rpm headers... ######################################## Testing package set / solving RPM inter-dependencies... ######################################## krb5-devel-1.2.7-14.i386.rp ########################## Done. krb5-libs-1.2.7-14.i386.rpm ########################## Done. krb5-server-1.2.7-14.i386.r ########################## Done. krb5-workstation-1.2.7-14.i ########################## Done. openssl-0.9.7a-5.i686.rpm: ########################## Done. openssl-devel-0.9.7a-5.i386 ########################## Done. openssl-perl-0.9.7a-5.i386. ########################## Done. openssl096-0.9.6-17.i386.rp ########################## Done. openssl096b-0.9.6b-6.i386.r ########################## Done. Preparing ########################################### [100%] Installing... 1:krb5-libs ########################################### [100%] This appears to be because rpm is hanging. [cricker@winsucks cricker]$ ps -ef | grep rpm cricker 26787 26754 0 14:17 pts/11 00:00:00 grep rpm [cricker@winsucks cricker]$ ps -ef | grep up2date root 26714 3997 0 14:06 pts/3 00:00:00 up2date --nox -u root 26715 26714 0 14:06 pts/3 00:00:00 /usr/sbin/userhelper -w up2date --nox -u root 26716 26715 4 14:06 pts/3 00:00:27 /usr/bin/python -u /usr/sbin/up2date --nox -u cricker 26789 26754 0 14:17 pts/11 00:00:00 grep up2date [cricker@winsucks cricker]$ sudo strace -f -p 26716 Password: futex(0x40dd5090, FUTEX_WAIT, 0, NULL Looks like rpm futex locking is b0rked.....
I tried to repair the db by removing the shared locks (/var/lib/rpm/__db.00?) and running rpmdb --rebuilddb so far that's been running for ~45 minutes. strace shows a long series of pread() and pwrite(), as I'd think it should, but the time seems quite excessive (this on an Athlon 1700+, 512 megs RAM)
It eventually finished but with a (harmless?) error: [cricker@winsucks rpm]$ sudo rpmdb --rebuilddb error: db4 error(16) from dbenv->remove: Device or resource busy [cricker@winsucks rpm]$
Yes, harmless, but let's backup. A --rebuilddb should finish in minutes, maybe 10 if you got a gazillion packages. Add -vv to get feedback, compare your slow machine with some other. FYI: stale locks can be displayed by doing cd /var/lib/rpm /usr/lib/rpm/rpmdb_stat -CA See the db4-utils doco for dbstat, rpmdb_stat is exactly that. And you might try rpm-4.2 all-but-final (and errata expected) from ftp://ftp.rpm.org/pub/rpm/test-{4.2,4.1.1} So how does the speed of --rebuilddb -vv compare with some other machine?
This time when I did the rpmdb --rebuild -vv it only took about 12 minutes on this same system (it's an everything install + some local RPMs, so I'd expect it to take a while)
Here's a data point, --rebuilddb -vv, 960 packages, 600MHz dual SMP, SCSI: 88.55user 10.97system 1:58.77elapsed 83%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (1344major+35058minor)pagefaults 0swaps 12 minutes still seemes excessive to me. what's the difference?
With 1400 packages, I'm seeing real 15m26.431s user 1m4.000s sys 0m16.890s now on this system.
(The rpm-hanging-during-install thing is related to 87747, right?) Anyway, on my system (ASUS P2B-DS, 2x P3-800MHz, 1Gb PC-100 ECC RAM, / on an IBM DRVS09V [U2W-LVD SCSI, 7200rpm]), I ran "rpm -vv --rebuilddb", let it finish (approx 15 min.), then ran it again: # script # time rpm -vv --rebuilddb and I got this: real 12m22.903s user 2m23.610s sys 0m40.620s I was replying to some email while running it (via kmail) but otherwise the system was essentially idle. The disk sure took a beating, though - most of the time was spent waiting for I/O, based on the numbers from time(1). FYI: # rpm -qa | wc-l # time rpm -qa | wc -l 1430 real 0m17.496s user 0m16.380s sys 0m0.710s **Seventeen seconds** to open a db4 file, iterate through each key, print it, and close the file seems excessive on this hardware. -Adam Thompson athompso@athompso.net
Not when you realize that header-only signatures/digests are verified for each header read. Add --nodigest --nosignature to disable. Meanwhile hangs come from multiple sources, assuming that 2 bugs that include the word "hang" is futile. Please open a different bug. Meanwhile 12-15 minutes for --rebuilddb is larger than I would expect, but is far less than 45 minutes. I still do not understand what caused 45 minutes.
Forget --rebuilddb, is the hang fixed or not?!
zaitcev@redhat.com, did you try the rpm builds at ftp://ftp.rpm.org/pub/rpm/test-4.2/?
I have a fresh RH9 load and I still got the same old "hang" as in 8.0. Had to kill and delete the locks to get going again.
Pete, I haven't had it hang again, now that I'm using the final glibc errata (glibc-2.3.2-27.9)
I'm pretty sure this problem is fixed in rpm-4.2-1. Reopen if not.