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:
-HUP) - restart a process
-INT) - terminate a process
-KILL) - let the kernel kick the process out
-SEGV) - have the program crash brutally
-TERM) - the default, ask the program kindly to terminate.
Kill without signal will send
All the above signal names can be specified the
SIG prefix (e.g.
-SIGKILL), this, however, is optional.
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!)
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 ...
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
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.
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.