Por que o pidof e o pgrep estão se comportando de maneira diferente?

Question

Eu tenho um script de inicialização em /etc/init.d/myservice para inicializar um serviço como este:

...
start() {
  ...
  daemon /usr/sbin/myservice
  ...
}

stop() {
  ...
  pgrep myservice
  pidof myservice
  ps -ef | grep myservice
  ...
}

E quando tento parar o serviço, esta é a saída:

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

Isso é esperado? Por que pidof está retornando apenas o PID correto do serviço que eu quero parar e pgrep está retornando o PID de serviço e o PID do script de inicialização? Posso confiar que pidof sempre irá ignorar o PID do script de inicialização?

    

Answer 1

pidof = encontra o ID do processo de um programa em execução

O Pidof encontra os ids do processo (pids) dos programas nomeados. Imprime    esses id estão na saída padrão. Este programa está em alguns sistemas    usado em scripts de mudança de nível de execução, especialmente quando o sistema tem um    System-V como a estrutura rc.

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

pgrep = procura ou sinaliza processos com base no nome e outros atributos,          O pgrep examina os processos atualmente em execução e lista os        IDs de processo que correspondem aos critérios de seleção.

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

pgrep , (p) = processo, grep = grep imprime as linhas correspondentes

Deseja saber mais sobre o pgrep & pidof? Basta executar no terminal como

# man pidof
# man pgrep

    

Answer 2

Acho que você não deve confiar em pidof , isso pode fazer com que seu programa falhe. Um exemplo simples com o programa 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 ~
% 

Você pode ver que o supervisord é realmente chamado pelo interpretador python, fazendo com que pidof falhe:

#! /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')()
    )

    

Answer 3

O comando pidof ignora os scripts, a menos que você inclua a opção -x . Além disso, é mais seguro incluir o caminho completo no comando pidof, como em:

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

isso minimiza as chances de corresponder a algum outro processo.