Home / Alt manpages / pidof(8)

  • pidof(8)
  • Admin command
  • linux

Find and Verify Running Processes with pidof

A monitoring script that trusts the wrong PID can send a signal to the wrong process, so knowing exactly what pidof can and cannot guarantee matters. You will use it to find process IDs by program name, turn the result into a quiet health check, and reduce false matches when several programs share a name. The examples describe the installed sysvinit-utils version 3.08-6ubuntu3. Allow about ten minutes. You need a shell and permission to inspect the processes you are checking; most commands here are unprivileged.

Checkpoint

By the end, you should be able to answer both "which PIDs match this name?" and "did at least one match exist?" without accidentally treating arbitrary output as proof that the intended service is running.

1. Check the installed command

Confirm that the command is available and identify its package. This is a read-only check:

$ command -v pidof
/usr/bin/pidof
$ dpkg-query -W -f='${Package} ${Version}\n' sysvinit-utils
sysvinit-utils 3.08-6ubuntu3
  • It is actually killall5. On this installation, /usr/bin/pidof is a symbolic link to /usr/sbin/killall5. Use the name pidof in scripts regardless; the manual page is dated 1998, while the package version identifies the implementation currently installed on this machine.
  • It takes one or more program names. It prints matching PIDs separated by spaces and returns status 0 when at least one program was found, or status 1 when none was found.

2. List matching PIDs

Start with a common, harmless target. This may show more processes than you expect because other users or services can also be running the same program:

$ pidof sleep
1492041 1492040 1492011

The numbers above are illustrative output from one test host and will change. Do not copy them as real PIDs. If there is no matching process, pidof prints nothing. Check the status separately when the distinction matters:

$ pidof definitely-no-such-process
$ printf 'pidof status: %s\n' "$?"
pidof status: 1

With more than one program argument, output for all requested names is combined. The command does not label each number with its program name, so use one name at a time when an unambiguous audit trail matters.

3. Make a quiet presence check

Use -q when a script needs only a yes-or-no result. It suppresses matching PIDs and preserves the meaningful exit status:

if pidof -q sleep; then
    printf '%s\n' 'a sleep process exists'
else
    printf '%s\n' 'no sleep process found'
fi

pidof -q definitely-no-such-process
printf 'status for missing process: %s\n' "$?"
status for missing process: 1

This is an ordinary inspection command. It does not start, stop or signal the process. In a service check, use the service's exact executable name and treat status 1 as "not found", not as a shell error that should be hidden.

Checkpoint

For automation, prefer the exit status over parsing standard output. For a human listing, omit -q so the PIDs remain visible.

4. Limit or format the result

Use -s for a single PID. The option is useful when a caller accepts one representative match, but it does not prove that only one process exists:

$ pidof -s sleep
1492041

Use -d to choose a separator when more than one PID is printed. This can make the result easier to pass to a tool that expects a particular delimiter:

$ pidof -d , sleep
1492041,1492040,1492011

Do not assume the first PID is the oldest, newest or most important process. The manual guarantees the matching result, not an ordering policy. If your operation needs a specific process, verify it with a second inspection step such as ps before taking action.

5. Exclude a known PID

Use -o when a wrapper or monitoring script must ignore a particular process. You can supply one PID or a comma-separated list:

$ pidof -o 1492041 sleep
1492040 1492011

Replace the example number with a PID you have obtained in the current run. PIDs can be reused after a process exits, so do not keep an old omit list indefinitely.

The special value %PPID means the parent of pidof, normally the shell or script that called it:

$ pidof -o %PPID sleep

Shell scripts should quote variables that hold a PID list, but leave the literal %PPID as shown. Omission changes only this command's result; it does not stop or hide the process from the operating system.

6. Avoid name collisions

A bare name is not a strong identity check. The manual warns that pidof can return processes with the same name even when they are different programs. Symbolic links to executables also match because the running executable name is resolved through readlink.

When you know the exact executable path, pass that path instead of a short name:

$ pidof /usr/bin/pidof
1492084

A full pathname is described as reasonably safe by the manual, but still verify the result if the next action is sensitive. For a service, compare the PID with process details before sending a signal:

$ pidof -s PROGRAM_NAME
PID=1492084
$ ps -p "$PID" -o pid=,comm=,args=
1492084 pidof /usr/bin/pidof

Replace PROGRAM_NAME and the example PID with values from your host. Do not paste an untrusted name directly into a command string. Keep it as one quoted argument and validate any path your script accepts.

7. Understand privilege and unusual process states

The -c option restricts results to processes using the same root directory. It is ignored for non-root users when the relevant process belongs to somebody else, because that user cannot inspect the process's root directory. Use elevated privileges only when you have a specific reason to inspect processes outside your account:

$ pidof -c PROGRAM_NAME
$ sudo pidof -c PROGRAM_NAME

The second command may require an administrator password and is still only an inspection command. Do not use sudo as a generic fix for an unexpected empty result. First check the executable name, permissions and process ownership.

  • -z tries to detect zombie processes. Ordinary zombie processes and processes in disk sleep are normally ignored because inspecting their state can fail or hang. The installed manual states a risk of failure or hanging, so use it only for a controlled diagnostic, not as a default service check. It also notes that processes in uninterruptible disk sleep are now found whether or not -z is used.
  • -n avoids a stat call on network filesystems. On network filesystems, this avoids a stat call on binaries located on filesystems such as NFS. The same behaviour can be selected by exporting PIDOF_NETFS. This is an environment and filesystem concern, not a way to make name matching more precise.

8. Keep process control separate

pidof only finds processes. It does not stop them. If a later step uses the result with kill, pause and review the exact PID list first:

$ pidof -d ' ' PROGRAM_NAME
$ ps -p PID -o pid=,user=,comm=,args=

Warning

Never paste an unchecked result into a destructive command. A name collision could select an unrelated process, and a reused PID could now belong to something else. Prefer the service manager's own status and stop commands when the process is managed by one. The manpage specifically points to start-stop-daemon for System V style service scripts where it is available.

There is no undo operation for the examples in this guide because they do not change process state. If you later send a signal based on a PID, recovery depends on that program and its service manager; confirm the target and consult its documented restart procedure before doing so.

Done means

  • PIDs listed: you can list matching PIDs with pidof PROGRAM_NAME and distinguish no match with exit status 1.
  • Quiet check used: you use -q for a quiet presence check and -s only when one representative PID is sufficient.
  • Result shaped: you can omit known PIDs with -o and format output with -d.
  • Collisions avoided: you use a full executable path, then verify with ps, when a short name could match the wrong program.
  • Edge cases understood: you understand that -c, -n and -z have specific inspection trade-offs and do not require changing a service.
  • No blind signals sent: you have not sent a signal or used elevated privileges without first checking the exact target.