How to Fix "Could not get lock /var/lib/dpkg/lock"

The /var/lib/dpkg/lock error stops any apt or dpkg operation cold. It appears when a second process tries to write to the package database while another one already holds the lock file. Most of the time a background update daemon or a previous crashed session is the culprit. The fix is straightforward, but blindly deleting the lock file without checking what holds it is a shortcut that can corrupt your package database. Do it correctly.

What the Lock Actually Is

dpkg uses POSIX advisory locks on several files under /var/lib/dpkg/ and /var/cache/apt/archives/ to prevent concurrent writes. When apt or dpkg starts, it acquires an exclusive lock. If the process exits cleanly, the lock is released automatically. If the system crashed, power was cut, or the terminal was force-closed mid-install, the lock file may linger even though nothing owns it. There are actually two lock files you will commonly encounter:

• /var/lib/dpkg/lock — the core dpkg database lock
• /var/lib/dpkg/lock-frontend — held by higher-level frontends like apt
• /var/cache/apt/archives/lock — the download cache lock

Step 1: Read the Full Error Message

The exact error text tells you which lock file is involved and sometimes includes a process ID. Note it before doing anything else. Common variants:

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1843
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)

If a PID is listed, jump straight to Step 2. If no PID appears, the lock file is stale from a dead process.

Step 2: Find What Holds the Lock

Use lsof or fuser to identify the owning process. Run these with sudo:

sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock
sudo lsof /var/cache/apt/archives/lock

Alternatively with fuser:

sudo fuser /var/lib/dpkg/lock-frontend
sudo fuser /var/lib/dpkg/lock

If either command returns no output, the lock is stale and no process owns it — skip ahead to Step 4. If a PID is returned, proceed to Step 3.

Step 3: Identify and Handle the Live Process

Get details on the process holding the lock:

ps aux | grep -E 'apt|dpkg|unattended'

Common legitimate holders and what to do:

• unattended-upgrade — A background upgrade is running. Wait for it to finish. Check progress with sudo journalctl -u unattended-upgrades -f.
• apt-get / apt — Another terminal session is running an install. Find and close it, or wait.
• dpkg — A configuration step is in progress. Interrupting it is risky. Wait unless it is clearly hung.
• snap — On Ubuntu, snapd can trigger apt operations indirectly. Wait for it.

If the process is genuinely stuck (zombie, unkillable, hung for more than 30 minutes), send SIGTERM first, then SIGKILL only if needed:

sudo kill -TERM <PID>
# Wait 10 seconds, then if still running:
sudo kill -KILL <PID>

Replace <PID> with the actual process ID. Never kill an active, healthy apt or dpkg process — you risk leaving the package database in an inconsistent state.

Step 4: Remove Stale Lock Files

Only do this after confirming no live process owns the lock (Step 2 returned empty). Remove each stale lock file:

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

These files are recreated automatically the next time apt or dpkg runs. Removing them when they are truly orphaned is safe.

Step 5: Repair the Package Database

After a crash or a force-killed dpkg session, the package database may be partially updated. Always run a reconfigure pass before your next install or upgrade:

sudo dpkg --configure -a

This tells dpkg to finish configuring any packages that were mid-installation. If it reports errors, follow up with:

sudo apt --fix-broken install

Step 6: Verify Everything Is Working

Run a simple apt update to confirm the lock is gone and the database is healthy:

sudo apt update

A clean run exits without lock errors and refreshes your package lists. If it still complains about a lock, reboot and try again — a reboot releases any kernel-held file locks and is always safe at this point.

Preventing the Problem

Check What unattended-upgrades Is Doing

On Ubuntu and Debian, unattended-upgrades runs as a systemd service and frequently causes this error when you try to manually install something at the same time. Check its status:

systemctl status unattended-upgrades

If you want to temporarily disable it while doing maintenance:

sudo systemctl stop unattended-upgrades

Re-enable it after you're done:

sudo systemctl start unattended-upgrades

Wait, Don't Fight It

A simple one-liner checks every 10 seconds whether the lock is free, then runs your command automatically — useful for scripted environments:

while sudo fuser /var/lib/dpkg/lock-frontend >/dev/null 2>&1; do
  echo "Waiting for lock..."
  sleep 10
done
sudo apt install <package>

Troubleshooting

Error persists after removing lock files

A reboot is the cleanest reset. After rebooting, run sudo dpkg --configure -a && sudo apt --fix-broken install before any other apt operation.

dpkg --configure -a produces errors about missing files

A partially downloaded package may have been removed mid-install. Clean the apt cache and retry:

sudo apt clean
sudo dpkg --configure -a
sudo apt --fix-broken install

Lock reappears immediately after removal

A background process is still running. Use ps aux | grep -E 'apt|dpkg' again. Look specifically for apt-daily.service or apt-daily-upgrade.service:

systemctl list-units --state=running | grep apt

Stop the relevant unit, then proceed.

System reports broken packages after fixing the lock

Run the full repair sequence in order:

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