Greater grokking of pgrep

Grep has become the standard name for any search tool that uses regular expressions. The original grep utility was a classic Unix tool that searched a file (or multiple files) for a string of alphanumeric characters. By adding wildcard characters and other regular expressions, the user could wield grep with great subtlety and power to find important information in logfiles, text files, and even output from other commands.

Linux power users and admins still use grep to search for system information. In fact, a whole family of grep-based tools have evolved to help users monitor and manage Linux systems. Tools such as egrep, fgrep, cgrep, and agrep all have slightly different features but are each tailored to a specific role as a search utility. What tool should you use to discover information about processes running on the system? What about pgrep [1]?

A typical Linux system might have 40-50 processes running at any moment. Even your little Raspberry Pi can have dozens of processes running at once. A process is any task executing on the computer, which might include an essential service running on the operating system, a server application offering services to the network, or even a desktop productivity application.

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 namespace 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.