Greater grokking of pgrep
Process Finder
![](/var/linux_magazin/storage/images/issues/2016/187/command-line-pgrep/78002271_7.png/671251-1-eng-US/78002271_7.png_medium.png)
Pgrep is a valuable tool for tracking down processes.
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.
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
.
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
).
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.
Bruce Byfield
Bruce Byfield is a computer journalist and a freelance writer and editor specializing in free and open source software. Bruce's most recent book, Designing with LibreOffice, was released under a Creative Commons License in March 2016. You can buy or download his book at http://designingwithlibreoffice.com/download-buy/. In addition to his writing projects, he also teaches live and e-learning courses. In his spare time, Bruce writes about Northwest Coast art. You can read more of his work at http://brucebyfield.wordpress.com.
Infos
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
![Learn More](https://www.linux-magazine.com/var/linux_magazin/storage/images/media/linux-magazine-eng-us/images/misc/learn-more/834592-1-eng-US/Learn-More_medium.png)
News
-
NVIDIA Released Driver for Upcoming NVIDIA 560 GPU for Linux
Not only has NVIDIA released the driver for its upcoming CPU series, it's the first release that defaults to using open-source GPU kernel modules.
-
OpenMandriva Lx 24.07 Released
If you’re into rolling release Linux distributions, OpenMandriva ROME has a new snapshot with a new kernel.
-
Kernel 6.10 Available for General Usage
Linus Torvalds has released the 6.10 kernel and it includes significant performance increases for Intel Core hybrid systems and more.
-
TUXEDO Computers Releases InfinityBook Pro 14 Gen9 Laptop
Sporting either AMD or Intel CPUs, the TUXEDO InfinityBook Pro 14 is an extremely compact, lightweight, sturdy powerhouse.
-
Google Extends Support for Linux Kernels Used for Android
Because the LTS Linux kernel releases are so important to Android, Google has decided to extend the support period beyond that offered by the kernel development team.
-
Linux Mint 22 Stable Delayed
If you're anxious about getting your hands on the stable release of Linux Mint 22, it looks as if you're going to have to wait a bit longer.
-
Nitrux 3.5.1 Available for Install
The latest version of the immutable, systemd-free distribution includes an updated kernel and NVIDIA driver.
-
Debian 12.6 Released with Plenty of Bug Fixes and Updates
The sixth update to Debian "Bookworm" is all about security mitigations and making adjustments for some "serious problems."
-
Canonical Offers 12-Year LTS for Open Source Docker Images
Canonical is expanding its LTS offering to reach beyond the DEB packages with a new distro-less Docker image.
-
Plasma Desktop 6.1 Released with Several Enhancements
If you're a fan of Plasma Desktop, you should be excited about this new point release.