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): 4.0.3 How Reproducible: Always. Steps to Reproduce: 1. rpm -qa Actual Results: See the attached strace log.
Created attachment 36921 [details] strace output from running rpm -qa
If you run: rm -f /var/lib/rpm/__db* does the problem go away?
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 course).
Using ^C with rpm as root, but querying as user causes the problem. Problem appears resolved.
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.
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.