Bug 673257

(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 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.