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

Eu tenho um script init /etc/init.d/myservicepara inicializar um serviço como este:

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

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

E quando tento interromper 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 pidofretornar apenas o PID correto do serviço que desejo parar e pgrepretornar o PID do serviço e o PID do script init? Posso confiar em que pidofsempre ignorará o PID do script init?

— Pigueiras
fonte

Respostas:

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

Pidof localiza os IDs de processo (pids) dos programas nomeados. Ele imprime esses IDs na saída padrão. Este programa está em alguns sistemas usados em scripts de alteração no nível de execução, especialmente quando o sistema possui uma estrutura rc semelhante ao System-V.

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

pgrep = consulta ou sinaliza processos com base no nome e outros atributos, o pgrep examina os processos em execução no momento e lista os IDs do 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 pgrep & pidof? Basta correr no terminal como

# man pidof
# man pgrep

— Babin Lonston
fonte

Ah, é por isso que pidofnão está voltando 10001, porque o programa é sh, não?

— Pigueiras 27/02

sim, você está certo

— Babin Lonston 27/02

Eu acho que você não deve confiar pidof, pois pode causar falha no seu programa. Um exemplo simples com o supervisordprograma:

% 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, o que supervisordé realmente chamado pelo intérprete python, causa pidoffalha:

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

— cuonglm
fonte

Mas, neste caso, posso confiar que não, não estou usando um intérprete para executar o programa (é um binário executável).

— Pigueiras 27/02

Claro. Mas acho que o bom caminho é usar killproc. Por que você não usar isso enquanto você haved usado daemonna startfunção?

— cuonglm

Como eu quero que o PID mate os filhos do processo, eu estava usando killprocpara matar o próprio processo.

— Pigueiras 27/02

Por que você deve fazer isso? se você matar parent process, a child processvontade também morreu.

— cuonglm

Não, acho que não: stackoverflow.com/questions/8533377/…

— Pigueiras

O pidofcomando ignora scripts, a menos que você inclua a -xopção 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 encontrar algum outro processo.

— John Hascall
fonte