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
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
Created attachment 41833 [details]
Backtrace after attaching gdb to hung rpmq process.
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
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
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.