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
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?


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

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
  • 1
    Aha, that is why pidof is not returning 10001, because the program is sh, no?
    – Pigueiras
    Feb 27 '14 at 9:33
  • yeap, you right Feb 27 '14 at 9:35

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__':                                                    
        load_entry_point('supervisor==3.0a8', 'console_scripts', 'supervisord')()
  • 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: stackoverflow.com/questions/8533377/…
    – Pigueiras
    Feb 27 '14 at 10:47

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.