Could not get lock /var/lib/dpkg/lock-frontend often pushes toward a reflex found everywhere online: deleting the lock file directly (rm /var/lib/dpkg/lock-frontend) to unblock apt. That reflex is risky: if another legitimate process still holds that lock, deleting it can let two dpkg operations write to the same package database simultaneously, a corrupted state far more costly to fix than the original wait.

What the lock actually protects

dpkg (and apt, which relies on it) maintains several lock files (/var/lib/dpkg/lock, /var/lib/dpkg/lock-frontend, /var/cache/apt/archives/lock) to guarantee that only one package-modifying operation runs at a time. This protection exists precisely because two concurrent writes to the package database (/var/lib/dpkg/status) can corrupt it, a problem far harder to fix than a temporary error message.

Checking who holds it before deleting anything

The first step when facing this message is never to delete the file, but to identify which process actually holds the lock.

# Identifies the PID holding the lock,
# before taking any action on the file itself
sudo lsof /var/lib/dpkg/lock-frontend
# or, an alternative without lsof installed
sudo fuser /var/lib/dpkg/lock-frontend

The most common culprit isn’t a stuck process, but unattended-upgrades, a service that automatically applies security updates in the background and legitimately holds this lock while it runs, often with no interactive terminal making that obvious.

# unattended-upgrades runs as a systemd service,
# independent of any active user session
systemctl status unattended-upgrades

The right response depending on what lsof reveals

If the holding process is unattended-upgrades or a still-active legitimate apt/dpkg instance, the only correct action is to wait for it to finish naturally, usually a matter of a few minutes. If the process is genuinely dead (a dpkg run interrupted by a power outage, for instance, whose PID no longer exists in ps aux), deleting the lock becomes legitimate, but only after this check, never before.

# Only once the PID returned by lsof/fuser
# no longer actually exists on the system
sudo rm /var/lib/dpkg/lock-frontend
sudo dpkg --configure -a

Takeaway

Could not get lock never justifies reflexively deleting the lock file: the first action is always to identify the holding process via lsof or fuser, the most frequent culprit being unattended-upgrades legitimately running in the background, the same automated-update principle that Renovate or Dependabot apply at the application-dependency level rather than the operating-system level. Deleting a lock still held by an active process risks corrupting the dpkg package database, a problem far costlier than waiting a few minutes for a legitimate process to finish. Only once it’s confirmed that no live process actually holds the lock does deleting it become a safe action.