Fixing "Could not get lock" on apt/dpkg

2026-06-05 Reading time: About 10 min Difficulty: Intermediate

What does "Could not get lock" mean?

Conclusion: apt and dpkg are designed to run one at a time, guarded by lock files. This error means another process already holds the lock. Most often it is a background automatic update.

When you run something like apt install, you may hit this and stop:

$ sudo apt install nginx
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (apt)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

apt and dpkg can only run one instance at a time so they never corrupt the package database. That mutual exclusion is enforced with lock files: while one operation is in progress, any other command fails to acquire the lock and prints this error.

So nothing is "broken" - you were simply turned away because something else is in line first. In most cases, waiting a few minutes clears it. Rushing to delete the lock files is the single most dangerous reaction; the right first move is to see who holds the lock.

Which lock files does apt use?

Conclusion: There is not one lock but four. lock-frontend covers the whole frontend, lock the dpkg DB, archives/lock downloads, and lists/lock apt update. The path in the error tells you which stage stalled.

apt uses separate lock files for different stages. The path shown in the error tells you where it is stuck.

Modern apt (Ubuntu 18.04+) acquires lock-frontend first. If the error names lock-frontend, another apt / dpkg is holding the whole frontend.

Why can't the lock be acquired?

Conclusion: 90% of the time another apt-family process is running. It comes down to automatic updates, the GUI updater, a double-launch, or a previous crash - and automatic updates dominate.

The cause almost always falls into one of four patterns.

The first is by far the most common. Ubuntu runs apt-daily.service / apt-daily-upgrade.service on timers that fire shortly after boot and at randomized times, running apt update or unattended-upgrades in the background. Running apt install right after provisioning a server very often collides with these.

How do I find the process holding the lock?

Conclusion: Start with lsof or fuser to find which process has the lock file open. Modern apt also prints the PID in the error. Once you know what it is (apt / unattended-upgrades / etc.), the fix follows.

The first step is identifying who holds the lock. Deleting or killing comes only after that.

Modern apt prints held by process 1234 (apt) in the error. When it does not, use lsof.

$ sudo lsof /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock

COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
unattended 1234 root    5uW  REG    8,1        0  ... /var/lib/dpkg/lock-frontend

The W in the FD column means a write lock. Here unattended-upgrades holds it. If you do not have lsof, fuser works too.

$ sudo fuser -v /var/lib/dpkg/lock-frontend

Listing apt-family processes gives you the broader picture.

$ ps aux | grep -iE 'apt|dpkg|unattended' | grep -v grep

root  1234  ... /usr/bin/python3 /usr/bin/unattended-upgrade

If the holder is unattended-upgrade or apt-daily, an automatic update is running - just wait. If it is a manual double-launch of apt, finish the other session.

What if an automatic update is the cause?

Conclusion: Automatic updates (unattended-upgrades) finish in a few minutes, so waiting is best. Killing it leaves the update half-applied. Stop the service properly only if you truly cannot wait.

If lsof shows unattended-upgrade, that process is not harmful - it is applying security updates. It usually finishes in 1-5 minutes and releases the lock on its own.

To watch progress, check its status.

$ systemctl status unattended-upgrades
$ sudo journalctl -u unattended-upgrades -f

If it never finishes, or you have a real reason to stop it, do not kill -9 it - stop it cleanly as a service.

$ sudo systemctl stop unattended-upgrades

When is it safe to delete the lock files?

Conclusion: Deleting lock files is a last resort, allowed only after you confirm with lsof that no process holds them. Deleting while a process is running corrupts the dpkg database.

You will see advice to "just delete the lock files." That is only valid as a final step after confirming no apt / dpkg is running. Delete while a process is alive and two apt instances rewrite the database at once, breaking package management.

First, confirm no process has the locks open.

# No output means no process is holding them
$ sudo lsof /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock
$ ps aux | grep -iE 'apt|dpkg|unattended' | grep -v grep

Only when both are empty (no apt / dpkg running at all) may you remove the stale lock files.

$ sudo rm /var/lib/dpkg/lock-frontend
$ sudo rm /var/lib/dpkg/lock
$ sudo rm /var/cache/apt/archives/lock
$ sudo rm /var/lib/apt/lists/lock

How do I recover an interrupted dpkg?

Conclusion: After releasing the lock, run sudo dpkg --configure -a. It finishes configuring packages left "unpacked but not configured", then apt-get install -f / apt update restores consistency.

Even after the lock is released, a previous apt that died mid-operation may leave packages half-installed. dpkg --configure -a normalizes that.

$ sudo dpkg --configure -a

This re-configures every package that was unpacked but not yet configured. Then repair any broken dependencies and refresh the lists.

$ sudo apt-get install -f
$ sudo apt update

apt-get install -f (--fix-broken) repairs packages with broken dependencies. Once this passes, apt install works normally again.

sudo dpkg --configure -a
sudo apt-get install -f
sudo apt update

How do I prevent it from recurring?

Conclusion: In scripts and automation, set DPkg::Lock::Timeout so apt waits for the lock instead of failing instantly. It retries for the given number of seconds. Standard in apt 2.x and later.

For manual work, "wait for the automatic update to finish" is enough. But in CI or provisioning scripts, colliding with an automatic update and failing is painful. apt 2.x can wait a set number of seconds instead of erroring out immediately.

# Wait up to 60 seconds for the lock
$ sudo apt-get -o DPkg::Lock::Timeout=60 install nginx

# Wait indefinitely (-1)
$ sudo apt-get -o DPkg::Lock::Timeout=-1 install nginx

For automation that runs apt install right after a server boots, adding DPkg::Lock::Timeout alone prevents most lock collisions with the boot-time apt-daily.

Summary: checklist

Conclusion: The basic order is "identify -> wait -> recover." Deleting lock files is a last resort, only once you confirm no process holds them. Follow that order and you fix it without breaking dpkg.

• [ ] Identified the holder via the PID in the error or lsof?
• [ ] If it is unattended-upgrade / apt-daily, waited a few minutes?
• [ ] Checked that the GUI "Software Updater" / packagekit is not running?
• [ ] If killing, avoided kill -9 and used systemctl stop or a normal kill?
• [ ] Confirmed with lsof and ps that nothing is running before deleting locks?
• [ ] If interrupted, recovered with dpkg --configure -a -> apt-get install -f -> apt update?
• [ ] Set DPkg::Lock::Timeout in automation?