DEV Community

Big Mazzy
Big Mazzy

Posted on

Fix Could Not Get Lock on Ubuntu 24.04: apt and dpkg

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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

  1. 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
Enter fullscreen mode Exit fullscreen mode
  1. Check the process named by apt. In this example, PID 2187 is the process to inspect.
ps -o pid,etime,cmd -p 2187
Enter fullscreen mode Exit fullscreen mode

The output shows the PID, elapsed time, and command:

    PID ELAPSED CMD
   2187   14:32 /usr/bin/python3 /usr/bin/unattended-upgrade
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The example identifies the holder as root and shows the same PID:

/var/lib/dpkg/lock-frontend: root 2187 F.... unattended-upgr
Enter fullscreen mode Exit fullscreen mode
  1. 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
Enter fullscreen mode Exit fullscreen mode

In this example, it returns when the PID exits:

# returns when PID 2187 exits
Enter fullscreen mode Exit fullscreen mode
  1. Retry the install after the wait command returns.
sudo apt install -y htop
Enter fullscreen mode Exit fullscreen mode

A successful install may include:

Setting up htop ...
Enter fullscreen mode Exit fullscreen mode

How to verify

Check dpkg’s status for the package:

dpkg -s htop | grep Status
Enter fullscreen mode Exit fullscreen mode

The expected status is:

Status: install ok installed
Enter fullscreen mode Exit fullscreen mode

Then check that apt can update its package lists cleanly:

sudo apt update
Enter fullscreen mode Exit fullscreen mode

For this example, the output includes:

Reading package lists... Done
Enter fullscreen mode Exit fullscreen mode

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)