CentOS yum Fatal Error 处理一例

环境说明

[root@thatsit ~]# cat  /etc/redhat-release

CentOS Linux release 7.1. (Core)

[root@thatsit ~]# uname -r

3.10.-229.7..el7.x86_64

[root@thatsit ~]#

报错信息

[root@thatsit ~]# yum  -y install  docker

error: rpmdb: BDB0113 Thread/process / failed: BDB1507 Thread died in Berkeley DB library

error: db5 error(-) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery

error: cannot open Packages index using db5 -  (-)

error: cannot open Packages database in /var/lib/rpm

CRITICAL:yum.main:

Error: rpmdb open failed

[root@thatsit ~]#

处理步骤

1, rm -f /var/lib/rpm/__db*    # 删除/var/lib/rpm 目录下的__db开头的rpmdb文件

2, rpm --rebuilddb             # rpm数据库重建

3, yum clean all               # 清理所有yum缓存

4, yum makecache               # 重新生成yum缓存

※: 此解决法方法在RHEL/CentOS 5(未测试),6,7系列的操作系统中都是适用的.

执行过程

[root@thatsit ~]# cd  /var/lib/rpm

[root@thatsit rpm]# ll  -htr

total 42M

-rw-r--r--.  root root .0K Feb  : Triggername

-rw-r--r--.  root root  16K Feb  : Obsoletename

-rw-r--r--.  root root .0K Feb  : Conflictname

-rw-r--r--.  root root  32K Feb  : Name

-rw-r--r--.  root root 2.4M Feb  : Basenames

-rw-r--r--.  root root  16K Feb  : Group

-rw-r--r--.  root root 200K Feb  : Requirename

-rw-r--r--.  root root 1.5M Feb  : Providename

-rw-r--r--.  root root 1.1M Feb  : Dirnames

-rw-r--r--.  root root  12K Feb  : Installtid

-rw-r--r--.  root root  40K Feb  : Sigmd5

-rw-r--r--.  root root  52K Feb  : Sha1header

-rw-r--r--.  root root  35M Feb  : Packages

-rw-r--r--   root root 1.3M Feb  : __db.

-rw-r--r--   root root 104K Feb  : __db.

-rw-r--r--   root root 432K Feb  : __db.

[root@thatsit rpm]# rm -f __db*

[root@thatsit rpm]# rpm --rebuilddb

[root@thatsit rpm]# yum clean all

Loaded plugins: fastestmirror

Cleaning repos: base epel extras updates

Cleaning up everything

Cleaning up list of fastest mirrors

[root@thatsit rpm]# yum makecache

Loaded plugins: fastestmirror

base                                                         | 3.6 kB  ::

epel/x86_64/metalink                                         | 5.7 kB  ::

epel                                                         | 4.3 kB  ::

extras                                                       | 3.4 kB  ::

updates                                                      | 3.4 kB  ::

(/): base//x86_64/group_gz                               |  kB  ::

(/): base//x86_64/primary_db                             | 5.3 MB  ::

(/): epel/x86_64/group_gz                                 |  kB  ::

(/): base//x86_64/filelists_db                           | 6.2 MB  ::

(/): extras//x86_64/filelists_db                         |  kB  ::

(/): extras//x86_64/prestodelta                          |   kB  ::

(/): extras//x86_64/primary_db                           |   kB  ::

(/): epel/x86_64/other_db                                 | 1.8 MB  ::

(/): epel/x86_64/primary_db                               | 3.9 MB  ::

(/): base//x86_64/other_db                              | 2.3 MB  ::

(/): extras//x86_64/other_db                            |  kB  ::

(/): updates//x86_64/prestodelta                        |  kB  ::

(/): updates//x86_64/filelists_db                       | 1.9 MB  ::

(/): epel/x86_64/updateinfo                              |  kB  ::

(/): updates//x86_64/primary_db                         | 3.1 MB  ::

(/): epel/x86_64/filelists_db                            | 6.4 MB  ::

(/): updates//x86_64/other_db                           |   MB  ::

Determining fastest mirrors

 * base: mirrors.aliyun.com

 * epel: mirrors.yun-idc.com

 * extras: mirrors.aliyun.com

 * updates: mirrors.aliyun.com

Metadata Cache Created

[root@thatsit rpm]#

故障原因:

(原文地址:http://serverfault.com/questions/616666/why-does-yum-index-get-corrupted)

In the general case, this happens when rpm (or yum) crashes when updating the rpmdb, which is a Berkeley DB key-value store, and very sensitive. When such a crash happens, the rpmdb is left in an inconsistent state and this error occurs. All of the other files in /var/lib/rpm contain the same information, though in a less efficient format, so the database is easily rebuilt.

Two notable bugs you may have seen on older CentOS systems can cause this. The big one, a "nasty and subtle race in shared mmap'ed page writeback" as it appears in the changelog, was quietly fixed in a kernel update in 2007. This one presented itself slightly differently than your report, though.

The one you might see from 2009 happened when PackageKit would kill yum at an inopportune time, and was also fixed. This would be more likely to affect desktop systems or servers with a GUI, though.

All of these bugs predate EL 6, and you should almost never see this occur on EL 6 or 7, nor should you see it if your EL 5 systems are up to date. (I have no idea about EL 4. If you have one, kill it before it spreads.) That said, anything that causes yum or rpm to die while working with the rpmdb could cause it. This includes what you're most likely to see these days, random cosmic rays flipping bits, or someone getting overzealous with kill -9.

In RHEL 7, yum traps more signals during the actual transaction run, and you'll see the message (shutdown inhibited). This should help prevent most situations in which someone or something interrupts the transaction and causes this problem.