Bug 58007 - rpmq going to sleep on select()
Summary: rpmq going to sleep on select()
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-01-05 01:26 UTC by Bill Crawford
Modified: 2008-05-01 15:38 UTC (History)
0 users

Clone Of:
Last Closed: 2002-01-07 22:39:04 UTC

Attachments (Terms of Use)
Backtrace after attaching gdb to hung rpmq process. (1.65 KB, text/plain)
2002-01-05 01:28 UTC, Bill Crawford
no flags Details

Description Bill Crawford 2002-01-05 01:26:38 UTC
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

Comment 1 Bill Crawford 2002-01-05 01:28:57 UTC
Created attachment 41833 [details]
Backtrace after attaching gdb to hung rpmq process.

Comment 2 Jeff Johnson 2002-01-07 21:27:23 UTC
	rm -f /var/lib/rpm/__db*

Comment 3 Bill Crawford 2002-01-07 22:36:43 UTC
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?

Comment 4 Bill Crawford 2002-01-07 22:38:58 UTC
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

Comment 5 Jeff Johnson 2002-01-08 17:48:30 UTC
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.

Comment 6 Bill Crawford 2002-01-08 18:18:24 UTC
Well, OK ... cluster packages would be nice.

But this is still a bug, as is the other problem I reported.

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