"E: Could not get lock /var/lib/dpkg/lock-frontend": what is holding apt, and what to do
Fix "Could not get lock /var/lib/dpkg/lock-frontend" on Ubuntu and Debian: find the process holding it, wait safely, and repair an interrupted dpkg.
by OhSudo ·
You want to install something, and apt refuses:
$ sudo apt install htopE: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2481 (unattended-upgr)N: Be aware that removing the lock file is not a solution and may break your system.E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?Only one program may change the installed packages at a time, so apt and dpkg take a lock first. Something else holds it right now. Recent apt versions even tell you who: here, process 2481, unattended-upgr — Ubuntu’s automatic security updates, which typically run in the first minutes after a server boots.
Most of the time the fix is simply to wait. The rest of this guide is for when waiting doesn’t help.
TL;DR
ps -fp 2481 # who holds the lock (the PID from the message)sudo tail -f /var/log/unattended-upgrades/unattended-upgrades.log # watch automatic updates finishsudo dpkg --configure -a # only if apt says dpkg was interruptedDon’t delete the lock files. That’s what the N: line warns about.
1. See what holds the lock
Use the process number from the message:
ps -fp 2481If your apt is older and doesn’t print the process, ask for it:
sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/dpkg/lockps aux | grep -E '[a]pt|[d]pkg|[u]nattended'The usual owners:
| Process | What it is | What to do |
|---|---|---|
unattended-upgr |
Automatic security updates | Wait a few minutes (step 2) |
apt.systemd.daily |
The daily package list refresh | Wait, usually under a minute |
apt / apt-get / dpkg |
Another install, maybe in another terminal or SSH session | Finish or cancel it there |
packagekitd |
The desktop “Software Updater” | Close it, or let it finish |
cloud-init |
First-boot setup of a cloud server | cloud-init status --wait |
2. Wait for automatic updates
On a server that just booted, unattended-upgrades is the usual suspect. Watch it work:
sudo tail -f /var/log/unattended-upgrades/unattended-upgrades.logsudo tail -f /var/log/dpkg.logWhen the log stops moving and the process is gone, run your command again.
In scripts and provisioning (Ansible, cloud-init user data, CI), tell apt to wait for the lock instead of failing:
sudo apt-get -o DPkg::Lock::Timeout=300 install -y htopThe interactive apt command already waits by itself for a while (you see Waiting for cache lock: …); apt-get doesn’t, unless you ask.
3. Why deleting the lock file doesn’t help
Many answers online say sudo rm /var/lib/dpkg/lock*. Here’s what that really does: the file is not the lock. apt and dpkg place a lock on the file, and the kernel releases it automatically when the process ends — even if it crashed. A lock file without a running owner blocks nothing; you never need to delete it.
So when apt says the lock is held, a process really is running. Deleting the file lets a second apt run at the same time as the first one, and two programs writing the package database in parallel is exactly how you get a broken system.
4. “dpkg was interrupted”
If an install was killed halfway (the SSH connection dropped, the machine rebooted, someone used kill -9), apt now says:
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.Do exactly that — it finishes configuring the packages that were half installed:
sudo dpkg --configure -asudo apt --fix-broken install5. A process that really hangs
Sometimes the owner of the lock waits forever: an apt in a forgotten tmux session asking a question, or a download stuck on a broken mirror. Find its terminal and answer or cancel it there. If there’s no other way, stop it gently and repair:
sudo kill 2481 # SIGTERM: lets it clean upsudo dpkg --configure -a # finish whatever it left half doneAvoid kill -9 while dpkg is unpacking files — that’s how packages end up half installed.
Shell, we have a problem!
Similar, but different: on RHEL / Rocky / AlmaLinux, dnf says Waiting for process with pid 1234 to finish. — the same idea, usually dnf-automatic or packagekit, and it waits by itself. E: Unable to locate package htop isn’t a lock problem: run sudo apt update first, or check the package name. Once apt runs, see Unable to locate package and NO_PUBKEY. If an install was cut short, see dpkg was interrupted.
Found this useful? Share it.
Found a mistake? Let us know at contact@ohsudo.com.