Unable to acquire the dpkg lock, explained and fixed

Debian and Ubuntu allow only one package-management process to modify the system at a time. When a second one starts, it stops with Could not get lock /var/lib/dpkg/lock-frontend. It is held by process … (apt) or a variant naming /var/lib/dpkg/lock or the cache lock. Most of the time this is coordination working correctly: an update is genuinely running, possibly an unattended background one you did not start. Occasionally a crashed process leaves the system believing a holder exists when none does. The two situations need opposite responses, patience for the first and cleanup for the second, and telling them apart takes one command.

Tell a live holder from a stale lock

  1. Read the message fully: modern apt names the holding process and its PID when there is one. Then look: ps aux | grep -E 'apt|dpkg' shows whether that process (or any package process) is actually alive and what it is doing.
  2. Common legitimate holders: an unattended-upgrades run (check systemctl status unattended-upgrades or just the process list), a graphical software center or updater left open, another terminal's forgotten apt waiting at a prompt, or a configuration step (dpkg --configure) still working.
  3. If a real process holds it, wait. Interrupting a working dpkg mid-configuration is how half-configured systems (and the error-code page's problems) are made. Background upgrades finish in minutes.

If nothing holds it (the stale case)

  1. Confirm twice that no apt or dpkg process exists in the process list, then remove the lock files: sudo rm /var/lib/dpkg/lock-frontend /var/cache/apt/archives/lock /var/lib/dpkg/lock. Removing locks while a holder lives is the dangerous version of this step, which is why the confirmation comes first.
  2. Then repair any interrupted state: sudo dpkg --configure -a completes whatever the killed process left pending, and a normal sudo apt update should now run cleanly.
Never kill a running dpkg or apt to “free” the lock unless the machine itself is being decommissioned. A holder that looks idle may be waiting on a prompt in another window or mid-download. The process list and a few minutes of patience distinguish a worker from a ghost at no risk.

Common questions

Why does it happen right after booting? Unattended upgrades check in shortly after boot on many Ubuntu configurations, and the first manual apt command of the session collides with it. Waiting for the background run to finish, or letting the software updater complete, clears it.

The message names a PID that no longer exists, is the lock stale? Yes, that is the stale signature: a holder recorded but absent from the process list. Verify no apt/dpkg process runs under any PID, then remove the lock files and run dpkg --configure -a.

How do I stop background updates from colliding with me? You can check for them first (the process list, or the software updater), schedule your own work, or adjust unattended-upgrades' timing in its configuration. Disabling security updates entirely to avoid collisions trades a nuisance for exposure and is not recommended.

Related errors

dpkg returned an error code · Permission denied (Linux) · Command not found