Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 5 down vote accepted

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
share|improve this answer
Aha, that is why pidof is not returning 10001, because the program is sh, no? –  Pigueiras Feb 27 at 9:33
yeap, you right –  Lonston Feb 27 at 9:35

I think you shouldn't rely on pidof, it can cause your program failed. 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 failed:

#! /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')()
share|improve this answer
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 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 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 at 10:34
Why must you do that? if you kill parent process, its child process will died, too. –  cuonglm Feb 27 at 10:42
No, I don't think so: stackoverflow.com/questions/8533377/… –  Pigueiras Feb 27 at 10:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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