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
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
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.
To get information about the processes, you can pass the process IDs to
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 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.