Fix "Could not get lock /var/lib/dpkg/lock-frontend"

ps -o pid,etime,cmd -C apt,apt-get,dpkg,unattended-upgr,packagekitd
# wait until nothing is listed, then retry
sudo apt update

What the error means

Typical output:

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2841 (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?

Recent apt versions wait for the lock instead of failing immediately and print a countdown:

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2841 (unattended-upgr)... 12s

dpkg allows exactly one process to change the package database at a time. It enforces that with lock files: /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock for installs, /var/lib/apt/lists/lock for apt update and /var/cache/apt/archives/lock for downloads. The locks are kernel file locks (fcntl), so they disappear automatically when the holding process exits. A lock file that merely exists on disk is not a problem; the error means a live process really has it open.

Cause 1: automatic updates are running

This is the cause in the large majority of cases, especially right after boot. Ubuntu and Debian run apt-daily.service (refresh lists) and apt-daily-upgrade.service (unattended-upgrades) from systemd timers. The message names the process: unattended-upgr is the truncated name of unattended-upgrade.

systemctl status apt-daily.service apt-daily-upgrade.service
tail -f /var/log/unattended-upgrades/unattended-upgrades.log

Wait for it to finish. Killing unattended-upgrades in the middle of installing a kernel or libc update is exactly how people end up with "dpkg was interrupted". If you must stop it, ask it to stop cleanly; it finishes the current package first:

sudo systemctl stop apt-daily-upgrade.service

Cause 2: a graphical software tool is open

GNOME Software, the Ubuntu App Center, the "Software Updater" dialog, KDE Discover and Mint's Update Manager all use PackageKit or apt in the background. A pending update dialog can hold the lock indefinitely. Close the app or finish its update, then check:

ps -o pid,etime,cmd -C packagekitd,gnome-software,discover,mintUpdate

If packagekitd is idle but still holding the lock, restarting it is safe when no transaction is running:

sudo systemctl restart packagekit.service

Cause 3: another terminal or script is running apt

An apt upgrade waiting at a "Do you want to continue? [Y/n]" prompt in another terminal, tmux pane or SSH session holds the lock until you answer. So does a cloud-init or provisioning script on a freshly created VM. Find the exact process holding the lock:

sudo lsof /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/lib/apt/lists/lock
# or, if lsof is not installed
sudo fuser -v /var/lib/dpkg/lock-frontend

Example output:

COMMAND  PID USER FD   TYPE DEVICE SIZE/OFF   NODE NAME
apt     3172 root  4uW  REG  259,2        0 1310787 /var/lib/dpkg/lock-frontend

Switch to that session and let it complete. On cloud VMs, wait for provisioning with cloud-init status --wait before running apt in your own scripts.

Cause 4: a crashed or killed apt left dpkg half-configured

If no process holds the lock (lsof prints nothing) but apt still complains, a previous run died. The lock itself is gone, but dpkg may be in an inconsistent state. Repair it:

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

dpkg --configure -a finishes configuring every unpacked package, and apt -f install resolves anything left missing.

When (and how) to remove the lock files

Because the locks are released when the process exits, deleting the files is almost never needed. If you have confirmed with lsof that no process holds any of them and the error persists after a reboot, you can remove them and repair:

sudo lsof /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/lib/apt/lists/lock /var/cache/apt/archives/lock
# only if the command above printed nothing:
sudo rm /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock
sudo dpkg --configure -a

Never kill -9 a dpkg process that is unpacking files. If something is truly hung (no CPU, no log output for a long time), stop it with a normal sudo kill PID and then run sudo dpkg --configure -a.

Distro-specific notes

• Ubuntu 26.04 and 24.04: unattended-upgrades is enabled by default on desktop and server. Snap refreshes do not use the dpkg lock, so snapd is not the culprit here.
• Debian 13: unattended-upgrades is installed on many images but not always enabled on a desktop install. Check with systemctl list-timers 'apt*'.
• Linux Mint: mintUpdate runs automatic updates via its own systemd service (mintupdate-automation-upgrade) if you enabled them.
• Arch, Fedora, openSUSE have the same concept with different files: see pacman "unable to lock database". DNF waits for its own lock, and zypper reports "System management is locked by the application with pid ...".

How to prevent it

• After booting a machine that has been off for a while, give automatic updates a few minutes before running apt yourself.
• In scripts, use apt's built-in wait: sudo apt-get -o DPkg::Lock::Timeout=300 install -y PACKAGE waits up to five minutes for the lock instead of failing.
• If you prefer to update manually on a server, schedule the timers to a quiet time rather than disabling security updates. Timers are covered in the systemd basics guide.

Frequently asked questions