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?

  • The first number is the PID. – Kusalananda Sep 5 '17 at 7:22
  • You should try first kill -TERM 5019 and only later kill -KILL 5019 (which is the same as kill -9 5019, see kill(1)....). Read signal(7) first. – Basile Starynkevitch Sep 5 '17 at 7:31
  • 2
    Actually, what xe should try first is not using the kill command at all, and instead looking at what other instances of the package tool xe happens to be running elsewhere, and simply exiting them in the normal way. – JdeBP Sep 5 '17 at 7:35
  • 1
    Note further that the pid that resulted was for grep; killing that pid will at best do nothing and at worst kill something completely unrelated. – Jeff Schaller Sep 5 '17 at 9:21
  • 2
    icewizard, can you clarify your question: are you wanting to fix the "apt update" lock issue, or do you want to find a PID to kill? (I would vote for the former, and warn you about the latter -- as per Basile and JdeBP's comments above) – Jeff Schaller Sep 5 '17 at 12:55

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.