If you are working with Linux environment, you must have once in your carrier ended up with this error "another app is currently holding the yum lock" or "Existing lock /var/run/yum.pid: another copy is running as pid XXX" while executing yum. I mostly use RHEL/CentOS environment in my work life so will only talk about this distribution. But i can say with some confidence that the same steps should work with SuSE environment.
Most common causes for "another app is currently holding the yum lock" error
Here is a snippet of the error you may face while using yum or dnf:
# yum install sntp.x86_64 Loaded plugins: fastestmirror Existing lock /var/run/yum.pid: another copy is running as pid 9571. Another app is currently holding the yum lock; waiting for it to exit... The other application is: yum Memory : 86 M RSS (408 MB VSZ) Started: Thu Feb 6 20:44:53 2020 - 00:35 ago State : Sleeping, pid: 9571 Another app is currently holding the yum lock; waiting for it to exit... The other application is: yum Memory : 86 M RSS (408 MB VSZ) Started: Thu Feb 6 20:44:53 2020 - 00:37 ago State : Sleeping, pid: 9571
1. Automatic System Updates
To see if automatic updates are running in the background, you can look for processes related to
ps aux | grep 'yum'
ps aux | grep 'dnf'
2. Another Terminal Session
Ensure no other terminal sessions are running
# This will show if any other terminal session is using yum or dnf ps aux | grep 'yum'
ps aux | grep 'dnf'
3. Background Processes
Background processes might also hold the lock.
# This will show all processes involving yum or dnf ps aux | grep 'yum'
ps aux | grep 'dnf'
4. Zombie Process
Check if there are any zombie processes related to
# Check for zombie processes ps aux | grep 'Z'
This command will help you identify zombie processes, and then you can look if any of them are related to
For now let's see how you can overcome and fix "
another app is currently holding the yum lock" error. For the sake of this article I have manually simulated this error by running two parallel yum sessions on different terminals using RHEL/CentOS 7.
Solution 1: Wait for the Other Process to Complete
What it means: If another process is using the package manager (like automatic updates or another terminal session running
dnf), you could simply wait for that process to complete.
When to use it: This is a safer approach if you suspect that an automatic update or a legitimate
dnf process is currently running.
How it helps: It prevents potential conflicts or corruptions that might occur due to forcefully stopping a package management operation.
Solution 2. Identify and Kill the Process
Find the process ID (PID) of the
# cat /var/run/yum.pid 9571
To get more details you can use "ps -ef" as shown below
# ps -ef | grep 9571 root 9571 9498 4 20:44 pts/1 00:00:03 /usr/bin/python /usr/bin/yum install nagios-plugins-ntp.x86_64 root 9576 9477 0 20:46 pts/0 00:00:00 grep --color=auto 9571
So either you can wait for that process to complete or you can manually kill the process
# kill -9 9571
When to use it: When a process seems to be stuck or you are certain that terminating a specific process won’t harm the system.
Solution 3: Disable Automatic Updates in PackageKit
PackageKit can also be one of the culprits when you encounter the "another app is currently holding the yum lock" or a similar message in the context of DNF. PackageKit is a daemon that runs in the background and facilitates package management tasks such as installing, updating, and removing packages, aiming to provide a common interface for different package management tools across various distributions.
To permanently stop and disabling
PackageKit On CentOS/RHEL 7
# systemctl disable packagekit --now
To permanently Disabling
PackageKit On CentOS/RHEL 6 open below file and change
# vi /etc/yum/pluginconf.d/refresh-packagekit.conf enabled=0
Solution 4. Remove the Lock File
What it means: Manually deleting the file that the package manager uses to prevent concurrent operations.
When to use it: When you are certain that no
dnf processes are running, but the lock file is still present.
How to do it:
rm /var/run/yum.pid # or /var/run/dnf.pid
How it helps: It removes the lock that is preventing new package management operations, but it might cause inconsistencies if done carelessly.
Note: Be very careful when removing lock files, as it might cause inconsistencies if a process is actually using it.
Solution 5: Reboot the System
What it means: Restarting the entire system.
When to use it: When other methods fail, and you are facing issues like stale or zombie processes.
How it helps: A reboot will clear all running processes, and the system will start afresh, resolving any lock issues.
Bonus Tip: Use DNF instead of YUM
With CentOS/RHEL 7 and higher release, we have an alternate tool "
dnf" as a package manager. You must understand that there are major improvements with dnf and should not be considered same as yum.
So if your yum is throwing "
another app is currently holding the yum lock" then you can use dnf as an alternative. But this would require dnf rpm to be installed in your environment which by default will not be installed in RHEL/CentOS 7.
# yum install dnf
Next in future you can completely switch to
dnf but for some reason if someone in your team still uses yum and you get "
another app is currently holding the yum lock" error then you can start using
dnf package manager.
As you see below, both can run in parallel:
# ps -ef | egrep yum\|dnf | grep -v grep root 9626 9498 2 20:59 pts/1 00:00:03 /usr/bin/python /usr/bin/yum install nagios-plugins-ntp.x86_64 root 9628 9477 36 21:00 pts/0 00:00:35 /usr/bin/python2 /usr/bin/dnf install sntp.x86_64
YUM vs DNF
Since we are discussing on this topic, Let us do some brief comparison between YUM and DNF
With RHEL/CentOS 8 they have introduced YUMv4
# rpm -q yum
Although this will internally be linked with DNFv3.
# ls -l /usr/bin/yum
lrwxrwxrwx 1 root root 5 Dec 19 21:13 /usr/bin/yum -> dnf-3
YUMv4 has the following advantages over the previous YUMv3 used on Red Hat Enterprise Linux 7:
- Increased performance
- New features available, most significantly the support for managing the modular content
- Well-designed stable API for integration with tooling
There are various other changes in DNF compared to YUM
dnf you will never face "
another app is currently holding the yum lock" as
dnf does not rely on any such PID file and multiple instances of
dnf can be executed in parallel.
Although if you choose to use YUMv4 you may still get "
Waiting for process with pid XXXX to finish." if another yum process is running but the handling with YUMv4 is far more better than YUMv3
For more details on yum and dnf with RHEL 8
Overview on YUM and DNF in Red Hat
Lastly I hope the steps from the article to fix another app is currently holding the yum lock error on RHEL/CentOS Linux was helpful.