I would like to know the kill stages. We always use kill -9 and not any other numbers. Can anyone explain the reason.

  • 3
    How can we explain your reasons?
    – Jeff Schaller
    Jul 8, 2017 at 15:55
  • 9
    I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
    – jlliagre
    Jul 8, 2017 at 16:24
  • kill -9 is numeric shorthand for kill -KILL: use kill to send the SIGKILL signal. On many systems you can use kill -l to list available signals. Jul 8, 2017 at 17:22
  • Don't use kill -9. Start with just kill.
    – roaima
    Jul 8, 2017 at 17:24
  • 2
    There is a theory that says if a prog can not be killed by kill -15 which is the normal way to terminate normally a prog, then remove this prog since it misbehaves and does not follow the common programming rules and potentially might misbehave in other cases also. Jul 8, 2017 at 20:46

4 Answers 4


Actually, I quite like Bob's answer.

The signals I use are:

  • -1 (-HUP) - restart a process
  • -2 (-INT) - terminate a process
  • -9 (-KILL) - let the kernel kick the process out
  • -11 (-SEGV) - have the program crash brutally
  • -15 (-TERM) - the default, ask the program kindly to terminate.

Kill without signal will send -15 (-TERM).

All the above signal names can be specified the SIG prefix (e.g. -SIGKILL), this, however, is optional.

Note, kill -11 will force the program to exit with a segmentation fault, I use it sometimes, when kill -9 won't terminate a process. (You might lose data if you issue kill -9 or kill -11 on a process, so beware!)

You use ps -ef | grep <program> to inspect the process. To get rid of a process (which has parent PID 1), you have to kill -HUP 1 or kill -1 1 (both as root). Note that PID 1 is your init system.

So, to terminate a process, issue kill <pid> (the exact same as kill -15 <pid>), if that fails I try these others (you could lose data!), kill -2 <pid> (akin to doing Ctrl+c), if that fails kill -9 <pid>, if that fails kill -11 <pid>, if that fails the process is most likely a zombie process, ensure that is the case using ps -ef | grep <program_name> or ps -ef | grep <pid>, it should mention "defunct" after the process. This is when you issue kill -1 1.

Some programs, such as Java JVM's, can be configured to dump threads/heap (for troubleshooting) when they receive a signal, in these cases I use kill as well ...

  • Actually HUP means "HangUP" and is sent when you log-out - or "loose the line" with a dial-up or serial-line. This will usually cause the command to terminate. The command nohup is used to make a command continue even after you log-out and the HUP-signal is sent - eg nohup gcc my_command.c >& log. However daemons usually respond to the HUP-signal by reloading their config-files and/or restarting... But this may be because daemons are specifically disconnected from all terminals and thus will never normally get the HUP-signal, thus freeing HUP for use as "reload config" signal. Apr 6, 2019 at 7:12
  • My .project file for root, used to be "Licensed to kill - processes". Apr 6, 2019 at 7:15

Originally, the kill command/system call just killed a process. This was done by the kernel and the process just disappeared, never being notified about it. That stopped around Third Edition, I think. kill -9 says to send signal number 9 to a process. Unlike most (all? it depends) other signals, it can't be 'caught' by a process and handled in any way. A kinder way to stop a process is kill -15 (or kill -TERM) which tells the process it is being terminated, but gives it a chance to perform cleanup.

Use of kill -9 is a 'guaranteed' way to kill a process; if it's stuck, kill -15 might not always work. Hence, many people still use kill -9 as a 'first resort'.

The reason the 'ultimate' kill signal is number 9 is just the way they did it. There were at least another eight different signals at that time, and I guess the numbers were assigned by the person who programmed that part of the kernel (probably Ken Thompson). Some of the lower numbers are now largely historical, as they map onto hardware instructions and/or events in the PDP-11 hardware. And there are also many others above 9.

Note that the actual numbers have no levels or hierarchy in them; in no sense is signal 8 'less' than signal 9 or 'greater' than signal 7.

  • Why are we not using 1 or 2 or 3 etc.. we just using 9 always. Is there a stages in between?
    – Athiri
    Jul 8, 2017 at 16:06
  • 6
    @Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
    – Fox
    Jul 8, 2017 at 16:14
  • I've added an expanded explanation of signal numbers.
    – Bob Eager
    Jul 8, 2017 at 16:19
  • Of course the process is notified: if it wants to, it can set up a signal handler and catch the signal. If it wants not to die, it can do so. It's only by default that most signals kill the process. But SIGKILL (9) cannot be caught or ignored, which is why people think that kill -9 is necessary: it is not - it depends on what you want to do (and BTW, if the process is sleeping uninterruptibly in the kernel, it cannot be killed: it will only disappear after a reboot). Also all of the "hardware" signals can be generated on modern hardware: which ones do you think are obsolete?
    – NickD
    Jul 8, 2017 at 17:10
  • 1
    When I said the process was never notified, I said 'originally'. I was referring to very early UNIX, Third Edition or earlier.
    – Bob Eager
    Jul 8, 2017 at 17:22

Well... everyone's programming style is different, I suppose. Personally, I try to avoid sending a kill -9 if I can because it tends to create zombie processes, as it does not allow the process it kills to execute any clean up actions that may or may not exist in the program the user wants to kill.

It is the 'last resort' signal, so while it's seldom the preferred way to terminate a program, it is commonly used, (particular in poorly written programs) because it "always works", so to speak...

If a process is ignoring SIGINT or SIGTERM, than there should be a reason for that-- perhaps the process is supposed to release a lock file, delete some temporary file(s), and/or perform some other 'clean up' actions before termination. Of course, programs do misbehave, and thus we do need SIGKILL for those (hopefully rare) scenarios.

The only truly appropriate uses of SIGKILL are when a process is misbehaving for some reason and thus will not properly terminate, or when the user needs to kill the process immediately for some other reason (for example, if you accidentally execute a trojan and than freak out, you may want to make sure that you kill the program quickly, and entirely).

The reason why you may see it often is because it is the only signal the kernel cannot ignore. In the shell you can play around with the trap command to see for yourself, but this a very good explanation of what kill -9 does:

Signal 9 From Outer Space

There is one signal that you cannot trap: SIGKILL or signal 9. The kernel immediately terminates any process sent this signal and no signal handling is performed. Since it will always terminate a program that is stuck, hung, or otherwise screwed up, it is tempting to think that it's the easy way out when you have to get something to stop and go away. Often you will see references to the following command which sends the SIGKILL signal: kill -9

However, despite its apparent ease, you must remember that when you send this signal, no processing is done by the application. Often this is OK, but with many programs it's not. In particular, many complex programs (and some not-so-complex) create lock files to prevent multiple copies of the program from running at the same time. When a program that uses a lock file is sent a SIGKILL, it doesn't get the chance to remove the lock file when it terminates. The presence of the lock file will prevent the program from restarting until the lock file is manually removed.

Be warned. Use SIGKILL as a last resort.


  • fuser -ck and kill -9 are does the same process?.
    – Athiri
    Aug 14, 2017 at 15:20

I love this thread as it echoes back to the days I used to help my Dad on-site (during the early 80s) working on old Burroughs/Unisys systems... all the way to the present where kill has slightly evolved (for various reasons).

First, credit to @thecarpy and Bob for their responses.

Secondly, kill can take on different meanings based on the Unix/Unix-like system (or shell) implementation. Originally, kill was a direct system call to module-based/monolithic-based kernels to allow a user to delete an active process from memory. The point is, this command was a means for the kernel space (ring0), ring3 (user space), or higher-level users to destroy greedy/run-away processes from absorbing resources on old, main/mid-frame systems.

Third, the whole purpose of kill is to ensure a PID has a handle for SIGKILL to be sent -- per process/per terminal/per run-level.

With Unix-like systems, kill -9 is used too frequently, IMHO, as it has been stated it can leave zombie processes. This is due to the Parent->Child Process PID relationships based on forking, pipe-lining, and other reasons where the initial PID/Process spawns children, etc.

The command is quite useful as it is dangerous, but knowing the options (as mentioned above) and the PID in question (from a shell script to a core DB process) should be investigated first:

ps -aef | grep -i

Once identified, kill -15 was what I used to prevent zombies and run-away processes, such as in the early days of MySQL, to conserve system resources, however knowing the right SIGnal to send a process is important, too: https://en.wikipedia.org/wiki/Kill_(command)

When in doubt, try to use the pkill command for named-processes, such as mariadb/httpd or kill -15 to immediately nuke a process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.