Pourquoi pidof et pgrep se comportent différemment?

8

J'ai un script init /etc/init.d/myservicepour initialiser un service comme celui-ci:

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

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

Et quand j'essaie d'arrêter le service, voici la sortie:

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

Est-ce attendu? Pourquoi pidofne renvoie que le PID correct du service que je veux arrêter et pgreprenvoie le PID du service et le PID du script init? Puis-je compter sur cela pidofqui ignorera toujours le PID du script init?

Pigueiras
la source

Réponses:

7

pidof = trouver l'ID de processus d'un programme en cours d'exécution

Pidof trouve les identifiants de processus (pids) des programmes nommés. Il imprime ces identifiants sur la sortie standard. Ce programme se trouve sur certains systèmes utilisés dans les scripts de modification au niveau de l'exécution, en particulier lorsque le système a une structure rc de type System-V.

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

pgrep = rechercher ou signaler des processus en fonction du nom et d'autres attributs, pgrep examine les processus en cours d'exécution et répertorie les ID de processus qui correspondent aux critères de sélection.

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

pgrep, (p) = process, grep= grep imprime les lignes correspondantes

Vous souhaitez en savoir plus sur pgrep & pidof? Il suffit d'exécuter dans le terminal en tant que

# man pidof
# man pgrep
Babin Lonston
la source
1
Aha, c'est pourquoi pidofne revient pas 10001, parce que le programme est sh, non?
Pigueiras
oui, vous avez raison
Babin Lonston
0

Je pense que vous ne devriez pas compter pidof, cela peut entraîner l'échec de votre programme. Un exemple simple avec supervisordprogramme:

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

Vous pouvez voir, le supervisordest en fait appelé par l'interpréteur python, provoque l' pidoféchec:

#! /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
la source
Mais dans ce cas, je ne peux pas compter dessus?, Je n'utilise pas d'interpréteur pour exécuter le programme (c'est un binaire exécutable).
Pigueiras
Bien sûr. Mais je pense que la bonne façon est d'utiliser killproc. Pourquoi vous ne l' utilisez pas pendant que vous haved utilisé daemonen startfonction?
cuonglm
Parce que je veux obtenir le PID pour tuer les enfants du processus, j'utilisais killprocpour tuer le processus lui-même.
Pigueiras
Pourquoi devez-vous faire ça? si vous tuez parent process, sa child processvolonté mourra aussi.
cuonglm
Non, je ne pense pas: stackoverflow.com/questions/8533377/…
Pigueiras
0

La pidofcommande ignore les scripts sauf si vous incluez l' -xoption. De plus, il est plus sûr d'inclure le chemin complet sur la commande pidof, comme dans:

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

cela minimise les chances de faire correspondre un autre processus.

John Hascall
la source