Это иллюстрирует две причины, по которым вам не следует использовать ps … | grep …
.
ps
печатает строку заголовка. Но поскольку вывод передается в grep
, а шаблон grep не соответствует строке заголовка, вы не видите строку заголовка. В строке заголовка вы увидите столбец с именем PID
. Значение в этом столбце — это то, что вам нужно передать в kill
.
При запуске ps … | grep …
часто отображается сам процесс grep. В вашем случае вы видите только процесс grep. Независимо от того, видите вы процесс grep или нет, он случайный :, конвейер работает ps
и grep
параллельно, и часто grep
успевает запуститься к моменту запуска ps
, но иногда ps
запускается очень быстро и grep
еще не началось. Существуют приемы, позволяющие не видеть процесс grep, например, гарантировать, что шаблон не совпадает с самим собой :
.
ps aux | grep '[a]pt'
Но есть и более надежные способы сделать это. Linux и другие системы предоставляют утилиту под названием pgrep
. Он работает примерно так же, как ps … | grep …
, но более надежно.
pgrep apt
Чтобы получить информацию о процессах, вы можете передать идентификаторы процессов вps
:
ps $(pgrep apt)
Если вы хотите убить их всех, вы можете изменить команду pgrep
на pkill
. Если вы хотите убить только некоторых из них,либо добавьте дополнительные критерии в командную строку pgrep
, чтобы она соответствовала только нужным процессам, либо вручную выберите PID из выходных данных ps
.
Команда Linux ps
также может сопоставлять процессы по нескольким критериям, включая имя команды, но вам нужно точное совпадение, тогда как pgrep
может находить подстроки и, в более общем случае, совпадения с регулярными выражениями.
ps -C apt # won't find e.g. apt-get
Все это не лучший способ решить вашу проблему с apt-блокировкой. См. ответ Стефана Шазела .
Мне пришлось монтировать загрузочный раздел в /boot
, а не /mnt/boot
...