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. <p> 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: Sometimes Steps to Reproduce: 1. Download http://prdownloads.sourceforge.net/sgmltools-lite/sgmltools-lite-3.0.3-rh71.2.noarch.rpm 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:
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.
Try doing 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 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.
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 planned.