Stop dnf from treating your rpm database as an afterthought

Technical Briefing | 8/29/2026

You probably think the rpm database is just a list of what’s installed on your server. Usually, it is. But when you start doing heavy automation or mirroring custom repositories, that sqlite backend starts showing its teeth. I have seen more than one production environment grind to a halt because a stray process left an exclusive lock on the database, turning every subsequent dnf update into a hanging mess.

Why the database gets cranky

Most of the time, dnf handles transaction locks gracefully. But if you are running automated scripts that poll for package updates while a human admin is mid-install, you are going to hit contention. The database uses BerkeleyDB or SQLite depending on your distro version, and both hate having multiple writers banging on them. If you suspect your local environment is corrupt or just plain sluggish, stop guessing and look at the physical lock state.

rm -f /var/lib/rpm/__db.* && rpm --rebuilddb

• The double underscore files are the primary suspects for ghost locks
• Rebuilding the database doesn’t fix logic errors in your repo metadata
• Always check /var/run/dnf.pid before assuming the database is corrupt

Don’t let scripts hang forever

If you have a cron job that checks for updates, it needs to be polite. Don’t just fire off dnf check-update and assume it will return. Wrap your automation in a check for the lockfile. It is better for a monitoring script to skip one run because of an active transaction than to stack up a dozen hung processes that keep the package manager locked for the rest of the afternoon.

Keep an eye on the actual size of your rpmdb directory. If it is ballooning into the hundreds of megabytes, you might have old transaction residue that is not being cleaned up by standard housekeeping. Purge the old headers occasionally, or you will eventually watch your install time go from seconds to minutes just waiting for a seek operation.