As long-term computer users, we've certainly had to use something like Windows' Task Manager, at least a few times. An application becomes unresponsive, or slow, or simply misbehaves. And clicking on that "X" button just doesn't work. So we fire up Task Manager, right-click on the "bad app", and "End task" it.

But what's the Linux equivalent to Task Manager? When all we have is an SSH connection to some remote Linux server? And just a command line to play in?

The command to kill any process on Linux, based on its PID (identifier) number, is:

sudo kill -9 1149

Where -9 is a shortcut to the SIGKILL (force-kill signal). And 1149 is the PID. Of course, we'd replace 1149 with whatever applies to our specific scenario.

In this guide, we'll answer questions like these:

• How do I find the PID of the process I want to terminate? Based on the process name.
• How do I find the PID of the process with the highest CPU utilization?
• How do I find and terminate a process that is listening to a certain port?
• How do I gracefully terminate / stop a process on Linux?
• How do I force-kill it if a graceful terminate does not work? (process unresponsive / stuck).
• What if it's a long-running process that should be restarted, how do I terminate, and then re-initialize that process (with systemd).

Let's go through all of that.

Step 1 – Find the PID of the Process

The first thing that we need to find is the so-called PID of that process. Think of it as Process IDentifier. A number that uniquely identifies this process, and only this process. No other process will have the same PID.

Scenario 1 – Find the PID Based on the Process, or Application Name

Let's say that we noticed our web server is stuck. Just hangs when we try to retrieve a web page. So we suspect something went wrong with our Nginx application. Knowing this name, nginx, here's what we can do.

First, we look for all processes which have nginx in their name (replace nginx in the next command with whatever applies to your situation):

pgrep -a nginx

The -a option tells the pgrep command to show us additional information. Without it, we'd only see the PID numbers, but nothing else.

We get this output:

This is a (somewhat) special case, because there are 3 processes that the Nginx application has started. Most applications will start just one process. But in this scenario, there are three:

• The main process with PID 1954.
  • And another two child processes with PIDs 1955 and 1962.

In such cases, we're interested in interacting with the main / parent process. PID 1954, in the example above.

Scenario 2 – Find the PID of the Process with the Highest CPU Usage

In some cases, we won't know what application is actually causing issues. We won't know its name. We might be thinking that:

Something is slowing down this server. But I'm not sure what process is doing that.

What we can do is look at what is intensively using our CPUs. We can do that with the top command:

top

A lot of data will show up. But there's no reason to feel overwhelmed. All we need to focus on is this part:

Our focus should be on the %CPU column. In this example, we have just two processes with higher-than-normal CPU usage (21.6% and 20.6%). One has PID 207112. And one has PID 26048.

top will periodically refresh this data. So we can get an idea on what is constantly using a lot of CPU power. Since some things might spike up at the top of this table, but then quickly disappear. For example, maybe our server gets a database request. And we might see the "mysql" process quickly spike up for a share of 50% of one CPU core. But if it goes down in a second, then it's probably not what is causing the issue.

Look at what is persistently showing up with a very high amount of %CPU usage. It's relative what counts as "very high". But if it's a program that shouldn't do much, and it's constantly up there with 80-160% CPU usage, or more, for no good reason, then it's probably stuck in a loop. Or misbehaving in some way.

Note the PID of the offender, and continue to the next step.

In our example, 1954 is the PID we care about (the master process started by the Nginx application). Now, what do we do with it?

Step 2 – Terminate the Process with systemd or the "kill" Command

Most of the long-lived processes on Linux are managed by something called systemd. Or, at least, a part of it does that. Since systemd covers many other responsibilities. Think of this part as a "manager" that makes sure certain applications are started at the right times. And that their processes have a long, healthy life. Also, if anything goes wrong, systemd will try to restart those processes, or take corrective actions (if it can).

Not all Linux distributions use systemd, but most of them do.

How do we check if our process is managed by systemd? Easily enough, we just run the systemctl status command, followed by the PID we found.

In our case, it would be:

systemctl status 1954

If the process with that PID is managed / monitored by systemd, we will get output like this:

Note the highlighted text, nginx.service. That's the unit name / file that defines how this process should be managed by systemd. Remember this ".service" name, it will be important later.

If that process is not managed by systemd, we'll get a message like this:

Scenario 1 – Gracefully Terminate the Process with systemd

If the process is managed by systemd, it's recommended to try to stop that process with systemd itself.

So, how do we tell systemd to gracefully stop a process? Well, remember when we ran our systemctl status command on the 1954 PID? We got this output:

Telling us that the process is managed by a so-called service unit called nginx.service. We use this name in our next command.

We can tell systemd to stop all the processes managed by this service unit with this command:

sudo systemctl stop nginx.service

Remember to replace nginx.service with whatever applies to your specific scenario.

sudo in our command above is added to get the administrative privileges required to run the systemctl stop command.

And we can check if this did the job:

systemctl status nginx.service

Ideally, we should see something like this:

Main PID: 1954 (code=exited, status=0/SUCCESS)

Indicating that the process was closed gracefully.

At the very least, we should see this:

Active: inactive (dead)

Inactive and (dead) tell us that the process was successfully terminated.

Another way to confirm that all the processes with the "nginx" name were terminated is to run the same command we ran earlier:

pgrep -a nginx

If it outputs nothing, job done!

Now, just in case we need Nginx back online, we can start it up again, with systemd:

sudo systemctl start nginx.service

And we can recheck the status of that service unit:

systemctl status nginx.service

active (running) is what we want to see for a long-lived process like Nginx.

Now let's move on to the next scenario.

Scenario 2 – Terminate the Process Using the "kill PID" Command

• Maybe the process is managed by systemd, but the systemctl stop command did not work.
• Or the process is not managed by systemd.
• Or the Linux distribution does not use systemd at all.

In either case, this time we'll go a different route: Interact with that process directly, without the help of systemd.

Let's say the PID of the process we want to stop is 778 this time. So just replace 778 in the next commands with whatever applies to you.

The first step we can try with a misbehaving process:

Method 1 – Try to Terminate the Process Gracefully (SIGTERM)

We can run this command to try to gracefully terminate (stop) a process on Linux:

sudo kill -s SIGTERM 778

This sends it a so-called signal, called SIGTERM. Which is a way to tell a process:

Hey, can you please close yourself, normally? Save your data, do whatever you need to do, and then exit.

No error output means that the SIGTERM signal was sent. But just because a signal is sent does not mean that the application acted on it. A signal is a request, that an application can fulfill, or not.

So we should check if the process with PID 778 was closed, by running:

ps 778

If it looks like this, with no content under the PID, STAT, COMMAND columns, then the process was closed:

Essentially, SIGTERM is a "nice" signal. It just politely asks the process to close itself. And it's up to the process to also be polite, and listen to the request.

Which means, if the application is stuck in some way, then it might ignore SIGTERM, and not close itself. So it's time to bring out the big guns: The SIGKILL signal!

Method 2 – Forcefully Terminate the Process with SIGKILL

SIGKILL should only be used as a last resort. When there's just no other way to close that process. Why?

• Because SIGTERM allows the application to save its data and close normally.
• But SIGKILL is brutal. It instantly kills the process, without allowing it to save data, or wrap up whatever it was doing. Which brings a small chance of data corruption, or rather, incomplete data, if the process was working on something and it was killed in the middle of that.

Think of SIGTERM as normally shutting down your computer. And SIGKILL as pulling the power cable (and battery) from your computer, or pressing the reset button. Of course, the "computer" in this case is the process we're working with.

Either way, SIGKILL cannot be ignored by a process. So when we send a SIGKILL, it's usually a guarantee that the process will be closed. There can be exceptions in some edge-cases, but >99% of the time, it will work.

So, no other solution to terminate that misbehaving process? Alright. To force-kill a process on a Linux machine, run the sudo kill -s SIGKILL command, followed by the PID of the process. For something with PID 1367, we'd run:

sudo kill -s SIGKILL 1367

On my test machine, I ran this on the Nginx process. Note how even systemd tells me that something was not quite right when this process exited. When I run the systemctl status nginx command, this is the output:

But, for processes that have gone off the rails, and are just not responding to any other methods, a SIGKILL might be the right solution.

And, just as a reminder: If this was a process managed by systemd, and you need it back up, you can use its service name to start it again:

sudo systemctl start nginx.service

Frequently Asked Questions (FAQ)

How do I Kill a Process Based on its Name?

To gracefully terminate all processes with a certain name, we can run the sudo pkill --signal SIGTERM command, followed by the name of the process. For example, if the process name is nginx, we'd run:

sudo pkill --signal SIGTERM nginx

Replace nginx with the name that applies to your situation.

To forcefully terminate all processes with a certain name:

sudo pkill --signal SIGKILL nginx

However, it's NOT RECOMMENDED to do it this way. Why? Because multiple processes might have the same name. And we might end up terminating more processes than intended.

For example, let's say we want to kill the process called bash. But if we search for entries with this name, look how many processes we might get:

pgrep -a bash

One of them might be our login shell. One might be the login shell of another user. Another might be running a script.

One pkill command and it will terminate all of these things. We get suddenly logged out. The other user is disconnected from the server as well; maybe losing work progress. The script that was doing important stuff is also closed – pretty bad day.

Instead of killing a process based on its name, follow the first steps described at the beginning of this blog. As in:

• First, find the PID of ONE process you want to close.
• Then use that PID to close the process.

How Do I Kill a Process Based on the Port Number It's Using?

More specifically, a process can attach to a certain port. To listen for incoming connections on that port, and then service them.

First thing's first. To see all the processes listening for incoming connections on TCP and UDP ports, we can run this command:

sudo ss -ltunp

Regarding the -ltunp options passed to the ss command, this is what each letter means:

• l is for listening.
• t is for TCP.
• u is for UDP.
• n is for numerical (to show port numbers like "22" instead of names like "ssh").
• p is for process.

We get output like this:

TheLocal Address:Port column is what we should look at. Seeing something like :80 in there tells us that a process is listening on port 80. And if we look in the Process column, it tells us that a process called nginx is listening on port 80, with a PID of 1819.

To filter only processes that are listening on a certain port, like port 80, for example, we could pipe this output to grep:

sudo ss -ltunp | grep ':80'

Telling grep to only show us stuff that contains :80 on a line, we end up with output like this:

Or, to filter only processes listening on port 22, we could run:

sudo ss -ltunp | grep ':22'

Just replace :80, or :22 with whatever you need.

Either way, after we run a command like:

sudo ss -ltunp | grep ':80'

We should note the PID:

In many cases, there will be a single PID listed on a line. But some applications can start up multiple processes, as we can see here. In such cases, we want to work with the parent process, so that it's children are terminated as well. If we see multiple PIDs (on a single line), we should choose the one with the lowest number, as that's usually the parent process (first one to start has lower PID).

Once the PID is extracted, just follow the steps described earlier in our guide (see the steps to stop a process with systemd first).

In the last screenshot, the PID of the process attached to port 80 is 1817. So, without systemd, one command to gracefully close the process would be:

sudo kill -s SIGTERM 1817

And to forcefully close the process, if SIGTERM didn't work:

sudo kill -s SIGKILL 1817

Hope this helped. Happy process hunting!

If you feel like something is unclear in this guide, please add a suggestion in the comments. Thank you!