Computers didn’t always multi-task. Back then it was easy to identify an out of control process (hint: it was the only one running). These days, the moment you boot up your computer, you’re immediately running hundreds of processes. Every so often your fan will kick up to 11 and just like days of yore, there’s probably only a single rogue process to blame. Other times you go to up a development server only to find that something else is already using the same port, but you have no idea which process.
Ready to go sleuthing? Let’s talk about tracking down processes, all from the command-line!
Getting Started
This article assumes you’re on a Unix-like operating system and the tools discussed are already available to you. Sometimes we’ll need to use super user privileges, which hopefully you have as well.
None of the commands in this guide are destructive in nature. All we’re going to do is figure out the process ID of running processes. The process ID can be used for destructive purposes, like killing the job, but that’s for another article.
top
Arguably the easiest way to find out the ID of a process is by running top.
While not as elegant as some of the examples we’re going to go over, it’s often times more than enough to get you what you need:
$ top
Which will greet you a text-based process list similar to your favorite process explorer or activity monitor.
If this is your first time seeing top, it’s probably a lot to take in.
There’s information about users, up-time, system load, available CPU and memory and then below it all, a nice list of processes.
It should look similar to this:
top - 18:51:41 up 10 days, 21:37, 3 users, load average: 0.44, 0.41, 0.66
Tasks: 252 total, 1 running, 251 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.3 us, 0.6 sy, 0.0 ni, 97.9 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
MiB Mem : 32046.7 total, 15190.6 free, 3999.7 used, 12856.4 buff/cache
MiB Swap: 30517.6 total, 30162.4 free, 355.2 used. 26809.4 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8383 josh 20 0 809168 92024 72892 S 1.7 0.3 6:23.94 spotify
767 root 20 0 1924628 20336 3468 S 0.7 0.1 24:17.07 containerd
1217 josh 20 0 249872 36296 16636 S 0.7 0.1 277:54.68 Xorg
1262 josh 20 0 3550872 311932 109312 S 0.7 1.0 321:50.42 gnome-shell
11371 josh 20 0 492308 53716 37984 S 0.7 0.2 0:45.78 gnome-terminal-
756 root 20 0 1890252 45104 10644 S 0.3 0.1 27:54.94 dockerd
14727 josh 20 0 13576 4064 3204 R 0.3 0.0 0:00.03 top
32562 josh 20 0 1349028 362364 181136 S 0.3 1.1 2:17.46 brave
1 root 20 0 198492 7424 5412 S 0.0 0.0 8:58.26 systemd
The list of processes is probably jumping around quite a bit, due to how you have things sorted. The default behavior is to sort the processes by the amount of CPU being used. Because of this, a processes eating up all of your CPU will be right there at the top.
If you look to the left of the process list, you’ll see a column labeled PID. That columns is where you will find the process ID. In example above, process 8383 belongs to the spotify command. If my Spotify app was getting unruly, I could take care of business knowing that ID.
It’s worth noting that a lot of applications are multi-threaded and have multiple processes running at once. Web browsers are pretty notorious for this.
Just because an processes’ ID doesn’t mean you have the main thread’s ID. If you were to kill the process ID for Chrome and it’s not the main thread’s ID, you’d probably end up killing a single tab, or extension and not the whole thing.
pidof
Let’s say that I already had a suspicion that my Spotify app was being unruly. By knowing the name of the command, in this case spotify, I could use the pidof command to get the process ID:
$ pidof spotify
By default, pidof will list all of the processes that match the name. As mentioned earlier, a process may have multiple threads, so you may have to root around a bit to determine if you have the main thread or not.
Remember that Unix-like systems may recycle process IDs, so the PID order is not a good indicator for deducing which ID may belong to the main thread.
jobs
Thus far, we’ve been finding jobs in the global scope of our system. Sometimes you have a process running in the background of your current session that you need to track down.
To help simulate some tasks in our session, let’s run the following:
$ sleep 300 &
$ sleep 600 &
$ sleep 900 &
This will run the sleep command for 5, 10 and 15 minutes and throw each process into the background of our current session.
You probably noticed each of those commands returned a number that looks very similar to the process IDs we’ve been working with. As it turns out, when you background a process, you are given the process ID so you can return to it later.
For the sake of example, let’s say we didn’t know those process IDs and wanted to see the processes in our current session:
$ jobs
Which returns the currently running jobs in the session, the order of which they were run and their status. But wait, no process ID?!
To get the process ID to show up as well, you need to include the -p argument:
$ jobs -p
Giving us results that probably look similar to this:
[1] 15765 running sleep 300
[2] - 15773 running sleep 600
[3] + 15782 running sleep 900
lsof
Everything discussed thus far has helped us to identify rogue processes and processes that were backgrounded in our current session. One of the most frustrating things is trying to run a process or bring up a service only to find out that another process is already occupying the port.
Sure, you could just reboot your machine, but what’s the fun in that?
To easily track down which process is listening on a specific port, you can use the lsof command. By default, without any arguments, lsof is going to list all open files that belong to every open process.
Run lsof without any arguments just once to fully realize how much stuff is actually happening behind the scenes on your machine. When I ran lsof with time on my laptop, it took nearly 10 seconds to dump out everything. WOW.
Fortunately, we can pass in a few additional arguments and cut through the clutter to figure out which process is listening on a port:
$ sudo lsof -itcp:4000
The aforementioned lsof will return the process that is current listening on port 4000. The sudo is because we may not know which user account on the system may be holding the port.
Similar to top, the process ID is listed under the PID column.
Try it out, replace the port number with one that you know you have a process listening on.
What about ps?
If you’re a command-line junky like myself, you are probably wondering why ps didn’t make the list.
Between you and me, I think ps is absolutely amazing. So much so, that I think it deserves an in depth article all it’s own :)