Another program is using the package system right now, and apt is politely refusing to be the second writer. Most of the time that program is your own automatic updates. This page shows how to identify the holder - and the one wrong fix that turns this harmless message into real corruption.
You type an install command and Ubuntu answers: "Could not get lock... It is held by process..." It reads like breakage. It is actually a queue. One process at a time may write the package database, and right now another process - very often the unattended security updater - holds the pen. This page teaches the order of response: wait, look, identify - and only in the rare dead-process case, the careful kill-and-repair sequence.
Only one program may change the package system at a time - two installers writing the same database would corrupt it. So apt and dpkg take a lock while they work, and any second command gets Could not get lock plus the name and process number of the holder. On a healthy Ubuntu desktop the holder is very often unattended-upgrades - the automatic security update service doing its scheduled run - or a Software Updater window you left open, or another terminal. Nothing has failed. Something else is simply first in the queue, and it will finish.
ps aux | grep -i apt shows running apt and dpkg processes. For the dpkg lock specifically, sudo fuser -v /var/lib/dpkg/lock-frontend prints exactly which process holds it and who owns it.unattended-upgr is automatic updates, apt or dpkg may be your own forgotten terminal, and packagekit or the Software app is the graphical updater. A holder that is genuinely working shows changing CPU or disk activity - give it its time.You cannot remove the automatic updater - nor should you, it is your security updates arriving on their own. You can schedule around it: run your manual installs a few minutes after boot rather than in the first seconds when apt-daily jobs start, and avoid leaving the Software app open while you work in the terminal. If lock collisions happen daily on a server, that is a sign the automatic runs and your maintenance window overlap - move one of them. The lock is a seatbelt: occasionally in the way, never the problem.
sudo rm /var/lib/dpkg/lock-frontend and friends) while a process is alive. It does not release the holder - it destroys the signal that keeps two writers out of the package database at once. Every "delete the lock" tutorial is trading your database's safety for a message disappearing.The video shows a real lock collision, identifies automatic updates as the holder, and the update going through once it finishes.
▶️ Watch Full VideoUbuntu runs its automatic update checks shortly after startup through the apt-daily and unattended-upgrades services. If you open a terminal in those first minutes and run apt yourself, you collide with that scheduled run. The holder is doing legitimate work - fetching lists and applying security updates - so the correct response is simply to wait a few minutes and run your command again.
Only when you have confirmed it is genuinely dead or stuck - for example its terminal was closed, or it has shown no activity for a long time. Kill it by the exact process number fuser reports, then always run sudo dpkg --configure -a afterwards to finish or roll back whatever it was in the middle of. Killing a live, working updater mid-install without that repair step can leave packages half-configured.
They guard different doors. The lists lock (/var/lib/apt/lists/lock) is held while apt update refreshes package lists. The frontend lock (/var/lib/dpkg/lock-frontend) is held while packages are actually being installed, removed or configured. Reading the path in your error tells you which activity is in progress - an update is quick and safe to wait out, while an install deserves a little more patience.