Bug 58007

Summary: rpmq going to sleep on select()
Product: [Retired] Red Hat Raw Hide Reporter: Bill Crawford <billc>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED WORKSFORME 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: 2002-01-07 22:39:04 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:
Attachments:
Description Flags
Backtrace after attaching gdb to hung rpmq process. none

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
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.
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 
Try
	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
repeatable.
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.