Grep has become the standard name for any search tool that uses regular expressions. Whether you are talking about egrep, fgrep, cgrep, or both tre-agrep and Wu-Manber agrep, commands with names that contain "grep" make their basic functionality perfectly clear. So, naturally, when a command for finding processes was written, could it be called anything except pgrep [1]?

Pgrep has become a useful command because of the proliferation of processes in computing. Defined as an instance of a running program, a process (or task) can range from an essential program for the running of the operating system – traditionally called a daemon and owned by the root user – to a productivity application started by an ordinary user.

Just running the top command, which lists the processes that use the most system resources, regularly returns a list of 40 or 50 processes. Run pstree, which shows both parent and child processes, and the result is several screens full of information and more than 240 processes (Figure 1). The number of processes displayed can be reduced by running ps auS to show only currently active processes (Figure 2) or fuser to show the processes using a particular file or filesystem. But, if you have some idea of the name of the process you are looking for, pgrep can often be the most useful command for locating it.

Figure 1: Part of the pstree. Note systemd at the top level.

Figure 2: Even a summary of the most memory-intensive processes makes for a long list.

Pgrep's options can also be used with the pkill command to find and either stop a process or send another signal to it.

The Basic Command Structure

Pgrep mostly follows the standard command structure, with the options providing various filters to limit the results:

pgrep OPTIONS PATTERN

In its simplest form, pgrep returns a process ID for the specified process (Figure 3). At times, you might want to complete an option or pattern with a comma-separated list. For example, the option -u plw,bab confines the results to processes belonging to the users plw or bab.

Figure 3: Pgrep returns a Process ID.

Regular expressions are also used somewhat unusually. Like most grep-inspired commands, pgrep gains its power and flexibility through the use of regular expressions. Like other search programs, pgrep uses many of the same symbols as standard regular expressions, with . standing for any single character, * for any group of characters, ^ for the start of a line, $ for the end of a line, and a range of characters placed within square brackets for acceptable completions – for example, [0-9] or [apple | oranges].

Another unusual feature is that pgrep can be run at the same time as other commands. For example, a system administrator might change the priority of all Akonadi processes in KDE with the command:

renice +6 $(pgrep akonadi)

As you might expect, using pgrep beside another command can have unexpected results, so you should be especially careful which options and strings you use. For safety's sake, you might prefer to avoid using complicated extended regular expressions in these cases. An even safer precaution might be to run pgrep first and then the other command, so that you can check what processes will be affected before you run the other command. In either way, you can avoid surprises that complex extended expressions can sometimes bring.

Filtering Results By Options

Where extended regular expressions filter the names of the processes affected by pgrep, most of the options filter the characteristics.

If you have an idea of the process ID, you can force an exact match of the pattern you enter with --exact (-x). Conversely, if you are sure of the processes you do not want in the results, use --inverse (-v) PID. If you think you know the parent process of the one you seek, then using --parent (-P) PID might help to limit results.

You can also use other criteria. When a process might be associated with a particular session, try --session (-s) SID. Similarly, on a network, you might search by the name of terminal from which the process was started with --terminal (-t) TERMINAL. Those comfortable working with namespaces, such as ipic, mnt, net, pid, user, or uts, can set results to include only processes within the designated name space with --nslist NAMESPACE or group results by namespaces with --ns PID.

Still another approach is to search by when a process was started with --newest (-n) or --oldest (-o) without any string or regular expressions. Strangely, however, these two options cannot be used together or with --inverse, although the package maintainer promises in the man page to change this limitation if anyone needs it removed.

One of the most useful ways to filter with options is to confine the search to particular owners with --euid (-u) UID. If you know the user account running the process, this option eliminates false positives. Even more efficiently, by specifying processes belonging to the root user, you can confine a search to system processes. The user can be specified either by numerical value or by account name, so that, on the system I am writing on, I could find my own processes by specifying either 1000 – the numerical value traditionally given to the ordinary account created during installation – or bb. On servers, --group (-G) might be almost as handy, although probably not on a home workstation.

Another use of options is to change the results produced by a search. Ordinarily, search results give only the process ID, but if you add --list-name (-l), results include the process name as well (Figure 4). With --list-full (-a), the results show the full path to the process (Figure 5). At other times, you may simply want the number of matches, in which case your options should include --count (-c).

Figure 4: The --list-name option shows not only the default process ID but also the process name.

Figure 5: The --list-full option gives the complete path to the process.

Using the pkill Command

A common reason for locating a process is that it is misbehaving or not responding and needs to be shut down. Pkill [2], which originated in Solaris just as pgrep did, simplifies this set of tasks by using options and extended regular expressions in the same way as pgrep. However, as with kill or killall, pkill includes the option to terminate results with SIGKILL (2), so that one command does the job of two.

Entered without any options, pkill closes all processes that match results. Used carelessly, the pkill command can easily crash a system by closing a core process, meaning that, the more precise the pattern in the command, the less likely something unexpected will happen.

Unlike pgrep, pkill also includes the option --signal SIGNAL, which allows the sending of any other signal [3]. Most users will probably have few uses for this option, although on a network, a system administrator might use SIGINT (15) to close down the terminal of a misbehaving process or SIGCHILD (17) to close down a child of a parent process.

For most users, pkill is an extra with limited use. But, whether you administer one computer or thousands, pgrep is a much-needed addition to your toolkit. Learn even a handful of its basic options and tracking down processes becomes far easier.