I just experienced the good old (bug 73097) lockup on a RH9 box with rpm-4.2-1.fdr.1. 1.fdr.1 is a Fedora (www.fedora.us) rebuild of the 4.2-1 package available at ftp://people.redhat.com/jbj/test-4.2/, with no changes except the release tag AFAICT. I have apt and yum installed, but hadn't been using them for a while when this happened during a routine rpm -Uvh operation. "rm -f /var/lib/rpm/__db* && rpm --rebuilddb" helped. Oh, and I also noticed that /var/lib/rpm/__db* are (0644,root,root) after the rebuilddb while other files in /var/lib/rpm/ are (0644,rpm,rpm). Is this normal? The Fedora rpm packages can be found at http://download.fedora.us/fedora/redhat/9/i386/RPMS.unstable/ http://download.fedora.us/fedora/redhat/9/i386/SRPMS.unstable/ Is there something I can do to help if I see the lockup again?
I just duplicated this on RedHat 9 with the rpm-4.2-0.69 package. This occurred when I tried to upgrade my apt package from freshrpms.net as follows: 963 root@Miney:~# apt-get install apt Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded apt 1 packages upgraded, 0 newly installed, 0 removed and 15 not upgraded. Need to get 873kB of archives. After unpacking 5326kB disk space will be freed. Get:1 http://ayo.freshrpms.net redhat/9/i386/freshrpms apt 0.5.5cnc5-fr2 [873kB]Fetched 873kB in 3s (278kB/s) Executing RPM (-Uvh)... Preparing... ########################################### [100%] 1:apt ########################################### [100%] <A wait of approximately one minute, followed by me hitting Ctrl+C then Ctrl+Z> [1]+ Stopped apt-get install apt 965 root@Miney:~# kill %1 967 root@Miney:~# jobs 969 root@Miney:~# ps -ef | grep rpm root 1920 1 0 22:59 pts/1 00:00:00 /bin/rpm -Uvh --oldpackage --noorder /var/cache/apt/archives/apt_0.5.5cnc5-fr2_i386.rpm 968 root@Miney:~# ls /var/lib/rpm/ Basenames __db.003 Installtid Provideversion Sha1header Conflictname Dirnames Name Pubkeys Sigmd5 __db.001 Filemd5s Packages Requirename Triggername __db.002 Group Providename Requireversion A 'killall -9 rpm' and 'rm /var/lib/rpm/__db*' seemed to fix things. When I ran the exact same apt-get command again, it successfully upgraded apt for me.
newren: Please open up seperate bug reports, rpm-4.2-1 and rpm-4.2-0.69 have different issues. Ville: I need a reproducible case before I can even attempt to identify the cause of the problem. Yes, the rpmdb has locks. Yes, stale locks are possible under execptional conditions, like machine reboots while rpm operation is active, and ceratinly under "kill -9". You can display locks by doing cd /var/lib/rpm /usr/lib/rpm/rpmdb_stat -CA There should be no locks if rpm is inactive. Can you reliably reproduce a problem?
I haven't found a way to reproduce this at all, for now it has only happened to me only once. rpmdb_stat says no locks. I'll try to keep my eyes open for a reproducible test case.
OK, I'm gonna close the bug then. Feel free to reopen if you find a way to reproduce the problem.
I've been bitten by this bug a few times as well. It is not reliably reproduceable. Bugs involving locks rarely are. In combination with the dbenv error when you do an rpmdb --rebuilddb, I panicked once about my RPM database being corrupted and completely wiped my system and re-installed. This has been a persistant problem with me in all rpm 4. It used to happen under RH 8 with great reliability if you tried to install a package from nautilus while not running as root. When I give non-geek friends copies of RH to use, this is the bug that scares me the most because it's the one that they will panic over, and not know how to do anything about. Lockups in a critical component like RPM are a serious issue, and nearly impossible to build a reliable test case for. I find you lack of concern disturbing.