有时候yum的caching被破坏，我们看到这样的错误：
error: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db3 - (-30974) error: cannot open Packages database in /var/lib/rpm 解决方法是rm -f /var/lib/rpm/__db*然后下一个“yum”命令重新生成数据。
我的问题是：这可能是什么原因造成的？ 是否有一些常见的任务忽略locking或导致此问题的其他问题？
我们有数以百计的CentOS机器，并没有看到这个问题的模式。 这可能是一个“百万分之一”的问题，这个问题往往是大规模的。
注意：我意识到这是一个非常“开放式”的问题，但如果一个答案find了原因，我会回过头来把这个问题转化为更直接与具体问题相关的问题。
在一般情况下，当rpm（或yum）在更新rpmdb时发生这种情况，这是一个Berkeley DB键值存储，非常敏感。 发生这样的崩溃时，rpmdb会处于不一致的状态，并且会发生此错误。 /var/lib/rpm中的所有其他文件都包含相同的信息，但效率较低，因此数据库很容易重build。
在较老的CentOS系统上可能看到的两个值得注意的错误可能会导致这个问题。 在变更日志中出现的一个大问题 ，即“在共享的映射页面回写中出现的令人讨厌的微妙的种族”， 在2007年的内核更新中悄然修复 。 不过，这个报告与报告略有不同 。
你可能会从2009年看到 PackageKit会在不合时宜的情况下杀死yum的， 也是固定的 。 不过，这将更有可能影响桌面系统或带有GUI的服务器。
所有这些错误早于EL 6，而你几乎从不会在EL 6或7上看到这种情况，如果你的EL 5系统是最新的，你也不应该看到它。 （我不知道EL 4.如果你有一个，在它传播之前把它杀掉。）也就是说， 任何在使用rpmdb的时候会导致yum或者rpm死掉的东西都可能导致它。 这包括你今天最有可能看到的东西，随机的宇宙射线翻转的东西，或者有人正在kill -9 。
在RHEL 7中，yum会在实际事务运行期间捕获更多信号，并且会看到消息(shutdown inhibited) 。 这应该有助于防止大多数情况下，某人或某事中断交易并导致此问题。