Ubuntu apt Error: Could not get lock /var/lib/dpkg/lock-frontend

Short answer: the message means another apt or dpkg process is holding the package system lock. Wait for it to finish or cancel it, then run your command again. You can see which process holds the lock with ps and lsof. Do not delete the lock file.

What the message means

Ubuntu allows only one package installation or removal at a time. The process that is working on packages holds a lock on the file /var/lib/dpkg/lock-frontend. If you start a second apt install while that lock is held, apt cannot get it and prints the message.

How I reproduced it

I used an Ubuntu 24.04.4 LTS server with apt 2.8.3 and two terminal windows connected to the same machine.

1. In terminal A I ran sudo apt install gimp. apt showed the confirmation prompt (Do you want to continue? [Y/n]) and I left it unanswered, so the command kept running.
2. In terminal B I ran sudo apt install figlet.
3. In terminal B I also ran sudo apt update, ps and lsof to see what was happening.
4. I answered n in terminal A, which ended the command with Abort., and ran sudo apt install figlet again in terminal B.

#	Where	Command	Result
1	Terminal B	sudo apt install figlet	The same Waiting for cache lock line repeated
2	Terminal B	sudo apt update	Finished normally
3	Terminal B	ps, filtered for apt and dpkg	Showed the apt install gimp process
4	Terminal B	sudo lsof /var/lib/dpkg/lock-frontend	Showed one apt process with the lock file open
5	Terminal B	sudo apt install figlet, after answering n in terminal A	Installed without waiting

The message I got

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process <PID> (apt)

It did not fail right away on this server. The same line kept repeating while apt waited for the lock. The text names the process that holds the lock, so you do not have to guess.

Find the process that holds the lock

Run this in a second terminal:

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

The output below is shortened, and the process numbers are replaced with placeholders.

root  <PID-1>  sudo apt install gimp
root  <PID-2>  sudo apt install gimp
root  <PID>    apt install gimp

In my test the process number in the error message was the same as the number of the apt install gimp process. Next I asked lsof which process has the lock file open:

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

COMMAND  PID    USER  FD   TYPE  NAME
apt      <PID>  root  4uW  REG   /var/lib/dpkg/lock-frontend

Only one process had the file open, and it was the same apt process. In lsof notation, the W in 4uW means a write lock on the whole file.

How to fix it

1. Read the message and note the process number and name.
2. Check what that process is with ps. If it is an apt command you started in another window, go to that window and let it finish or cancel it.
3. If you do not recognize the process, wait for it to finish. I did not test removing lock files and I do not recommend it.
4. Run your command again. In my test it ran without waiting once the other command was cancelled.

apt update was not blocked in my test

While terminal A was holding the lock, sudo apt update in terminal B finished normally. I saw this once and only in this situation. Other situations, such as an update that is already downloading, may behave differently.

A tip for reproducing it

In my tests, installing a small single package (cowsay and figlet) did not ask for confirmation, but removing a package did. If you try to reproduce this yourself, check on the first terminal that the command is really still running before you start the second one.

What I did not test

• Other causes of the same message, such as automatic updates running in the background
• How long apt waits for the lock before it gives up
• Removing lock files
• Other Ubuntu versions