How to Kill a Process (Terminate a running process) in Linux

Let’s spend a few minutes discussing How you go about killing a running process on a Linux system from the shell prompt.

Introduction

Now normally you don’t do this instead you would use the appropriate exit function that’s coded into nearly all applications to end its process.

For example, if I were in the vi editor and I wanted to get out I would enter a colon (:) to enter into command line mode and then enter exit or q! to end the vi process.

How to kill a Process in Linux

However, there are times when exit function won’t work.

For example, you may have a process that is hung and no matter what you do you cannot get that process to exit out properly.

In this situation you may need to manually kill that hung process.

There are two different ways that you can do this.

One way is to use either the kill or the killall command another option is to use the pkill command.

Suggested Read:

Terminating Processes Using the kill Command

So, let’s begin this lesson by looking at the kill command.

As its name implies the kill command is used to terminate a running process and the syntax is shown here.

We enter kill and then a dash (-) and then we enter which kill signal we want to send followed by the process ID number of the process that we want to get rid of.

Syntax: kill -signal PID

Different types of kill signals

Now understand that the kill command is very flexible, you actually have about 64 different types of kill signals that you can send to a process.

# kill -l
 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
 6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM
16) SIGSTKFLT	17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
21) SIGTTIN	22) SIGTTOU	23) SIGURG	24) SIGXCPU	25) SIGXFSZ
26) SIGVTALRM	27) SIGPROF	28) SIGWINCH	29) SIGIO	30) SIGPWR
31) SIGSYS	34) SIGRTMIN	35) SIGRTMIN+1	36) SIGRTMIN+2	37) SIGRTMIN+3
38) SIGRTMIN+4	39) SIGRTMIN+5	40) SIGRTMIN+6	41) SIGRTMIN+7	42) SIGRTMIN+8
43) SIGRTMIN+9	44) SIGRTMIN+10	45) SIGRTMIN+11	46) SIGRTMIN+12	47) SIGRTMIN+13
48) SIGRTMIN+14	49) SIGRTMIN+15	50) SIGRTMAX-14	51) SIGRTMAX-13	52) SIGRTMAX-12
53) SIGRTMAX-11	54) SIGRTMAX-10	55) SIGRTMAX-9	56) SIGRTMAX-8	57) SIGRTMAX-7
58) SIGRTMAX-6	59) SIGRTMAX-5	60) SIGRTMAX-4	61) SIGRTMAX-3	62) SIGRTMAX-2
63) SIGRTMAX-1	64) SIGRTMAX

Some are very kind and gentle some are very brutal, some of the most useful kill signals are shown here.

  • SIGHUP (1)
  • SIGINT (2) – Equivalent of pressing CTRL+C on the keyboard.
  • SIGKILL (9)
  • SIGTERM (15)

SIGHUP (1):

The first one you need to be familiar with is SIGHUP or Signal Hang-up it’s what it stands for.

This is kill signal number 1 so that’s a very kind and gentle kill signal.

SIGINT (2):

Another one you can send is the SIGINT kill signal, this is kill signal number 2.

This one does try to stop the process, but it does so very politely.

This is the equivalent of pressing CTRL+C on the keyboard to stop a process from running, If the process is behaving properly it should respond if it’s not it probably won’t.

SIGTERM (15):

If you need to get a little meaner you can use SIGTERM or kill signal 15, now this signal tells the process to terminate immediately.

In fact, if you don’t specify a signal here with the kill command this is the one that will be sent by default.

The key thing to remember about SIGTERM kill signal 15 is the fact that it tries to be a little bit polite and it allows the process to clean up after itself as it’s exiting.

SIGKILL (9):

Now for some processes that get hung they’re not going to respond to either SIGINT or SIGTERM in which case you’re going to have to go to SIGKILL, this is kill signal number 9.

This one is a lot more brutal, if you have a process that’s hung, and it’s hung badly this option will force it to stop.

And as I said it’s kind of a brute force signal because if you executed it against a process that’s hung it does not really give the process an opportunity to clean up after itself.

When I say clean up after itself, I’m talking about freeing up resources that may have been allocated to that process such as memory addresses associated with that process.

Those resources are going to remain allocated to the process that you killed until you restart the system itself.

Note: Now when you run the kill command you can use either the name of the kill signal or you can use the number of the kill signal either one works just fine.

One important thing to remember about using the kill command is the fact that you do have to specify the Process ID (PID) number of the process that you want to kill.

Therefore, more than likely you’re going to need to use ps command or possibly top command at the shell prompt to first identify the Process ID (PID) number of the process that you want to kill.

# ps -elf
F S UID          PID    PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
1 I root           8       2  0  60 -20 -     0 -      May11 ?        00:00:00 [mm_percpu_wq]
1 S root           9       2  0  80   0 -     0 -      May11 ?        00:00:03 [ksoftirqd/0]
1 I root         484       2  0  60 -20 -     0 -      May11 ?        00:00:00 [ttm_swap]
0 S helpdesk   40156   30633  1  80   0 - 140623 x64_sy 22:56 ?       00:00:00 /usr/bin/gedit --gapplication-service
0 R root       40187   32751  0  80   0 - 14455 -      22:56 pts/0    00:00:00 ps -elf
4 S root       32746   31257  0  80   0 - 33371 -      14:52 pts/0    00:00:00 su
4 S root       32751   32746  0  80   0 -  6730 -      14:52 pts/0    00:00:00 bash

You can use the following to accomplish the similar information.

# pidof gedit
40156

In this example, I have the gedit program running it’s, Process ID number is 40156.

If I wanted to kill that process, I would enter kill followed by the signal that I want to send followed by the Process ID (PID) number that I want to kill.

# kill -SIGTERM 40156

Now notice that I used SIGTERM in this command that’s the same as signal 15, which basically allows gedit to clean up after itself as it’s exiting freeup any system resources that we are allocated to it.

This will allow the gedit process to exit out cleanly.

Correct sequence to use the kill signals

Now this brings up a mistake that I’ve seen many new Linux system administrators make when they start working with the kill command.

They just want to bypass all the polite kill signals and go right for the mean brutal ones they’re going for the jugular first.

Now this it really isn’t the best way to do things.

Yes, using SIGKILL will work most of the time but it’s actually better if you try the other cleaner more polite signals first.

Only if these kill signals fails you should try a more brutal kill signal.

If you experience a hung process that has to be killed with the kill command, I suggest you use the sequence that you see here.

  • Send a SIGINT.
  • Send a SIGTERM.
  • Send a SIGKILL.

First try sending a SIGINT kill signal with the kill command, just see if the process responds.

If it doesn’t then try sending it a SIGTERM kill signal.

Now my experience has been that usually Nine times out of Ten this actually fixes the problem and it’s better because it allows that process to exit cleanly, freeing up any resources that were allocated to it.

But on rare occasions you may find that SIGTERM doesn’t work in which case you need to go on to step three and then get mean with it and send it a SIGKILL.

Terminating Processes Using the killall Command

Now in addition to kill there is a second command you can use to kill processes that is the killall command.

Now killall is very similar to kill, in fact the syntax is almost the same.

Syntax: killall [-signal] [command_name]

The key difference is the fact that with killall you specify the command name of the process to be killed instead of its Process ID (PID) number.

For example, here once again we need to kill that gedit Process, I’m going to send it a kill signal 15.

# ps -elf
F S UID          PID    PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
1 I root           8       2  0  60 -20 -     0 -      May11 ?        00:00:00 [mm_percpu_wq]
1 S root           9       2  0  80   0 -     0 -      May11 ?        00:00:03 [ksoftirqd/0]
1 I root         484       2  0  60 -20 -     0 -      May11 ?        00:00:00 [ttm_swap]
0 S helpdesk   40156   30633  1  80   0 - 140623 x64_sy 22:56 ?       00:00:00 /usr/bin/gedit --gapplication-service
0 R root       40187   32751  0  80   0 - 14455 -      22:56 pts/0    00:00:00 ps -elf
4 S root       32746   31257  0  80   0 - 33371 -      14:52 pts/0    00:00:00 su
4 S root       32751   32746  0  80   0 -  6730 -      14:52 pts/0    00:00:00 bash

To do this with killall I enter kill all -15 followed by the name of the process that is gedit and this will send the signal to the process named gedit.

# killall -15 gedit

Basically, it allows you to kill the process without having to figure out what its Process ID (PID) number is.

Type the following command to terminate all processes running as a user helpdesk.

# killall -u helpdesk

Now I strongly suggest that you spend a little bit of time looking at the man page for both kill and killall, both of these commands are quite extensive and there are a lot of different things you could do with it.

Terminating Processes Using the pkill Command

In addition to the kill and killall commands you can also use another command to kill running processes and that’s the pkill command.

Now the pkill command is a close cousin of the pgrep command.

Infact if you look at the man page for pkill you’ll see that it’s exactly the same man page as that for pgrip.

The two commands use exactly the same man page and use the exact same options.

pkill is really useful, you can use pkill to search for processes that match a specific search criteria that you specify and then send those matching processes a particular kill signal.

In this example, I needed to search through all of my running processes for any process whose name contains the term gedit.

I actually have one, but it is possible that could have multiple processes that have gedit in their name.

To find all of those processes I would enter pkill followed by the kill signal, I want to sand either the name or Process ID (PID) number.

Syntax: pkill -signal [options] [command_name] / [PID]

In this case we’re gonna send kill signal 15 SIGTERM and then specify the term that I want to search for in the name which case I’m looking for word gedit.

# pkill -SIGTERM -f gedit

This will kill every process that has gedit in its Process name.

Type the following command to kill only the gedit processes owned by the user helpdesk.

# pkill -SIGTERM -u helpdesk gedit

nohup Command: How to keep a process running

The last topic we need to address before we end this lesson is that of How to keep a process running even if you log out from the system.

Now as we’ve discussed various signals can be sent to running processes to indicate that a system event of some type has occurred and that the process needs to respond in some way.

A very commonly used signal is the Hang-up signal which we’ve talked about earlier in this lesson SIGHUP.

Now understand that Linux keeps track of which processes are being run by each shell session.

And when a user logs out of a shell session Linux will send a signal to all the programs associated with that shell session.

Now normally each process will respond as it’s supposed to when it receives a signal however, a process can also be told to ignore any SIGHUP signals which will allow it to remain running even if you log out of your shell session.

One way to do this is to use the nohup utility, now nohup stands for no Hang-up.

For example, let’s suppose I’ve created a shell script called updatemydb.sh that automatically updates a local database with information from an external data source.

Now the script takes a long time to run it may take three or four hours and I’m leaving for the night and I really don’t want to leave my system logged in while it runs nor do I want to stay here for three or four more hours waiting for it to finish.

In order to let it run and for me to be able to log out and leave I could enter nohub at the shell prompt followed by the command that I want to run updatemydb.sh and I’m going to run it in the background with the ampersand (&) command.

# nohup updatemydb.sh &

I can then go ahead and log out and even though I’ve logged out the process created by this command will continue to run.

Now because the shell session where I ran the command from is going to be gone while I log out, we’ve got a problem if the command generates something that’s sent to the standard out such as text on the screen like command was successful or whatever or if there was an error message going to the standard out.

Because the shell sessions gone standard out and standard error have no place to display their information.

Therefore, if the command generates output that is sent to the standard out or standard error what nohup will do is redirect the standard out or standard error to a text file in your home directory called nohup.out (~/nohup.out).

And you can look at it after the command is done when you come back in the morning and make sure everything ran properly.

Now it’s important to note that any command that you run with nohup is only immune to signal Hang-up signals (SIGHUP), all other kill signals will still work.

For example, I could run updatemydb.sh with nohup but then still send a SIGKILL signal with kill and it will respond it’ll shut down.

Launch and use multiple shell sessions over the network using SSH

Now another command you can use to accomplish a similar thing is the screen command.

If you do not have screen installed on your Linux system, then you must run the following command to install this utility.

Redhat/CentOS based systems:

# yum -y install screen

Debian/Ubuntu based systems:

$ sudo apt-get install screen

The screen command is kind of interesting and it’s very useful especially if you’re accessing a Linux system remotely over the network using an SSH connection.

The key benefit of screen is it allows you to use multiple shell windows from within a single SSH session.

This is especially beneficial because it can keep an SSH shell active even if the network goes down so whatever it was you were running will continue to run even though you’ve lost your connection.

You can even use screen to disconnect and then reconnect to a particular shell session from different location without having to stop and then restart whatever process you were working on.

Now you run screen by simply entering the screen command at the shell prompt after you do so you’ll see a shell prompt displayed.

And it doesn’t look any different than the shell prompt you were working with before, however it is different because now you’re inside of a screen window instead of within the shell session itself.

And the window functions just like a normal shell session, you can run commands and interact with programs just as you would from any other shell prompt.

However, you can do other things.

If you press CTRL + a within the screen window, then whenever you type after CTRL + a will be sent to the screen process instead of for whatever process you’re running in the shell session.

For example, if you press CTRL + a followed by c it will cause a new screen window to be created and the old window that you were working in will remain active along with any processes that we’re running within it.

This allows you basically to run multiple commands within one single SSH session.

For example, you could run top command in one window, open up a new window and then use an email client to check your email.

If you press CTRL + a followed by n you can toggle between all of your open windows within screen.

Pressing CTRL + a followed by d will detach your screen window and drop you back to your original shell prompt but whatever processes you had running in all the various screen windows will remain running.

In fact, you can completely logout of the server and even though you’re logged out and gone everything that you started running will continue running within that detached window.

And most likely you’re going to want to reattach the window at some point.

To do that you use the screen -r command and that will reattach you to any detached screen windows you may have started previously.

# screen -r

If you have multiple screen windows, you’ll have to specify which one you want to reattach to.

Conclusion

I hope that now you have a good understanding of How to Kill a Process (Terminate a running process) in Linux.

If anyone does have any questions about what we covered in this guide then feel free to ask in the comment section below and I will do my best to answer those.

If you like our content, please consider buying us a coffee.

Buy Me A Coffee

We are thankful for your never ending support.

Leave a Comment