'Could Not Get Lock' on dpkg: Don't rm the Lock File Before Checking This

You run sudo apt install on a fresh server, and apt refuses. It cannot get the lock, it says, because some process is holding it. You paste the error into a search engine, and the first ten results all tell you the same thing: delete the lock files and force a reconfigure. It is the top answer everywhere. It usually works. And it is how people corrupt their package database.

Here is the thesis: that lock is doing its job. apt and dpkg use it precisely so that two package operations never run at once, because two writers to the package database at the same time is how you get a genuinely broken system. When you delete the lock without checking what holds it, you are not fixing the lock, you are overriding a safety interlock while the machine it protects may still be running.

Nine times out of ten on a modern Ubuntu or Debian box, the thing holding that lock is unattended-upgrades quietly installing security patches in the background. It will finish on its own in a few minutes. Wait, and the problem evaporates with zero risk. So before you rm anything, spend fifteen seconds finding out who actually has the lock.

The exact error

The message names the lock file and, crucially, tells you a process holds it:

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

Read past the first line. The text in parentheses after the PID is the name of the process holding the lock. In the example above it is unattended-upgr, which is the single most common answer to "what is holding it." Sometimes it is apt, apt-get, packagekitd, or dpkg itself from another terminal. That name is the whole diagnosis, and the guides that skip straight to rm never even look at it.

Why the lock exists and why deleting it is dangerous

dpkg maintains a database of every installed package under /var/lib/dpkg/. Installing, removing or configuring a package rewrites parts of that database and unpacks files across the filesystem. If two operations did that simultaneously they would interleave writes and leave packages half-configured, files half-unpacked, and the database describing a state that does not match reality. To prevent this, apt and dpkg take exclusive locks: lock-frontend coordinates the higher-level frontends, and lock guards the dpkg database itself.

When you rm the lock file out from under a running transaction, you do not stop that transaction. It keeps writing. You have just told a second process that the coast is clear, so it starts writing too. Now both are modifying the package database, and the result is the dreaded half-configured state. The irony is thick: the "fix" for a lock error is the fastest way to produce the far worse dpkg was interrupted error, which really does require repair.

The fix, step by step

Step 1: Find out what actually holds the lock

Ask the kernel who has the file open. lsof is the cleanest tool for it:

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

Expected output when something holds it is a line naming the command and its PID, for example:

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
unattended 2841 root    4uW  REG  259,1        0 131074 /var/lib/dpkg/lock-frontend

The W in the FD column means a write lock is held. If lsof prints nothing at all, no process has the file open, and the lock is stale. If you do not have lsof installed (chicken and egg on a broken apt), fall back to:

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

Step 2: If a real process holds it, wait

If Step 1 named unattended-upgrades, apt, apt-get, aptitude, dpkg, or packagekitd, that process is doing legitimate work. The right action is to wait for it to finish. Security upgrades typically complete within a few minutes. You can watch it wind down:

# wait until nothing is holding the lock, then continue
while sudo lsof /var/lib/dpkg/lock-frontend >/dev/null 2>&1; do
  echo "lock still held, waiting..."; sleep 5;
done
echo "lock released"

When that loop prints "lock released," re-run your apt command and it will proceed. You have lost a few minutes and risked nothing, which is the whole point.

Step 3: Only if the lock is stale, remove it, then repair

If Step 1 showed nothing holding the lock, the process that created it died without cleaning up (a crashed apt, a killed SSH session mid-install, a power loss). This is the only case where removing the lock is correct. Remove both lock files:

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

Then, because a crashed transaction may have left a package half-configured, repair the database before doing anything else:

sudo dpkg --configure -a

This finishes any package that was mid-configuration. It should complete without error on a system that was merely holding a stale lock. Skipping this step is how a stale-lock cleanup turns into a lingering half-configured package that bites you on the next install.

Verification

Prove the lock is gone and apt is healthy by running a harmless operation that takes the lock and releases it:

sudo apt update

Expected: it fetches package lists and exits cleanly with no lock error. Follow with a state check that will complain if any package is still half-configured:

sudo dpkg --audit

Expected: no output, which means dpkg found no packages in a broken state. Output here lists packages that still need attention, and you resolve them with another sudo dpkg --configure -a or sudo apt install -f.

What people get wrong

sudo rm /var/lib/dpkg/lock* as step one. This is the internet's favourite answer and it is reckless as a first move. It works when the lock is stale and corrupts your system when it is not, and the guides that recommend it never tell you how to tell the difference. Check first, delete second, and only when nothing holds it.

Killing the process with kill -9. If you see unattended-upgrades holding the lock and impatiently kill -9 it, you abort a package transaction partway, which is exactly what produces the dpkg was interrupted state. A hard kill of a dpkg process is a last resort, not a first response. Let it finish, or at most send a gentle signal and let it clean up.

Disabling unattended-upgrades permanently out of annoyance. It is installing your security patches. Turning it off to stop the lock contention trades a two-minute wait for an unpatched server. If it genuinely gets in the way during automated provisioning, disable it for that window only and re-enable it, do not rip it out.

When it is still broken

If the lock keeps reappearing immediately after you clear it, something is relaunching apt. Check for a running apt-daily or apt-daily-upgrade systemd timer firing, and if you are provisioning, that is the culprit racing your script. In automation, do not loop-retry rm plus install; instead wait for the lock to clear (the loop in Step 2 is a good building block) or mask the apt-daily timers for the provisioning window and unmask them after. If dpkg --configure -a itself errors, you are now in the interrupted-dpkg state and need to identify and reinstall or purge the offending package named in its output. For the wider question of when to use cron versus systemd timers for this kind of scheduled maintenance, see Cron vs systemd Timers vs the Frappe Scheduler. The authoritative reference for dpkg's states and repair flags is the dpkg man page.