How do I kill the process holding the apt lock?

Question

I tried doing

sudo apt update

but got:

Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)

E: Unable to lock directory /var/lib/apt/lists/

I am trying to get the latest version of mongod. Following some instructions I found, I did:

$ ps aux | grep apt
5019  0.0  0.0  14224   980 pts/0    S+   02:52   0:00 grep --color=auto apt

But I don't know which part of this I should plug into

kill -9 processnumber <id>

to make it work.

Which part is the ID and is there any way to prevent this from happening again?

Answer 1

If you want to kill processes based on their name or argument list, use pkill.

pkill regexp

Will kill all processes whose name matches the regexp extended regular expression.

pkill -f regexp

Will kill all processes whose list of arguments (including the first which usually contains the command name) concatenated with spaces matches the regexp.

Here however, it looks more like you want to kill the process(es) that holds the /var/lib/apt/lists/lock lock file, so:

fuser -k /var/lib/apt/lists/lock

(with some fuser implementations) or

lsof -t /var/lib/apt/lists/lock | xargs kill

may be more appropriate.

Though you may want to check what process it is first with lsof /var/lib/apt/lists/lock or fuser /var/lib/apt/lists/lock. And exit it normally if possible instead of coldly kill it.

In any case, avoid kill -9 which doesn't let a chance to the process to exit cleanly.

Answer 2

This illustrates two reasons why you shouldn't use ps … | grep ….

ps prints a title line. But since the output is piped into grep, and the grep pattern doesn't match the title line, you don't get to see the title line. In the title line, you'd see a column called PID. The value in this column is what you need to pass to kill.

When you run ps … | grep …, this often lists the grep process itself. In your case, you're only seeing the grep process. Whether you see the grep process or not is random: the pipe runs ps and grep in parallel, and often grep has had time to start by the time ps runs, but sometimes ps runs very quickly and grep hasn't started yet. There are tricks to avoid seeing the grep process, such as ensuring that the pattern doesn't match itself:

ps aux | grep '[a]pt'

But there are more reliable ways to do this. Linux and other systems provide a utility called pgrep. It works a bit like ps … | grep … but more reliably.

pgrep apt

To get information about the processes, you can pass the process IDs to ps:

ps $(pgrep apt)

If you want to kill them all, you can change the pgrep command to pkill. If you only want to kill some of them, either add more criteria to the pgrep command line so that it only matches the processes you want, or manually select PIDs from the ps output.

Linux's ps command can also match processes by several criteria, including the command name, but you need an exact match whereas pgrep can find substrings and more generally regular expression matches.

ps -C apt     # won't find e.g. apt-get

None of this is the best way to solve your apt lock problem though. See Stéphane Chazelas's answer for this.