Today we’re going to have an article that’s straightforward and simple and it will be about how you find an applications’s process ID (PID). This isn’t the article I want to write. This is a case where I have to write one article so that I can write another article. Otherwise, we’d end up with a two-thousand-word article that nobody would read.
Let’s start with the basics – and it is very, very basic…
Every process running on your Linux computer has a Process ID (PID from here on out). Each process has a unique PID. Curiously, not all PIDs are using resources. Some PIDs are sleeping. If you work at it and find the right dodgy application (I’m looking at you, Shutter), you can even find zombie processes that are darned near impossible to kill (which might be foreshadowing a future article).
Though, unlike the movies, zombie processes are perfectly okay. They just sit there consuming no resources. Plus, they don’t eat brains (or CPU power), nor do they devour human flesh. They don’t even spread to other processes. In fact, with all that information, maybe calling them zombie processes is a bad idea. It’s not my idea – and they do share one thing in common with zombies in that they can’t be killed. (Zombies are already dead. You can’t kill something that’s already dead!)
There are many ways to find the PID for any given process. You can probably crack open your system monitor and find quite a few listed right there. You won’t even need the terminal for that. Imagine that?!?
(Of course, we’ll be finding PIDs in the terminal. It’s just what we do.)
Find An Application’s PID:
Yup. We’ll need an open terminal. Chances are reasonably good that you can just press
The first thing we’re going to do is generate a giant list of running processes. The first column will be who owns the process (not always you) and the second column will be the PID. To generate this giant list, try this command in said terminal:
1 | ps aux |
It’s a pretty big list, isn’t it? Well, let’s use ‘grep’ to narrow that down quite a bit. You can pipe the output from the previous command into grep and that would look like this:
1 | ps aux | grep <process_name> |
Using Shutter as an example, the command would look like this:
1 | ps aux | grep shutter |
NOTE: You may find that you see multiple PIDs. That’s because there are multiple instances of the application running.
If you know the name of the process, you can also try pidof (which should also indicate what it does – it tells you the PID of an application).
So, let’s say we wanted to know the PID of bash. That command would look like this:
1 | pidof bash |
In my case, I get four different numbers because I have multiple terminals open, each using bash. No, I don’t consider four open terminals to be abnormal. Well, at least it’s fairly normal for me.
Finally, chances are pretty good that you have ‘pgrep’ available. I did a flip through some VMs and it appears to be installed by default on all the distros I checked. You can use pgrep to find a PID. That would look like this:
1 | pgrep <process_name> |
So, using Shutter as an example again, we’d try something like this:
1 | pgrep shutter |
Now, not all processes seem to want to be listed like this. For example, if you run the ps aux command, you might have seen processes with weird names like this:
1 | /usr/libexec/gvfsd-mtp --spawner :1.3 /org/gtk/gvfs/exec_spaw/171 |
You go ahead and put that into pgrep and let me know if it works for you! It doesn’t work here. But, if you tried pgrep gvfs it will spit out some PIDs for you. At that point, you’re officially above my pay grade. I am not sure and I do not know everything. I did some searching, like a good 30 minutes worth of searching, and didn’t find anything conclusive.
If you happen to know what’s going on, let me know in the comments! Someone is always happy to let me know what I missed (and I’m so grateful for that, I really am.) I swear, I learn more from writing these silly things than you learn from reading them.
Closure:
Well, have you ever needed to know the PID? It’s a pretty useful thing to know, which I’ll cover in a future article. I didn’t want to write some giant 2000-word article only to have folks gloss over the important bits. Sure, it’d make a nice segue to the next article, but you know darned well that I’m unlikely to write the articles in order. I get bored easily!
Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.
