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.
kill -TERM 5019
and only laterkill -KILL 5019
(which is the same askill -9 5019
, see kill(1)....). Read signal(7) first. – Basile Starynkevitch Sep 5 '17 at 7:31kill
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