Why pidof and pgrep are behaving differently?

Question

I have a init script in /etc/init.d/myservice for initialize a service like this:

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

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

And when I try to stop the service, this is the 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

Is this expected? Why pidof is returning only the correct PID of the service that I want to stop and pgrep is returning the service PID and the PID of the init script? Can I rely on that pidof will always ignore the PID from the init script?

score 8 · Accepted Answer · answered Feb 27 '14 at 09:29

pidof = find the process ID of a running program

Pidof finds the process id's (pids) of the named programs. It prints those id's on the standard output. This program is on some systems used in run-level change scripts, especially when the system has a System-V like rc structure.

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

pgrep = look up or signal processes based on name and other attributes, pgrep looks through the currently running processes and lists the process IDs which matches the selection criteria.

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

pgrep, (p) = process, grep = grep prints the matching lines

Want to know more about pgrep & pidof ? Just run in terminal as

# man pidof
# man pgrep

Aha, that is why `pidof` is not returning `10001`, because the program is `sh`, no? — Pigueiras, Feb 27 '14 at 09:33

score 0 · Answer 2 · edited May 04 '16 at 12:15

0

I think you shouldn't rely on pidof, it can cause your program to fail. A simple example with supervisord program:

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

You can see, the supervisord is actually called by python interpreter, causes pidof to fail:

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

edited May 04 '16 at 12:15

Lucas Azevedo

101
4

answered Feb 27 '14 at 10:04

cuonglm

150,973
38
327
406

But in this case I can rely on it no?, I am not using an interpreter to execute the program (it is a executable binary). – Pigueiras Feb 27 '14 at 10:23
Of course. But I think the good way is use `killproc`. Why you don't use this while you haved used `daemon` in `start` function? – cuonglm Feb 27 '14 at 10:31
Because I want to get the PID to kill the children of the process, I was using `killproc` to kill the process itself. – Pigueiras Feb 27 '14 at 10:34
Why must you do that? if you kill `parent process`, its `child process` will died, too. – cuonglm Feb 27 '14 at 10:42
No, I don't think so: https://stackoverflow.com/questions/8533377/why-child-process-still-alive-after-parent-process-was-killed-in-linux – Pigueiras Feb 27 '14 at 10:47
Just pass signal `-9` to `killproc`. – cuonglm Feb 27 '14 at 10:53
The `-9` is too aggressive for me :D – Pigueiras Feb 27 '14 at 11:08

score 0 · Answer 3 · answered Jun 05 '16 at 14:18

The pidof command ignores scripts unless you include the -x option. Also, it is safest to include the full path on the pidof command, as in:

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

this minimizes the chances of matching some other process.

Why pidof and pgrep are behaving differently?

3 Answers3