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
Version-Release number of selected component (if applicable):
[bill@desktop bill]$ rpm -q rpm
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
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
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
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.