Repair an RPM database safely: “First informally: When a process _is_ so killed [sometimes due to a loss of power crash, sometimes due to a third party helper application dying without cleaning up lock state information in files at exit, sometimes due to an impatient admin], it may also leave some small corruption behind in the RPM ‘SleepyCat’ db based database. Usually the simple
rm -f /var/lib/rpm/__db*
will remove the files which hold lock state information (these files start with that distinctive ‘__’). As these lock state holding files are automatically re-created if missing, this is a safe approach.
It would be safest to clear these locks while still in single user mode; as a system is booting up, it is in single user mode before init can fire off any ‘child’ daemon processes. Checking, we can find:
bash-2.05b$ nl /etc/rc.d/rc.sysinit | grep rpm 556 rm -f /var/lib/rpm/__db* bash-2.05b$
That is, in the boot-scripts, recent Red Hat releases do exactly this (here at line 556 of /etc/rc.d/rc.sysinit). The safest approach which will do this for you, automatically, is to simply verify that a single user mode script indeed will do the cleanup at boot time when no other processes are running, and just reboot. [It is all right; that uptime record you were going for is less important than a clean RPM database — try the reboot method.]
But sometimes there are still problems. If the simply removal of the ‘__*’ files does not clear up the problem, it is also possible that other damage exists, such corrupted linked lists, and is separately present. Proceed carefully — take a backup FIRST, before trying to have rpm repair the database.
It is also _usually_ safe to rebuild these lists, thus:
rpm -vv –rebuilddb”