Bug 57533 - rpm -qf "hangs" on a particular filename
Summary: rpm -qf "hangs" on a particular filename
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-14 23:17 UTC by Bill Crawford
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-15 09:02:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bill Crawford 2001-12-14 23:17:41 UTC
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

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.

Comment 1 Jeff Johnson 2001-12-15 00:36:56 UTC
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.

Comment 2 Bill Crawford 2001-12-15 09:02:18 UTC
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)

Comment 3 Jeff Johnson 2001-12-19 19:06:25 UTC
I can't reproduce this problem running

	find /usr/lib/python2.2 | xargs rpm -qf

Comment 4 Bill Crawford 2001-12-19 19:58:38 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.