grub-install: ошибка: не удалось получить канонический путь `/boot/efi'

Это иллюстрирует две причины, по которым вам не следует использовать 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-блокировкой. См. ответ Стефана Шазела .

1
12.01.2020, 22:36
1 ответ

Мне пришлось монтировать загрузочный раздел в /boot, а не /mnt/boot...

1
27.01.2020, 23:40

Теги

Похожие вопросы