Почему pidof и pgrep ведут себя по-другому?

У меня есть сценарий инициализации в /etc/init.d/myservice для инициализации службы следующим образом:

 ... start() { ... daemon /usr/sbin/myservice ... } stop() { ... pgrep myservice pidof myservice ps -ef | grep myservice ... } 

И когда я пытаюсь остановить службу, это результат:

 10000 10001 10000 root 10000 1 0 09:52 ? 00:00:02 /usr/sbin/myservice root 9791 9788 0 10:06 pts/1 00:00:00 /bin/sh /sbin/service myservice stop root 10001 9791 1 10:06 pts/1 00:00:00 /bin/sh /etc/init.d/myservice stop root 9805 9796 0 10:06 pts/1 00:00:00 grep myservice 

Ожидается ли это? Почему pidof возвращает только правильный PID службы, которую я хочу остановить, и pgrep возвращает PID службы и PID сценария инициализации? Могу ли я полагаться на то, что pidof всегда будет игнорировать PID из сценария инициализации?

3 Solutions collect form web for “Почему pidof и pgrep ведут себя по-другому?”

pidof = найти идентификатор процесса запущенной программы

Pidof находит идентификатор процесса (pids) названных программ. Он печатает эти идентификаторы на стандартном выходе. Эта программа используется в некоторых системах, используемых в сценариях сценариев на уровне выполнения, особенно когда система имеет структуру Rc, похожую на System-V.

 sysadmin@codewarden:~$ pidof apache2 5098 5095 5094 5092 

pgrep = поиск или сигнальные процессы на основе имени и других атрибутов, pgrep просматривает текущие процессы и перечисляет идентификаторы процессов, которые соответствуют критериям выбора.

 sysadmin@codewarden:~$ pgrep apache2 5092 5094 5095 5098 

pgrep , (p) = process, grep = grep печатает соответствующие строки

Хотите узнать больше о pgrep & pidof? Просто запустите терминал

 # man pidof # man pgrep 

Я думаю, вы не должны полагаться на pidof , это может привести к сбою вашей программы. Простой пример с программой supervisord :

 % cuonglm at ~ % ps -ef | grep supervisord root 8512 1 0 16:53 ? 00:00:00 /usr/bin/python /usr/bin/supervisord cuonglm 8584 7688 0 17:00 pts/0 00:00:00 grep --color=auto supervisord % cuonglm at ~ % pidof supervisord % cuonglm at ~ % 

Вы можете видеть, что supervisord pidof вызывается интерпретатором python, что приводит к сбою pidof :

 #! /usr/bin/python # EASY-INSTALL-ENTRY-SCRIPT: 'supervisor==3.0a8','console_scripts','supervisord' __requires__ = 'supervisor==3.0a8' import sys from pkg_resources import load_entry_point if __name__ == '__main__': sys.exit( load_entry_point('supervisor==3.0a8', 'console_scripts', 'supervisord')() ) 

Команда pidof игнорирует сценарии, если вы не включили опцию -x . Кроме того, безопаснее включать полный путь в команду pidof, как в:

 killme=$(pidof -x /usr/bin/supervisord) *instead of* killme=$(pidof -x supervisord) 

это сводит к минимуму вероятность сопоставления некоторого другого процесса.

Linux и Unix - лучшая ОС в мире.