Description of Problem: Inadvertently running a "rpm -q something-x.y-z" whilst /etc/cron.daily/rpm was running appears to have caused the latter rpmq process to hang. A backtrace will be attached in a moment. Version-Release number of selected component (if applicable): [bill@desktop bill]$ rpm -q rpm rpm-4.0.4-0.4 Bizarrely that rpm -q ran fine whilst the other process was sat there with gdb attached ... *shrug* I'm assuming there is something specific about the state of my rpm database (and others that have had this problem) that isn't there in yours, so you can't reproduce it. I'm quite happy as I've said before for you to look at this rpm database to see if you can find the problem(s). As far as I'm concerned, though, even if the problem *has* been caused by some kind of corruption in the past, I have run --rebuilddb *several* times, to no avail; this, and the problem I have with rpm -qf hanging, are still appearing.
Created attachment 41833 [details] Backtrace after attaching gdb to hung rpmq process.
Try rm -f /var/lib/rpm/__db*
Yeah, sure ... but why is the process hanging like that? It *appears* to have been triggered by two processes trying to access the database at the same time, sure ... but they're both read-only accesses, if they're queries, aren't they? Why does that end up hanging? Can't we just get rid of these __db* files?
And closing bugs as "WORKSFORME" when it plainly isn't working right for other people really isn't an answer, please consider that some bugs only affect a small number of people, and I assure you they have been reproducible and repeatable.
Short answer: The __db files are gonna be necessary to support concurrent database access so that, say, rpm installs can be run from %post scriptlets (i.e. a package of packages). No they cannot be eliminated. And I have a limited number of resolutions to choose from, WORKSFORME is closest IMHO.
Well, OK ... cluster packages would be nice. But this is still a bug, as is the other problem I reported.