Fix “Another App Is Holding the yum Lock” on RHEL and Fedora

Search results still mention “another app is currently holding the yum lock,” but on RHEL 8 through RHEL 10 you are almost always running DNF4 through the yum or dnf command. The lock is not a single /var/run/yum.pid file anymore. DNF uses separate locks for metadata, downloads, and the RPM database.

The walkthrough below reproduces the modern messages on RHEL 10.2, shows how to find the holding process, and explains when it is safe to remove a stale *.pid file.

Quick reference

What DNF locks (DNF4 on RHEL 8–10)

DNF4 does not use one global yum lock for every operation. Common lock files on RHEL 10:

/var/run/dnf.pid appears in older documentation but was not created during testing on RHEL 10.2. Treat the cache and lib paths above as the source of truth on current DNF4 systems.

For DNF5 on newer Fedora releases, see the DNF4 vs DNF5 lock behavior section below. Do not assume the DNF4 paths above apply there.

Reproduce the lock on DNF4

Start a long metadata refresh in one session:

sudo dnf makecache -y

While that runs, open a second terminal and try another dnf command with immediate exit on lock:

sudo dnf --setopt=exit_on_lock=1 install bash -y

metadata already locked by 13708
  The application with PID 13708 is: dnf
    Memory :  85 M RSS (403 MB VSZ)
    Started: Sun 16 Aug 2026 08:25:16 AM IST - 00:02 ago
    State  : Sleeping

Exit code 200 means DNF refused to wait. The same message appears when you use the yum wrapper because yum on RHEL 8+ calls DNF4.

Without exit_on_lock, the second command usually waits instead of failing:

sudo dnf install bash -y

Waiting for process with pid 15980 to finish.
Nothing to do.
Complete!

That wait-then-continue behavior is normal. Only treat it as an incident when the PID never finishes.

RPMDB lock looks different

Metadata and RPMDB locks are separate. While one terminal runs dnf reinstall, a second terminal with exit_on_lock enabled can report the database lock:

sudo dnf --setopt=exit_on_lock=1 reinstall bash -y

RPMDB already locked by 14574
  The application with PID 14574 is: python3
    Memory :  40 M RSS (284 MB VSZ)
    Started: Sun 16 Aug 2026 08:26:34 AM IST - 00:07 ago
    State  : Sleeping

The holder may show as python3 because /usr/bin/dnf is a Python wrapper. Use the PID from the message, not only the process name.

Find which process holds the lock

Read the PID from the error block, or inspect the lock file while the command is still running:

cat /var/cache/dnf/metadata_lock.pid

16063

Confirm the process before you kill anything:

ps -p 16063 -o pid,cmd

PID CMD
  16063 /usr/bin/python3 -s /bin/dnf makecache -y

Typical holders include an interactive dnf install, dnf-automatic, packagekit, cockpit package updates, or configuration management running yum or dnf over SSH.

Fix it safely

Work through these steps in order.

1. Wait for the other transaction to finish

If the process is a legitimate install or makecache, let it complete. Forcing a lock while RPM is writing the database risks an inconsistent RPMDB.

2. Stop a stuck holder

If you have confirmed that the process is genuinely stuck rather than performing a slow download or RPM transaction, send it SIGTERM first:

sudo kill 16063

Use kill -9 only when a normal TERM signal does not clear the process. After the holder exits, DNF normally removes the *.pid file on its own.

3. Clear a stale lock file

Remove a lock file only when the PID inside it is not running:

ps -p 16063

If ps reports no such process, retry your dnf command first. DNF4 reclaims dead locks automatically in most cases.

If a *.pid file remains after the holder is gone, remove the specific file:

sudo rm -f /var/cache/dnf/metadata_lock.pid

Do not remove a DNF lock PID file while its recorded process is still running. The PID file is part of DNF4's process-lock coordination. Deleting it while the holder is alive can allow another DNF process to recreate the file and interfere with normal locking.

If the recorded PID no longer exists, DNF4 can normally reclaim the stale lock itself. Retry the command before deleting the file manually.

4. Reboot only as a last resort

Rebooting clears every user process and is reasonable on a stuck lab VM. On production, prefer identifying the holder with ps first.

Legacy yum3 message (RHEL 7 and older)

RHEL 7 and CentOS 7 used yum3 with a single PID file:

Another app is currently holding the yum lock; waiting for it to exit...
Existing lock /var/run/yum.pid: another copy is running as pid 9571.

On those releases:

cat /var/run/yum.pid

Map that PID to the running yum process:

ps -p 9571 -o pid,cmd

Wait for the listed yum process, or stop it if it is clearly stuck. Remove /var/run/yum.pid only when no yum process is running. After RHEL 7, migrate troubleshooting habits to the DNF4 paths in the table above.

DNF4 vs DNF5 lock behavior

DNF5 uses a newer libdnf5 locking implementation. Do not assume that DNF4 paths such as /var/cache/dnf/metadata_lock.pid or options such as exit_on_lock behave identically. Check the installed DNF5 version and its documentation before removing any lock-related file.

DNF5 lock reproduction was not run on the RHEL 10.2 lab used for this article because dnf5 is not installed there. For packaging differences between generations, see DNF4 vs DNF5.

Troubleshooting

References

• DNF lock implementation (DNF4)
• Managing software packages — RHEL 10
• DNF5 configuration options

Summary

“Another app is currently holding the yum lock” describes yum3 on older RHEL. On RHEL 8 through 10, yum and dnf share DNF4, which serializes work through metadata, download, and RPMDB lock files under /var/cache/dnf and /var/lib/dnf. A second command usually prints Waiting for process with pid … and blocks until the first job finishes.

When you need an immediate failure instead of waiting, use dnf --setopt=exit_on_lock=1. The error lists the holding PID—confirm it with ps before you kill anything. Remove metadata_lock.pid or rpmdb_lock.pid only when that PID is no longer running; DNF often clears dead locks without manual deletion.

On DNF5 systems, treat locking as a separate implementation: verify the installed version and follow DNF5-specific documentation rather than copying DNF4 PID-file paths from this page. For day-to-day package work after the lock clears, use the dnf command reference for install, upgrade, and repository options.