🚨 Linux Error: rpmdb: BDB0113 Thread/process failed — Cause, Fix, and Troubleshooting Guide

Summary

rpmdb: BDB0113 Thread/process ... failed means RPM’s Berkeley DB backend in /var/lib/rpm is corrupt or holding stale lock/environment state. It usually appears as error: db5 error(11) or error: cannot open Packages database and makes rpm, yum, or dnf hang or abort. This is a database-integrity problem, not a missing-package problem. On RHEL 8/9 and Rocky the fix is almost always a clean rebuild of the RPM DB after a backup.

Common Symptoms

• rpm -qa, yum, or dnf hangs, then prints rpmdb: BDB0113 Thread/process ... failed.
• Companion errors: error: db5 error(11) from dbenv->failchk, error: cannot open Packages index using db5, error: cannot open Packages database in /var/lib/rpm.
• Package operations were interrupted (power loss, OOM kill, kill -9 on yum, a full disk mid-transaction).
• Stale lock files like /var/lib/rpm/__db.001 linger after the process died.

Most Likely Causes of the ‘rpmdb: BDB0113 Thread/process … failed’ Error

The exact phrase rpmdb: BDB0113 Thread/process ... failed almost always traces to one of these, most common first:

1. An interrupted transaction — yum/dnf was killed, the box lost power, or the OOM killer reaped it mid-write, leaving the Berkeley DB environment inconsistent.
2. Stale BDB environment/lock files — __db.00x files reference a dead process; the new process cannot attach to the shared environment.
3. Disk full or read-only / during a transaction, truncating an index write.
4. A copied or restored filesystem where /var/lib/rpm was rsynced live, capturing a half-written DB.
5. Mixed glibc/db versions after an in-place major upgrade left an old-format DB.

Quick Triage

# Confirm the error and that rpm itself is the failing layer
rpm -qa 2>&1 | head
ls -l /var/lib/rpm/
df -h /var
mount | grep ' /var\| / '
# Any process still holding the DB open?
sudo fuser -v /var/lib/rpm/Packages 2>/dev/null
sudo lsof /var/lib/rpm/Packages 2>/dev/null

If rpm -qa hangs or prints BDB0113 and no live process is holding Packages, you have stale state to clear.

Diagnostic Commands

# List the DB files and their sizes/timestamps
ls -l /var/lib/rpm/

Look for __db.001, __db.002, __db.003 (the shared environment) and a Packages file. Recent __db.00x with no owning process are stale locks.

# Is anything actively using the DB right now?
sudo fuser -v /var/lib/rpm/Packages
sudo lsof +D /var/lib/rpm

Never rebuild while a real yum/dnf/packagekit process holds it — stop that first.

# Verify integrity of the Packages database (db_verify from libdb-utils)
sudo /usr/lib/rpm/rpmdb_verify /var/lib/rpm/Packages 2>&1 | tail
# or, if installed:
sudo db_verify /var/lib/rpm/Packages

A clean DB returns silently; corruption prints page/checksum errors.

# Check for a full or read-only filesystem that caused the corruption
df -h /var
mount | grep -E ' / | /var '

# After recovery, cross-check transaction history
sudo dnf history list | head     # RHEL 8/9, Rocky
sudo yum history list | head     # RHEL 7

Fix / Remediation

Work through these in order. Steps 1-2 are non-destructive.

1. Stop competing package tooling. Ensure no yum, dnf, packagekit, or unattended job is running:

   sudo systemctl stop packagekit 2>/dev/null
   sudo pkill -f 'yum|dnf|packagekit' 2>/dev/null; sleep 2
   sudo fuser -v /var/lib/rpm/Packages

2. Free space / remount read-write if that was the cause (see No space left on device and Read-only file system). A rebuild on a full /var will just re-corrupt.

3. Back up the entire RPM DB before touching it.

   Warning: Everything below rewrites /var/lib/rpm. Take this backup first — it is your only rollback.

   sudo tar czf /root/rpmdb-backup-$(date +%F-%H%M).tar.gz /var/lib/rpm

4. Remove only the stale Berkeley DB environment files (the __db.00x locks), then retry. This clears stale locks without discarding the index:

   Warning: Removing files under /var/lib/rpm is destructive; confirm the backup exists.

   sudo rm -f /var/lib/rpm/__db.00*
   sudo rpm --quiet -qa && echo "recovered"

   If rpm -qa now works, you are done — skip to Validation.

5. Rebuild the database if removing locks did not help:

   sudo rm -f /var/lib/rpm/__db.00*
   sudo rpm --rebuilddb -vv

   --rebuilddb regenerates the indexes from the Packages file. This is the standard, supported repair.

6. If --rebuilddb also fails, recover the Berkeley DB out-of-band, then rebuild:

   Warning: Only do this when a normal rebuild fails; work on a copy.

   cd /var/lib/rpm
   sudo /usr/lib/rpm/rpmdb_recover
   sudo rm -f /var/lib/rpm/__db.00*
   sudo rpm --rebuilddb

7. On RHEL 9 / recent Fedora the backend is sqlite, not BDB. Confirm and convert if a legacy BDB was carried in:

   rpm -E '%{_db_backend}'
   sudo rpmdb --rebuilddb   # rewrites into the configured backend

Validation

# The DB opens cleanly and lists packages
sudo rpm -qa | wc -l
# No stale env files remain
ls -l /var/lib/rpm/__db.00* 2>/dev/null || echo "no stale locks"
# A real transaction dry-run succeeds
sudo dnf check-update >/dev/null; echo "exit=$?"
sudo dnf install -y --downloadonly --setopt=tsflags= tree 2>&1 | tail -1

A non-hanging rpm -qa with a plausible package count and a clean dnf check-update confirm recovery.

Prevention

• Back up /var/lib/rpm on a schedule (nightly tar), and always before major upgrades.
• Never kill -9 yum/dnf; let transactions finish or use dnf history undo.
• Monitor free space on / and /var and alert well before 100% so a transaction can never run out of space.
• When cloning or backing up hosts, snapshot the filesystem or stop package tooling first so /var/lib/rpm is captured consistently — never rsync it live.
• Manage packages through config management (Ansible dnf, etc.) so operations are serialized and idempotent instead of ad-hoc.

Related Errors

• Linux Error: No space left on device
• Linux Error: Read-only file system
• Linux Error: Failed to download metadata for repo
• Linux Error: Operation not permitted
• Linux Error: Permission denied

Final Notes

rpmdb: BDB0113 Thread/process ... failed is a corruption/lock problem in /var/lib/rpm, usually from an interrupted transaction or a full disk. Back up the DB, clear the stale __db.00x locks, and rpm --rebuilddb; only escalate to rpmdb_recover if that fails. Fix the underlying cause — space, power, or a live-copied DB — or it will recur.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.