Sstrhsrtj

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

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 you 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.

Hope that helps ;-)

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 ...

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.

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.

Source

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.