Could not get lock /var/lib/dpkg/lock — the safe fix

Could not get lock /var/lib/dpkg/lock-frontend means another process is already using the package system. Only one apt or dpkg operation can run at a time, so the second one waits for a lock it cannot get. The right fix is patience first, force last.

1. Something else is genuinely running — wait for it

On a fresh cloud server this is almost always unattended-upgrades installing security patches in the background. See who holds the lock:

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

If you see an apt or unattended-upgrade process, give it a couple of minutes and try again. It will finish and release the lock on its own.

2. It is stuck — end the process cleanly

If a previous apt command was interrupted (closed terminal, dropped SSH), the process may be a zombie holding the lock. Stop it gracefully:

sudo kill <PID>          # PID from the ps output above
# if it will not die and nothing important is mid-install:
sudo kill -9 <PID>

3. Remove stale locks and repair dpkg

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

# finish any half-configured packages
sudo dpkg --configure -a
sudo apt update

Optional: stop the background updater interfering

On a server where you manage updates yourself, the automatic timer causing these collisions can be paused for the session:

sudo systemctl stop unattended-upgrades
# re-enable later with: sudo systemctl start unattended-upgrades

Leave automatic security updates on in the long run — they matter more than the occasional lock wait. If a repair leaves the box in a bad state, a VMHeaven VPS can be rolled back from a snapshot or reinstalled from the panel in minutes.

Frequently asked