Red Hat Bugzilla – Bug 57533
rpm -qf "hangs" on a particular filename
Last modified: 2008-05-01 11:38:01 EDT
Description of Problem: rpm -q appears to go into an infinite loop somewhere. Repeatable on whichever file it gets stuck on. Repeatable (sometimes the location of the "hang" moves to another filename) after a --rebuilddb or even low-level fix using "mv Basenames Basenames.orig ; db_dump Basenames.orig | db_load Basenames" Version-Release number of selected component (if applicable): [bill@desktop bill]$ rpm -q rpm rpm-4.0.4-0.2 How Reproducible: In my case, shows up while doing "find /usr/lib/python2.2 | xargs rpm -qf" ... at some point it stops. To narrow it down, I run a loop which echoes the filename and then runs rpm -qf on the one file. This is repeatable; it's always the same file. I've run this as non-root, so there's no reason that any DB corruption should have occurred due to me terminating the "rpm -qf" process. There are no __db* files hanging about. I have rebuilt the database (repeatedly). It only occurs trying to look up a particular file, so not terribly obvious. As the file causing the problem changes after doing the db_dump ... db_load thing, I would guess it's related to the physical layout of the data.
FIrst of all, there's no reason to db_dump anything other than Packages, an rpm --rebuilddb will regenarate all the indices. Next, are there /var/lib/rpm/__db files present or not after the rebuilddb? If the files are present, nuke them.
No, they weren't present even before the "rpm --rebuilddb" ... I've run that several times (as root obviously), the hang happens anyway, whether I run the query command as root or another user. If I run the query as non-root, then the __db* files do *not* appear, even if I interrupt the process. I only tried the db_dump because that was proposed as a solution to another bug (in that case on the Packages table IIRC), and it seemed apparent that the problem was in the Basenames table, or at least the indexing; "rpm -ql" on the package concerned (python) works fine, but rpm -qf on a particular file fails (just hangs, no output, I've left it for around 10 minutes consuming 90% or more CPU). The interesting thing for me was that: 1) initially this was happening for "/usr/lib/python2.2/distutils/README" 2) after at least two attempts at "rpm --rebuilddb" it still hung doing the query on this file 3) after the "db_dump ... db_load" it started to work on that file (=> /me thought it was fixed), but 4) I found (by repeating the "find ... | xargs rpm -qf" process) that it was now hanging on a different filename, in this case "/usr/lib/python2.2/site-packages" So no, it's not just the result of interrupting a process and leaving the __db* files there. I suspect the problem has been there a while, and was only exposed by me running the " ... | xargs rpm -qf" because I rarely use rpm -qf except on files in /lib and /usr/lib when wrestling with conflicts/failed dependencies for Raw Hide packages :o) If you want, I can arrange for you to login and have a look (send me a public SSH key, and we'll coordinate; I have a second dial account with a static IP you'll be able to connect to). I'm sure this is a frustrating bug report, but I assure you this is a repeatable bug. It's just that the file affected changes from time to time. I think it's related to the Basenames index, but whether the bug is in db or rpm is something I'm really not qualified to determine (never done any low-level database work, but I guess this may be time to start :o)
I can't reproduce this problem running find /usr/lib/python2.2 | xargs rpm -qf
But I can ... and doing low-level operations on the database can change where the problem occurs. I have *repeatedly* run rpm --rebuilddb, and the problem persists. So although it may conceivably have been caused by database corruption in the past, it's being preserved in some way across the rebuild operation. I can't quite understand why it would recur after a rebuild unless there's either a problem with the db code, or with the way rpm is searching through the data. There is no problem with [any of] the db file[s] according to db_verify. You're quite welcome to have a look at the database and try to divine what's wrong with it.