Perché pidof e pgrep si comportano diversamente?

Ho uno script /etc/init.d/myservicedi inizializzazione per inizializzare un servizio come questo:

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

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

E quando provo a interrompere il servizio, questo è l'output:

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

È previsto? Perché pidofviene restituito solo il PID corretto del servizio che desidero interrompere e pgreprestituisce il PID del servizio e il PID dello script init? Posso fare affidamento sul fatto che pidofignorerà sempre il PID dallo script init?

pidof = trova l'ID di processo di un programma in esecuzione

Pidof trova l'ID di processo (pid) dei programmi indicati. Stampa gli ID sull'output standard. Questo programma è su alcuni sistemi utilizzati negli script di modifica a livello di esecuzione, specialmente quando il sistema ha una struttura rc simile a System-V.

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

pgrep = cerca o segnala i processi in base al nome e ad altri attributi, pgrep controlla i processi attualmente in esecuzione ed elenca gli ID di processo che corrispondono ai criteri di selezione.

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

pgrep, (p) = process, grep= grep stampa le linee corrispondenti

Vuoi saperne di più su pgrep & pidof? Corri nel terminal come

# man pidof
# man pgrep

Penso che non dovresti fare affidamento pidof, può causare il fallimento del programma. Un semplice esempio con il supervisordprogramma:

% 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 ~
% 

Si può vedere, il nome supervisordè effettivamente chiamato dall'interprete di Python, causa pidoferrori:

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

Il pidofcomando ignora gli script a meno che non si includa l' -xopzione. Inoltre, è più sicuro includere l'intero percorso nel comando pidof, come in:

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

questo riduce al minimo le possibilità di abbinare qualche altro processo.