killall не дает мне 'процесса, найденного', но PS

Менеджер по шрифту очень удобен для предварительного просмотра и сравнения шрифтов. Это позволяет Вам устанавливать файлы TTF, даже если заархивированный, и предварительно просмотрит их довольно быстро. Это действительно устанавливает их в Вашем ~/.fonts каталог, но довольно легко удалить их.

Font Manager

17
06.06.2011, 16:59
5 ответов

Это находится на Linux?

Существует на самом деле несколько тонко различных версий названия команды, которые используются ps, killall, и т.д.

Два основных варианта: 1) длинное название команды, которое является тем, что Вы получаете, когда Вы работаете ps u; и 2) короткое название команды, которое является тем, что Вы получаете, когда Вы работаете ps без любых флагов.

Вероятно, самое большое различие происходит, если Ваша программа является сценарием оболочки или чем-нибудь, что требует интерпретатора, например, Python, Java, и т.д.

Вот действительно тривиальный сценарий, который демонстрирует различие. Я назвал его mycat:

#!/bin/sh
cat

После выполнения его вот два различных типов ps.

Во-первых, без u:

$ ps -p 5290
  PID TTY      ... CMD
 5290 pts/6    ... mycat

Во-вторых, с u:

$ ps u 5290
USER       PID ... COMMAND
mikel     5290 ... /bin/sh /home/mikel/bin/mycat

Отметьте, как вторая версия запускается с /bin/sh?

Теперь, насколько я могу сказать, killall на самом деле чтения /proc/<pid>/stat, и захватывает второе слово, промежуточное parens как название команды, таким образом, это действительно, что необходимо указывать, когда Вы работаете killall. Логически, это должно совпасть со что ps без u флаг говорит, но это была бы хорошая идея проверить.

Вещи проверить:

  1. что делает cat /proc/<pid>/stat скажите, что название команды?
  2. что делает ps -e | grep db2 скажите, что название команды?
  3. сделать ps -e | grep db2 и ps au | grep db2 показать то же название команды?

Примечания

Если Вы используете другие флаги PS также, то Вы могли бы найти более простым использовать ps -o comm видеть краткое название и ps -o cmd видеть длинное имя.

Вы также могли бы найти pkill лучшая альтернатива. В частности, pkill -f попытки соответствовать использованию полного названия команды, т.е. названия команды, как распечатано ps u или ps -o cmd.

19
27.01.2020, 19:47
  • 1
    очень хорошее объяснение. И я предполагаю, что Вы были правы в первый раз. ps -e |grep db2 gives me 3084? 0:00:00 db2syscr' и PS aux |grep db2 дает мне root 3084 0.0 0.6 579292 28304 ? S 13:02 0:00 db2ckpwd. Мог прокомментировать это. Я - потерянный бит. –  Radek 06.06.2011, 07:33
  • 2
    , я не уверен. Возможно, что программа меняет свое имя. Вы знаете, как это выполняется? Что делает ls -l /proc/3084/exe сказать? Что относительно which или whence или type найти файл и затем ls и type видеть, является ли это символьная ссылка или сценарий или двоичный файл? –  Mikel 06.06.2011, 09:35
  • 3
    ls-l/proc/3084/exe дает нам lrwxrwxrwx 1 root root 0 Jun 6 16:49 /proc/3084/exe -> /var/lib/db2/db2inst1/sqllib/adm/db2syscr –  Radek 06.06.2011, 09:52
  • 4
    ls-l/var/lib/db2/db2inst1/sqllib/adm/db2syscr дает мне -r-sr-s--- 1 root db2iadm1 147K Feb 1 23:32 /var/lib/db2/db2inst1/sqllib/adm/db2syscr* ---------121 тип--------44882----дает мне/var/lib/db2/db2inst1/sqllib/adm/db2syscr /var/lib/db2/db2inst1/sqllib/adm/db2syscr is /var/lib/db2/db2inst1/sqllib/adm/db2syscr –  Radek 06.06.2011, 09:54

killall пытается соответствовать на имени процесса (но не действительно настолько хорошо в части соответствия).

И начиная с "PS | grep" и "PS | grep | уничтожают", делает намного лучшее задание, кто-то упростил это и создал pgrep и pkill. Считайте, что команды как "PS grep" и "PS уничтожают", начиная с той команды первый PS затем grep, и, если требуется уничтожает.

6
27.01.2020, 19:47

У меня была похожая проблема, но /proc//stat содержал ожидаемую строку. Используя строку strace я видел, что к killall также обращался /proc//cmdline.

Я продолжал исследовать с помощью gdb, чтобы обнаружить, что в моем случае он провалился при проверке моей команды на полную команду, включая все аргументы, найденные в /proc//cmdline. Казалось, что этот путь кода сработал из-за того, что имя файла длиннее 15 символов (что является жестко закодированным значением в источнике killall). Я не до конца исследовал, можно ли как-то заставить его работать с killall.

Но, как упоминалось в других комментариях, pkill - это лучшая альтернатива, которая не имеет тех же проблем.

Исходный код pkill для заинтересованных лиц можно найти здесь https://github.com/acg/psmisc.

2
27.01.2020, 19:47

В системах Ubuntu 16 /proc/ pid /stat будет содержать имя потока (, которое программа может использовать через pthread _setname _np системный вызов.

0
27.01.2020, 19:47

В большинстве случаев kill PIDбудет работать.

Для определения использования PIDpgrep <application name>

Если вы убили такое приложение, как Google Chrome, которое работает с несколькими идентификаторами PID

я бы использовал killall "Google Chrome", который в основном принудительно закроет приложение, уничтожив все PID.

заключение:Если у вас есть несколько PID для приложения, попробуйте killall, если присутствует только один PID, kill и killall будут работать одинаково.

0
25.05.2021, 17:33

Теги

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