Fix ‘Could Not Get Lock /var/lib/dpkg/lock-frontend’

You run an install or upgrade and apt refuses to start:

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2295 (unattended-upgr)
N: Be aware that removing the lock file is not a solution and may break your system.

Most of the time this error is apt working exactly as designed: another package operation is already running, and two of them writing dpkg’s database at once would corrupt it. The dangerous part is not the error — it is the most-upvoted answer to it, which tells you to delete the lock file. Sometimes the holder finishes in two minutes. Sometimes it has been wedged for months. The whole job here is telling those two cases apart before you touch anything.

sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/lib/apt/lists/lock 2>/dev/null

Why the Lock Exists

dpkg’s database under /var/lib/dpkg/ records what is installed, at what version, with which files. A package operation rewrites it in multiple steps, and there are several locks guarding the process: lock-frontend (taken by high-level tools like apt for the whole session), lock (the dpkg database itself), and /var/lib/apt/lists/lock (the package index). Whichever one appears in your error, the meaning is the same — someone else is mid-operation.

Step 1: Identify the Holder

Modern apt names the process right in the error. Confirm it and check all the locks at once:

sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/lib/apt/lists/lock 2>/dev/null

Then look at how long the holder has been running and what state it is in:

ps -o pid,etime,stat,cmd -p 2295

Replace 2295 with the PID from your error. The etime column is the decision point: minutes is normal, hours is suspicious, days is stuck.

Step 2: If It Is unattended-upgrades, Let It Finish

Ubuntu and Debian install security updates automatically via unattended-upgrades, and its timers tend to fire shortly after boot — which is why this error so often appears the moment you log in to do exactly what it is already doing. Watch it work:

sudo tail -f /var/log/unattended-upgrades/unattended-upgrades.log

You can also see when the automatic runs are scheduled:

systemctl list-timers 'apt-daily*'

A normal run finishes in a few minutes; a kernel update with initramfs rebuilds on a slow disk can take ten or fifteen. If the log is actively appending, the correct move is coffee, not kill. The lock releases itself the moment it completes.

Step 3: Deciding a Process Is Genuinely Stuck

Stuck means the process exists but is doing nothing, and will keep doing nothing forever. Two checks together give you confidence:

ps -o pid,etime,time,stat,cmd -p 2295
sudo tail -3 /var/log/dpkg.log

First, compare etime (how long it has existed) with time (CPU it has actually consumed) — a process alive for hours that has consumed almost no CPU and whose log stopped moving is wedged. Second, check whether dpkg’s own log has written anything recently.

Do not assume this resolves itself eventually. We once inherited a server whose apt process had been holding the lock for 1,019 days — a hung update left a wedged process in place, every subsequent automatic run bounced off the lock, and the machine silently went almost three years without a security patch. The only visible symptom the whole time was this exact error.

Step 4: Kill the Holder Safely

Once you are confident it is stuck, kill the process — never the lock file:

sudo kill 2295

Give it thirty seconds to exit cleanly. Only if it survives a polite TERM:

sudo kill -9 2295

Do not run rm on any lock file while a process holds it. The lock is advisory bookkeeping for a real operation; deleting it lets a second dpkg start writing over the first one’s half-finished work, and that is how you end up reinstalling an operating system. Once the holder is dead, the locks release on their own.

An interrupted operation may have left packages half-configured. Finish the job:

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

If that second command reports unresolvable dependency problems, our guide to apt –fix-broken install not working picks up from there.

Verify the Fix

Prove the lock is free and the package system is healthy end to end:

sudo apt update
apt list --upgradable

Then run whatever install or upgrade you originally wanted. If a machine has been stuck for a long time, expect a large upgrade list — work through it now rather than deferring it; that backlog is unpatched exposure.

Prevent It From Recurring

Never interrupt a running upgrade. The most common way processes end up wedged is a closed laptop lid or dropped SSH session mid-dist-upgrade. For anything long-running over SSH, start it inside tmux or screen so the operation survives your connection.

Leave unattended-upgrades enabled. The lock contention it causes is an occasional two-minute wait; the security patching it does is continuous. Removing it to avoid this error is trading a papercut for an open wound.

Glance at package health after reboots and incidents. A quick sudo apt update that completes cleanly is a five-second proof the whole chain works. On fleet machines, alert when the last successful apt run is more than a week old — that check would have caught our 1,019-day patient roughly 1,012 days sooner.

Frequently Asked Questions