Could Not Get Lock /var/lib/dpkg/lock-frontend: Fix

"Could not get lock /var/lib/dpkg/lock-frontend" means another apt or dpkg process is running. Wait for it or stop it cleanly. Never just delete the lock file.

You SSH into a fresh Ubuntu server, type sudo apt install nginx, and get E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2143 (unattended-upgr). It's one of the most searched Linux errors, and the top answer on many forums is to rm the lock files. That advice can corrupt your package database. I hit this constantly when provisioning new VPS servers and in CI jobs that run apt right after boot, so here's the safe way to handle it, in the order I do it.

Key takeaways

• The lock is doing its job: only one program may change installed packages at a time. Something else is installing or updating right now.
• On a new or freshly booted server it's almost always unattended-upgrades installing security updates. Waiting a few minutes is the fix.
• Find the holder first with sudo fuser -v /var/lib/dpkg/lock-frontend or sudo lsof /var/lib/dpkg/lock-frontend.
• Don't delete the lock files. Two dpkg processes writing at once can leave packages half-installed.
• In scripts, wait instead of failing: apt-get -o DPkg::Lock::Timeout=300 waits up to five minutes for the lock.

What is the dpkg lock?

Ubuntu and Debian install software with dpkg, and apt sits on top of it. To stop two installs from writing the package database at the same time, they take locks on a few files:

• /var/lib/dpkg/lock-frontend: taken by apt, apt-get and other front ends for the whole operation.
• /var/lib/dpkg/lock: taken by dpkg itself while it changes packages.
• /var/lib/apt/lists/lock: held during apt update.
• /var/cache/apt/archives/lock: held while downloading packages.

The lock files themselves always exist; what matters is whether a running process holds a lock on them. That's why deleting the file doesn't "unlock" anything safely: it just lets a second process in while the first is still working.

Step 1: Find out who holds the lock

Modern apt tells you the PID in the error message. If it doesn't, ask the kernel:

sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock
# or
sudo lsof /var/lib/dpkg/lock-frontend
# then see what it is and how long it has been running
ps -o pid,etime,cmd -p 2143

You'll usually see one of these:

• unattended-upgrade: Ubuntu's automatic security updates, started by the apt-daily-upgrade timer and on first boot.
• apt or apt-get from another SSH session, a tmux window you forgot, or a config management run.
• packagekitd or the Software Updater on Ubuntu Desktop.
• cloud-init on a brand-new cloud server, still installing the packages from your provider's user data.

If nothing holds it but apt still complains, a previous run was killed. Skip to Step 4.

Step 2: Usually, just wait

If the holder is unattended-upgrade, cloud-init or a legitimate apt run, let it finish. On a new server that's typically a few minutes. You can watch it:

tail -f /var/log/unattended-upgrades/unattended-upgrades.log
# wait until nothing holds the lock, then continue
while sudo fuser /var/lib/dpkg/lock-frontend >/dev/null 2>&1; do sleep 5; done

On a brand-new cloud VM, cloud-init status --wait blocks until first-boot setup is done, which is a cleaner wait than polling the lock.

Step 3: If it's really stuck, stop it cleanly

Check the elapsed time from ps -o etime. If an apt process has been running for a very long time with no log output, it may be waiting on an interactive prompt in a session nobody is watching (a config file question in a lost tmux window is the usual culprit). Find and finish that session if you can. If not, stop the process politely first:

sudo systemctl stop unattended-upgrades apt-daily-upgrade.service apt-daily.service
sudo kill 2143          # SIGTERM first; only use kill -9 if it ignores this

Then move straight to Step 4, because an interrupted install leaves dpkg in an unfinished state.

Step 4: Repair dpkg after an interrupted install

If you see E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem, or a previous apt run was killed, finish the pending work:

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

dpkg --configure -a configures every package that was unpacked but not set up, and apt-get -f install fixes broken dependencies. If dpkg --configure -a itself fails, read its error: a full disk is a common reason a package can't finish, and my "No space left on device" guide covers clearing space safely.

What about deleting the lock files?

You'll see this "fix" everywhere:

# don't do this while anything holds the lock
sudo rm /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock

If a process is still running, removing the files lets a second apt start alongside it, and both write to /var/lib/dpkg/status. That's how you end up with half-configured packages and a broken kernel update. It's only harmless when nothing holds the lock, and in that case apt wouldn't have complained. Use fuser to prove nothing is running, then run dpkg --configure -a instead.

How to stop this from breaking your scripts and CI

Provisioning scripts, Ansible runs and GitHub Actions jobs that SSH into a fresh server often fail on the very first apt line, because the server is still applying its first-boot updates. Make them wait instead:

sudo cloud-init status --wait || true
sudo apt-get -o DPkg::Lock::Timeout=300 update
sudo apt-get -o DPkg::Lock::Timeout=300 install -y nginx

DPkg::Lock::Timeout tells apt to wait up to that many seconds for the lock instead of failing at once. Don't disable unattended-upgrades to avoid the lock; those are your security patches. If timing matters, move them with the apt-daily-upgrade.timer instead. My Ubuntu 24.04 hardening checklist explains why automatic security updates belong on every server, and my GitHub Actions deploy guide shows a pipeline that doesn't touch apt at deploy time at all.

Frequently asked questions

How long does unattended-upgrades take?

Usually a few minutes, longer on a new server with many pending updates or a slow mirror. Watch /var/log/unattended-upgrades/unattended-upgrades.log to see that it's still making progress before you decide it's stuck.

Is it safe to kill unattended-upgrades?

Stopping it with a normal kill or systemctl stop is usually fine, as long as you run sudo dpkg --configure -a afterwards to finish any package it was in the middle of. Avoid kill -9 unless it refuses to stop.

Why do I get this error right after creating a new server?

New cloud servers run cloud-init and an initial round of security updates on first boot, and both hold the dpkg lock. Wait with cloud-init status --wait or retry after a few minutes.

What's the difference between lock and lock-frontend?

lock-frontend is held by apt and other front ends for the whole operation, while lock is held by dpkg itself while it changes packages. The fix is the same for both: find the process holding it.

Can I make apt wait for the lock automatically?

Yes. Pass -o DPkg::Lock::Timeout=300 to apt-get and it waits up to 300 seconds for the lock to be released. This is the right fix for scripts and CI jobs.

Need a hand with your server?

I set up and maintain Ubuntu servers: safe automatic updates, hardening, backups and monitoring, so a stuck package manager never takes your site down. See my Linux system administration services, or contact me with the full error and I'll help you fix it.