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

Another apt/dpkg process is mid-run — usually unattended-upgrades doing its job. Killing it blindly is how you create the bigger problem.

What you'll see

Root causes

Unattended upgrades running

Ubuntu auto-applies security updates in the background; the lock is legitimately held for minutes.

A previous apt run died mid-transaction

Crash left dpkg half-configured; the next run needs cleanup before anything else.

Fix it

  1. See who holds the lock before touching it
    ps aux | grep -E 'apt|dpkg' | grep -v grep
  2. Wait for unattended-upgrades to finish (check again)
    watch -n5 'ps aux | grep unattended'
  3. If truly dead, finish any half-done dpkg state
    sudo dpkg --configure -a && sudo apt -f install
  4. Last resort, after confirming no process holds it
    sudo fuser -k /var/lib/dpkg/lock-frontend   # only if ps shows nothing

Field note

On cloud VMs, cloud-init also runs apt at first boot. Give a fresh instance five minutes before concluding anything is broken.

Common questions

What holds the dpkg lock?

An apt/dpkg process mid-operation — often an unattended-upgrades background run on Ubuntu. lsof /var/lib/dpkg/lock-frontend names the holder; waiting beats killing, since interrupting dpkg mid-write leaves the package database inconsistent.

Is it safe to delete the lock file?

Only after confirming the holder is dead (crashed, not running). Deleting the lock while dpkg is mid-operation corrupts package state; prefer killing the stale process or rebooting. Check for a dangling dpkg --configure -a afterwards.

Related fixes

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.