Bug 60319 - RPM hangs on -e, -U, i, and -qa
Summary: RPM hangs on -e, -U, i, and -qa
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 7.2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL: http://sourceforge.net/project/showfi...
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-25 15:45 UTC by David Nedrow
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-04 13:20:26 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Nedrow 2002-02-25 15:45:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8) Gecko/20020204

Description of problem:
rpm (4.0.3-1.03) hangs when doing any of these three operations: e, U, i, and
qa. All other operations seem to work fine, including --rebuild which will
correct the problem (at least temporarily). I've seen this on several machines
and others have reported it in the newsgroups.
I have found one way to always cause the problem on one of my machines. The
steps are provided below. Note that this behavior is not apparent or
reproducible on every Red Hat 7.2 machine.

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

How reproducible:

Steps to Reproduce:
1. Download
2. rpm -Uvh sgmltools-lite-3.0.3-rh71.2.noarch.rpm
3. rpm should say preparing and then stop responding altogether.

Actual Results:  rpm displays "Preparing" but never draws any hash marks,
regardless of how long you wait. If you ^C, you will also no no longer be able
to delete, upgrade, or install any package. Additionally, an rpm -qa will
generally hang partway through the list.

If you now do an rpm --rebuild, the system should return to normal operation
(unless you again try to install the package mentioned previously). Note that
others have been unable to determine what caused their rpm system to become half
functional, but once the behavior starts it is consistent. Also, some users with
this problem have reported that --rebuild does not help them and the have to
reisntall the entire system.

Expected Results:  I should be able to install, upgrade, erase and print a list
of all packages without hosing the rpm database.

Additional info:

Comment 1 Rex Dieter 2002-02-25 17:53:03 UTC
I've seen similar things happen on machines of mine.  Almost every time, I had
previously pressed CNTL-C interrupting an rpm operation.  Subsequent rpm 
operations would then hang, until I did a rpm --rebuild.  In my experience, 
rpm --rebuild has always (>20 times) fixed any problems I had been experiencing.

Since then, I always try to proofread any rpm commands a enter carefully, as
to avoid the need to interrupt with CNTL-C.

Comment 2 Jeff Johnson 2002-02-25 18:07:04 UTC
Try doing
	rm -f /var/lib/rpm/__db*
These files contain db locks, an ^C can leave locks behind.

Comment 3 Jeff Johnson 2002-03-01 00:30:32 UTC
CLosed because I believe the
	rm -f /var/lib/rpm/__db*
fix will work. Please reopen if I'm wrong ...

Comment 4 David Nedrow 2002-03-04 13:20:22 UTC
OK, so there is a work around, but not a fix. If it's known that rpm leaves
behind lock files after a control C and can't recover on its own, shouldn't rpm
intercept a Control-C, clean itself up, and then exit? I've had to do this in my
own apps.

Given the number of people who run in to this problem, I think it would behoove
the rpm maintainers to prevent the spurious lock files from being left behind.

You could at least add a check for lock files on rpm start and issue the "You
need to do a rm -f /var/lib/rpm/__db*" message for the user.

Comment 5 Jeff Johnson 2002-03-04 13:37:20 UTC
rpm-4.0.4 removes the files (if possible) on
next invocation. That doesn't work if the
files were created by root who used ^C, and
the next user is non-root. The fix there
will require a setgid helper binary, already

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