Hide Forgot
From time to time, when launching a yum command which alters the rpm database, either directly through yum, or through the PackageKit yum backend, yum starts taking up 100% of the CPU, not responding to Ctrl+C and not doing anything apparently. The only way to exit this loop is to kill the yum process from the command line; when you do that, yum will complain about a corrupt rpm database when it's launched again. A way to fix it is to remove /var/lib/rpm/__db.00* files and launch rpm --rebuilddb as root. I reproduced it many many times recently, and from an empiric observation I'd say it usually happens when the yum database is accessed for the first time after a fresh boot.
(In reply to comment #0) > From time to time, when launching a yum command which alters the rpm database, > either directly through yum, or through the PackageKit yum backend With this I mean e.g. 'yum install' or 'yum update' trigger the bug, whereas 'yum search' doesn't.
lots of varying reports of rpmdbs being corrupted ever since the rpm update in rawhide. check your yum history you'll see it. reassigning to rpm.
(In reply to comment #2) > lots of varying reports of rpmdbs being corrupted ever since the rpm update in > rawhide. > > check your yum history you'll see it. > reassigning to rpm. Yeah, I wanted to report this earlier, but never managed to, so I don't really know when this behavior started. Anyway, looking at the dates of rpm updates here [1] I'd say this surely occurred before the 4.9.0 beta update. [1] http://koji.fedoraproject.org/koji/packageinfo?packageID=319
(In reply to comment #2) > lots of varying reports of rpmdbs being corrupted ever since the rpm update in > rawhide. Really? Where? I've only seen one (in bugzilla), and even that doesn't appear to be actual corruption (well ok, pretty much everybody says "corruption" if rpmdb cannot be opened for whatever reason). As for this bug... yum reads through the entire rpmdb to refresh its cache if you've used rpm directly for installing/erasing something, and this can take considerable amount of time (and after a reboot, Berkeley DB's own cache is empty so it'll take even longer). You might want to wait a bit longer to see if it eventually completes. If not, stracing the stuck process should give some clues. If strace doesn't output anything meaningful, attach gdb to the process and to see where it's looping (and attach logs here)
(In reply to comment #4) > As for this bug... yum reads through the entire rpmdb to refresh its cache if > you've used rpm directly for installing/erasing something, and this can take > considerable amount of time (and after a reboot, Berkeley DB's own cache is > empty so it'll take even longer). You might want to wait a bit longer to see if > it eventually completes. If not, stracing the stuck process should give some > clues. If strace doesn't output anything meaningful, attach gdb to the process > and to see where it's looping (and attach logs here) Well, I guess that ~20 minutes on a quad core machine is more than a considerable amount of time :) I don't think it would ever complete. Anyway, thanks for your suggestions of stracing or attaching gdb. Will do the next time I get to reproduce this, and report back.
Okay, at 20min it really sounds like its stuck in a loop someplace. The cache-refreshing is a case of "takes noticeably longer" but nowhere /that/ long, especially on modern hardware.
I've had to delete my db files and rebuild the DB 4 times running rawhide in the last 1-2 weeks. Output each time: error: db4 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db4 - (-30974) error: cannot open Packages database in /var/lib/rpm CRITICAL:yum.main: Error: rpmdb open failed I've not been able to find a cause or any useful debugging output. I have not seen the hang mentioned above though, perhaps my hardware is dying!
(In reply to comment #7) > I've not been able to find a cause or any useful debugging output. I have not > seen the hang mentioned above though, perhaps my hardware is dying! If it's not hanging then it's hardly the same bug, lets not confuse things... FWIW others have been seeing DB_RUNRECOVERY on rawhide recently too, see bug 672932.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This has been long fixed for me, closing.