Bug 55920 - rpm hanging when doing -qa, breaks up2date
rpm hanging when doing -qa, breaks up2date
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2001-11-08 14:07 EST by Need Real Name
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-09 04:17:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace output from running rpm -qa (63.76 KB, text/plain)
2001-11-08 14:08 EST, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2001-11-08 14:07:46 EST
Description of Problem:

When I do "rpm -qa", it spews out a number of RPM's and then hangs.  
up2date and other programs that uses rpm hangs as a consequence.

Version-Release number of selected component (if applicable):


How Reproducible:


Steps to Reproduce:
1. rpm -qa

Actual Results:

See the attached strace log.
Comment 1 Need Real Name 2001-11-08 14:08:32 EST
Created attachment 36921 [details]
strace output from running rpm -qa
Comment 2 Bill Nottingham 2001-11-08 21:17:36 EST
If you run:

rm -f /var/lib/rpm/__db*

does the problem go away?
Comment 3 Need Real Name 2001-11-09 04:17:50 EST
Yes, deleting __db* works fine. Thanks!

Do you know what caused this?  Crashing machines while rpm was working?  Maybe 
rpm/up2date could delete those files automatically (if it is safe to do so, of 
Comment 4 Jeff Johnson 2001-11-09 12:31:59 EST
Using ^C with rpm as root, but querying as user causes the problem.

Problem appears resolved.
Comment 5 Need Real Name 2001-11-09 12:48:35 EST
I can reproduce this by ^C'ing "rpm -qa" as root.

I don't think this is intended behaviour, rpm should not permanently break 
because you ^C "rpm -qa" once.  It should use a ^C sighandler to clean up 
after itself.  Or even better, detect stale __db* files on startup.
Comment 6 Jeff Johnson 2001-11-09 13:47:43 EST
The problem is not signal handling, but rather a
reference count that is left in the __db file.
The fix is more complicated than handling signals
(which are already handled), and will involve
removing the database object from the rpmlib API.
This has already been done.

The __db files are being removed on all of rpm exec,
rpm exit and even on system reboot. That doesn't work
when root does ^C, and user cannot remove file.
The traditional remedy, making rpm setgid, is underway,
but the better solution yet is to get POSIX shared mutexes
implemented in the kernel, as write access to the lock
is needed even if the rpm database is opened read only.

Oh yeah, the goal of this whole exercise is to permit
concurrent write access to the rpm database.

And, finally, rpm doesn't exactly "permanently break"
when the problem occurs. Nuke the __db files and be happy.

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