Americas

  • United States
sandra_henrystocker
Unix Dweeb

Using pidof and pgrep to list process IDs

How-To
Dec 08, 20203 mins
Linux

The pidof and pgrep commands make selecting and using process IDs on the Linux command line painless.

Number 10, distressed type
Credit: Shelly Still / Getty Images

The pidof and pgrep commands provide listings of process IDs (PIDs) for process names that you provide as arguments. This post shows how to use these commands and illustrates the differences between them with a series of examples.

pidof

There are a number of ways to determine the PID of a process running on a Linux system, but the easiest is probably a command called pidof. Read this as “PID of” and you’ll have an easy time remembering it. Using this command, you can get the PID of a process by typing “pidof” and specifying the process name. For example:

$ pidof bash
1262005

If you were to run the ps command without arguments, you will get a list of the processes that you’re running in your current shell. The command below shows where the response above comes from:

$ ps
    PID TTY          TIME CMD
1262005 pts/0    00:00:00 bash

If more than one person is logged in and using bash, the response to that command will include all of the associated PIDs for bash processes, and you won’t necessarily know without some additional commands which PID belongs to your shell:

$ pidof bash
1265446 1262005

You could run a command like this to show just your shell:

$ ps | grep bash | awk ‘{print $1}’
1262005

To get a listing of PIDs for system processes like systemd, you could run a command like this one:

$ pidof systemd
1265265 1261815 1548 1

Notice that the output shows that four systemd processes are running. To display just one PID, you can add the -s option, but the pidof command will only then be providing the largest (more recently started) PID in the group.

$ pidof -s systemd
1265265

If you get no response when you use pidof, the process you are asking about either isn’t running or you mistyped its name.

$ pidof apache2
$

Interestingly, if you do a file listing for pidof, you’ll see that it’s nothing more than a symbolic link to another program, killall5 on this system.

$ which pidof
/bin/pidof
$ ls -l /bin/pidof
lrwxrwxrwx 1 root root 14 Feb 13  2020 /bin/pidof -> /sbin/killall5

Even so, the executable behaves very differently when it’s called pidof. When invoked with killall5, the command is one of a number of commands that is used to terminate processes. When referred to as pidof, it returns PIDs.

pgrep

The pgrep command works a lot like pidof, but there are some differences both in the content and the arrangement of its output. For example, when we use pidof to get a list of PIDs for systemd, we get a list like this one:

$ pidof systemd
1261815 1548 1

When we use pgrep, on the other hand, we get a vertical listing of the PIDs and see more entries. Why? Because pgrep acts more like grep. It looks for processes that contain the string that is provided as an argument, not just those that match the process name exactly.

$ pgrep systemd
1
1010
1548
171864
171907
172061
1261815

In the command below, you can see more details on the processes that the above command selected:

$ ps -eo pid,euser,comm | grep systemd
      1 root     systemd
   1010 root     systemd-logind
   1548 gdm      systemd
 171864 systemd+ systemd-resolve
 171907 root     systemd-journal
 172061 root     systemd-udevd
1261815 shs      system

Wrap-Up

Selecting process IDs can be very useful at times, and the pidof and pgrep commands keep you from having to pipe the output of commands to other commands to narrow down the output  to a list containing only process IDs.

Now see:

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.