Fix 'Could not get lock /var/lib/dpkg/lock-frontend' on a VPS

You type sudo apt update on your VPS, expecting a quick refresh, and instead get a wall of text ending in "Could not get lock /var/lib/dpkg/lock-frontend". Nothing installs, nothing updates, and it's tempting to just delete the lock file and move on. Please don't. This guide shows you what's actually holding the lock, how to wait it out safely, and the one situation where it's right to step in.

What the error looks like

On Ubuntu and Debian you'll see one of these variants:

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1423 (unattended-upgr)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

E: Could not get lock /var/lib/apt/lists/lock
E: Could not get lock /var/cache/apt/archives/lock
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.

They look similar but they point to different causes, so read the last line carefully.

Why it happens

apt and dpkg use lock files so two package operations never edit the same database at once. If the lock is held, either another process is legitimately working, or a previous one died and left things half-finished.

Step 1: Find out who holds the lock

Don't guess. Ask the system:

sudo lsof /var/lib/dpkg/lock-frontend
ps aux | grep -E 'apt|dpkg|unattended' | grep -v grep

If lsof isn't installed, sudo fuser -v /var/lib/dpkg/lock-frontend does the same job. You'll get a PID and a process name, and that tells you which of the cases above you're in.

Step 2: If it's unattended-upgrades, wait

This is the most common case on a fresh SkyServer VPS. Ubuntu starts security updates shortly after boot, and they can take a few minutes, longer on a small plan with slow disk. Watch the progress instead of killing it:

sudo tail -f /var/log/unattended-upgrades/unattended-upgrades.log

When the log goes quiet and the process disappears from ps, run your command again. Killing it mid-upgrade is the fastest way to end up with the "dpkg was interrupted" error below.

If you'd rather block until the lock is free, this one-liner works well in scripts:

while sudo fuser /var/lib/dpkg/lock-frontend >/dev/null 2>&1; do sleep 5; done
sudo apt install -y nginx

Newer apt versions also accept -o DPkg::Lock::Timeout=120, which makes apt wait up to two minutes by itself.

Step 3: If another session is running apt, let it finish

Check for a second SSH window, a half-forgotten tmux session, a cron job, or a CI deploy. If a script is installing packages, let it complete. Two package managers fighting over the same database is how corruption starts.

Step 4: Fix "dpkg was interrupted"

If no process holds the lock and apt tells you dpkg was interrupted, the package database is mid-transaction. Finish it:

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update && sudo apt upgrade

The first command replays any half-configured packages. The second pulls in missing dependencies. Both can take a while, so run them inside tmux or screen so a dropped connection doesn't interrupt them again.

Step 5: Stale lock, the last resort

Only if all three of these are true should you remove lock files:

1. lsof and fuser show no process holding it.
2. ps aux shows no apt, dpkg or unattended-upgrades running.
3. You've waited a few minutes and the error hasn't changed.

Then:

sudo rm /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock
sudo rm /var/lib/apt/lists/lock /var/cache/apt/archives/lock
sudo dpkg --configure -a
sudo apt update

Always follow a lock removal with dpkg --configure -a. Skipping that step is what turns a five-minute problem into a broken package database.

Fixing a fresh-VPS "apt is locked" loop

If the lock reappears every time and a process like apt.systemd.daily keeps showing up, it's the scheduled apt timers. Check them:

systemctl list-timers 'apt-daily*'
systemctl status apt-daily.service apt-daily-upgrade.service

Don't disable them permanently, since they deliver your security patches. Just wait for the current run to complete. If one is truly stuck for more than 30 minutes, check memory and disk first with free -h and df -h. A VPS that's out of RAM or full of logs will stall apt without any obvious error.

RHEL, AlmaLinux and Rocky: the dnf version

Same idea, different wording. You'll see "Waiting for process with pid 1234 to finish" or "Another app is currently holding the yum lock". Check ps -p 1234 -o pid,etime,cmd and wait. If a stuck process is clearly dead, sudo rm -f /var/run/yum.pid clears it, then run sudo dnf clean all.

Prevention

• Run long installs inside tmux so a dropped SSH session can't kill dpkg halfway.
• After first boot or a rebuild, give unattended-upgrades a few minutes before you start installing software.
• In deploy scripts, use DPkg::Lock::Timeout or the fuser loop so they wait instead of failing.
• Keep an eye on free disk and RAM. Running out of either mid-install is the top cause of interrupted dpkg runs.
• Take a VPS snapshot before big upgrades, so a bad outcome is a restore rather than a rebuild.

Frequently Asked Questions

Is it safe to just delete /var/lib/dpkg/lock-frontend?

Only if you've confirmed no process is using it. If something is actively installing, removing the lock lets a second process write to the same database, and that's how packages end up half-installed. Always check with lsof first and run dpkg --configure -a afterward.

How long should I wait for unattended-upgrades?

Usually under ten minutes. On a small VPS right after first boot it can take longer. If the log file is still changing, it's working, so leave it alone.

Why does apt say "dpkg was interrupted" when nothing is running?

A previous install was killed before it finished, often by a dropped SSH connection, reboot or out-of-memory event. Run sudo dpkg --configure -a and then sudo apt --fix-broken install to complete it.

Can I disable unattended-upgrades to avoid this?

You can, but it's not recommended because it stops automatic security patching. A better approach is to let it finish and use the lock timeout option in your scripts.