Red Hat Bugzilla – Bug 60319
RPM hangs on -e, -U, i, and -qa
Last modified: 2008-05-01 11:38:01 EDT
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):
Steps to Reproduce:
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.
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.
rm -f /var/lib/rpm/__db*
These files contain db locks, an ^C can leave locks behind.
CLosed because I believe the
rm -f /var/lib/rpm/__db*
fix will work. Please reopen if I'm wrong ...
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
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.
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