Bug 57533
| Summary: | rpm -qf "hangs" on a particular filename | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | Bill Crawford <billc> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-12-15 09:02:22 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bill Crawford
2001-12-14 23:17:41 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. 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. |