Last modified: 2026 March 26

Overview

This document describes package manager lock files and how to resolve cPanel & WHM upgrade blockers.

Package managers

Package managers let you install, update, and remove software on your system. They use repositories to manage the packages that you install or uninstall. They also handle any dependencies for packages that you wish to use. For more information, read our Package Manager Basics documentation.

Features and scripts that use the package manager

Many cPanel & WHM features and scripts use the system package manager. They respect package manager locks and may fail or wait if a lock is active. The following features and scripts use the package manager:

• cPanel upgrades — Both automatic and manual upgrades with the /scripts/upcp script use the package manager. For more information, read our How to Update Your System documentation.
• EasyApache 4 — Installs or removes PHP versions and modules. For more information, read our About EasyApache 4 documentation.
• The check_cpanel_pkgs Script — The /scripts/check_cpanel_pkgs --fix command that shows any package problems and automatically corrects them.
• AutoSSL — May install packages for provider plugins.
• cPanel plugin installations — Any RPM or DEB based plugins.
• Account transfer — Restoring accounts may install required packages.

Package manager lock files

When a package manager starts an install, update, or remove operation, it creates a lock file. The lock prevents other package management processes from running at the same time. This avoids corrupted package data, inconsistent package states, and failed installations.

Lock file problems

The system creates and removes package manager lock files automatically. You do not need to manage them.

In some cases, the system leaves a lock file behind after an error, such as a crash, reboot, or terminated process. When this occurs, the package manager cannot run new operations. A stale lock file blocks the package manager from installing or updating packages.

The system can leave package manager lock file after an interrupted operation, such as:

• A yum update crashes mid-transaction.
• The server reboots while apt is running.
• A process hangs and does not complete.
• An administrator terminates a package operation with Ctrl+C or kill -9.

In these cases, the lock file remains even though the operation is no longer running. The package manager cannot start new operations until you remove the lock. Any task that uses the system package manager, such as yum install or apt update, must wait for the lock to clear.

Lock file locations

Before starting a new package manager process, the system checks for any active package manager lock files. The following table lists the exact files cPanel checks on each operating system:

Package manager locks and upgrades

In cPanel & WHM version 136 and later, the upgrade system checks for active package manager locks before starting any upgrade. The system runs a pre-upgrade blocker that retries up to four times, waiting 30 seconds between each attempt. If a lock remains after approximately two minutes, the system blocks the upgrade.

In practice, this means that if yum, dnf, or apt is running when cPanel upgrade starts, the upgrade waits a few minutes for the package operation to finish. If the process does not complete, the upgrade stops. In this case, the system displays the following message:

Cannot upgrade because the package manager has active locks: /var/lib/rpm/.rpm.lock, /var/run/yum.pid

Resolve upgrade lock file blockers

To resolve package manager lock file upgrade blockers, perform the following actions:

1. Use fuser to check which processes hold package manager locks. If fuser returns process ID(s), a process is running.

   • For RHEL/Alma/Rocky, run the following command:

     fuser /var/lib/rpm/.rpm.lock /var/run/yum.pid /var/lib/dnf/rpmdb_lock.pid 2>/dev/null

   • For Ubuntu, run the following command:

     fuser /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null

2. Use the following command to identify the process:

   ps -p <PID> -o pid,user,start,cmd

   Note:

   If a package operation is running (for example, yum update, dnf install, or apt upgrade), allow it to complete. Do not stop it.

3. To determine whether the process is stuck, run the following command and watch for ten seconds:

   strace -p <PID> -e trace=write -c

   • If the process is unresponsive (no I/O for minutes), run the following command to terminate it:

     kill <PID>

   • Wait a few seconds. If the process does not stop, run:

     kill -9 <PID>

4. If no package operations are running, clear stale locks and repair the package manager.

   • For RHEL/Alma/Rocky, run the following commands:

     1 2 3 4

     rm -f /var/run/yum.pid rm -f /var/lib/dnf/rpmdb_lock.pid rpm --rebuilddb dnf clean all

   • For Ubuntu, run the following commands:

     1 2 3 4 5 6

     rm -f /var/lib/dpkg/lock rm -f /var/lib/dpkg/lock-frontend rm -f /var/lib/apt/lists/lock rm -f /var/cache/apt/archives/lock dpkg --configure -a apt-get clean

   Note:

   The rpm --rebuilddb or dpkg --configure -a commands repair the package database after an interrupted operation. If a package operation stops mid-transaction, it can leave the database incomplete. Skipping this step can cause errors (for example, rpmdb: Thread died) or break dependency resolution.

5. To retry cPanel upgrade, run the following command:

   /scripts/upcp --force