TL;DR: Identify the process holding apt’s lock, let it finish, then retry the install.
The problem
You run an apt install on Ubuntu 24.04, but apt stops with a “Could not get lock” error. This usually means another package operation is already using dpkg’s lock. The package manager is preventing two processes from changing the system at the same time.
In this example, the attempted install is:
sudo apt install -y htop
Apt reports:
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2187 (unattended-upgr)
N: Be aware that removing the lock file is not a solution and may break your system.
The key detail is the holder: process 2187, named unattended-upgr. The lock is doing its job. Don’t delete the lock file; doing so can leave package management in an inconsistent state.
Why it happens
Ubuntu may run unattended upgrades in the background. When that process is installing or updating packages, another apt command has to wait for access to the package database. This is common and does not by itself mean anything is broken.
The right response is to identify the process and check what it is doing. Here, the process is a real unattended upgrade, it has been running for fourteen minutes, and it is owned by root. Let it finish instead of interrupting it.
Process IDs and elapsed times in examples are placeholders: your system may show a different PID or duration. Use the PID named in your own apt error when checking and waiting.
Step-by-step fix
- Reproduce the lock message with the install command. Read the error and note the holder’s PID and process name.
sudo apt install -y htop
- Check the process named by apt. In this example, PID 2187 is the process to inspect.
ps -o pid,etime,cmd -p 2187
The output shows the PID, elapsed time, and command:
PID ELAPSED CMD
2187 14:32 /usr/bin/python3 /usr/bin/unattended-upgrade
This is an unattended upgrade, so give it time to complete. You can also check which process is using the frontend lock:
sudo fuser -v /var/lib/dpkg/lock-frontend
The example identifies the holder as root and shows the same PID:
/var/lib/dpkg/lock-frontend: root 2187 F.... unattended-upgr
- Wait for the process to exit. The tail command returns when PID 2187 is gone. Replace the example PID with the holder reported on your system.
sudo tail --pid=2187 -f /dev/null
In this example, it returns when the PID exits:
# returns when PID 2187 exits
- Retry the install after the wait command returns.
sudo apt install -y htop
A successful install may include:
Setting up htop ...
How to verify
Check dpkg’s status for the package:
dpkg -s htop | grep Status
The expected status is:
Status: install ok installed
Then check that apt can update its package lists cleanly:
sudo apt update
For this example, the output includes:
Reading package lists... Done
The package reports installed, and apt update runs clean. The lock was handled by waiting for its owner; nothing was killed or deleted.
Common mistakes
- Deleting the lock file: The error explicitly warns that removing it is not a solution and may break your system. The lock is managed by the package process using it.
- Killing the holder: An unattended upgrade may be actively changing packages. Check what the process is doing and let it exit before retrying apt.
- Guessing the PID: Use the PID from your own error message. The example’s PID and elapsed time are placeholders.
- Retrying immediately: If the upgrade is still running, the install may hit the same lock again. Wait for the holder to exit, then retry.
If you want a clean Ubuntu box to practice on, PowerVPS is a reasonable choice: https://powervps.net/?from=32
Watch more fixes on Server Lab: https://www.youtube.com/channel/UCov7rfWAnS4c2wF5E9V1Yag
Top comments (0)