Why are we using kill -9 always
I would like to know the kill stages. We always use kill-9 and not any other numbers. Can anyone explain the reason.
kill signals
add a comment |
I would like to know the kill stages. We always use kill-9 and not any other numbers. Can anyone explain the reason.
kill signals
2
How can we explain your reasons?
– Jeff Schaller
Jul 8 '17 at 15:55
9
I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
– jlliagre
Jul 8 '17 at 16:24
kill -9
is numeric shorthand forkill -KILL
: usekill
to send theSIGKILL
signal. On many systems you can usekill -l
to list available signals.
– user4556274
Jul 8 '17 at 17:22
Don't usekill -9
. Start with justkill
.
– roaima
Jul 8 '17 at 17:24
1
There is a theory that says if a prog can not be killed bykill -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.
– George Vasiliou
Jul 8 '17 at 20:46
add a comment |
I would like to know the kill stages. We always use kill-9 and not any other numbers. Can anyone explain the reason.
kill signals
I would like to know the kill stages. We always use kill-9 and not any other numbers. Can anyone explain the reason.
kill signals
kill signals
edited Jul 9 '17 at 23:34
Gilles
527k12710561580
527k12710561580
asked Jul 8 '17 at 15:47
Athiri
3010
3010
2
How can we explain your reasons?
– Jeff Schaller
Jul 8 '17 at 15:55
9
I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
– jlliagre
Jul 8 '17 at 16:24
kill -9
is numeric shorthand forkill -KILL
: usekill
to send theSIGKILL
signal. On many systems you can usekill -l
to list available signals.
– user4556274
Jul 8 '17 at 17:22
Don't usekill -9
. Start with justkill
.
– roaima
Jul 8 '17 at 17:24
1
There is a theory that says if a prog can not be killed bykill -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.
– George Vasiliou
Jul 8 '17 at 20:46
add a comment |
2
How can we explain your reasons?
– Jeff Schaller
Jul 8 '17 at 15:55
9
I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
– jlliagre
Jul 8 '17 at 16:24
kill -9
is numeric shorthand forkill -KILL
: usekill
to send theSIGKILL
signal. On many systems you can usekill -l
to list available signals.
– user4556274
Jul 8 '17 at 17:22
Don't usekill -9
. Start with justkill
.
– roaima
Jul 8 '17 at 17:24
1
There is a theory that says if a prog can not be killed bykill -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.
– George Vasiliou
Jul 8 '17 at 20:46
2
2
How can we explain your reasons?
– Jeff Schaller
Jul 8 '17 at 15:55
How can we explain your reasons?
– Jeff Schaller
Jul 8 '17 at 15:55
9
9
I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
– jlliagre
Jul 8 '17 at 16:24
I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
– jlliagre
Jul 8 '17 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.– user4556274
Jul 8 '17 at 17:22
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.– user4556274
Jul 8 '17 at 17:22
Don't use
kill -9
. Start with just kill
.– roaima
Jul 8 '17 at 17:24
Don't use
kill -9
. Start with just kill
.– roaima
Jul 8 '17 at 17:24
1
1
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.– George Vasiliou
Jul 8 '17 at 20:46
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.– George Vasiliou
Jul 8 '17 at 20:46
add a comment |
4 Answers
4
active
oldest
votes
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 ...
add a comment |
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 '17 at 16:06
5
@Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
– Fox
Jul 8 '17 at 16:14
I've added an expanded explanation of signal numbers.
– Bob Eager
Jul 8 '17 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 thatkill -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 '17 at 17:10
That's what I said: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.
I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
– Bob Eager
Jul 8 '17 at 17:15
|
show 4 more comments
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
fuser -ck and kill -9 are does the same process?.
– Athiri
Aug 14 '17 at 15:20
add a comment |
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.
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f377191%2fwhy-are-we-using-kill-9-always%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 ...
add a comment |
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 ...
add a comment |
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 ...
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 ...
edited Jul 27 '17 at 9:45
answered Jul 8 '17 at 17:24
thecarpy
2,265825
2,265825
add a comment |
add a comment |
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 '17 at 16:06
5
@Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
– Fox
Jul 8 '17 at 16:14
I've added an expanded explanation of signal numbers.
– Bob Eager
Jul 8 '17 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 thatkill -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 '17 at 17:10
That's what I said: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.
I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
– Bob Eager
Jul 8 '17 at 17:15
|
show 4 more comments
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 '17 at 16:06
5
@Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
– Fox
Jul 8 '17 at 16:14
I've added an expanded explanation of signal numbers.
– Bob Eager
Jul 8 '17 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 thatkill -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 '17 at 17:10
That's what I said: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.
I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
– Bob Eager
Jul 8 '17 at 17:15
|
show 4 more comments
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.
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.
edited Jul 8 '17 at 16:18
answered Jul 8 '17 at 15:58
Bob Eager
1,8861421
1,8861421
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 '17 at 16:06
5
@Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
– Fox
Jul 8 '17 at 16:14
I've added an expanded explanation of signal numbers.
– Bob Eager
Jul 8 '17 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 thatkill -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 '17 at 17:10
That's what I said: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.
I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
– Bob Eager
Jul 8 '17 at 17:15
|
show 4 more comments
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 '17 at 16:06
5
@Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
– Fox
Jul 8 '17 at 16:14
I've added an expanded explanation of signal numbers.
– Bob Eager
Jul 8 '17 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 thatkill -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 '17 at 17:10
That's what I said: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.
I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.
– Bob Eager
Jul 8 '17 at 17:15
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 '17 at 16:06
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 '17 at 16:06
5
5
@Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
– Fox
Jul 8 '17 at 16:14
@Athiri Those aren't "levels" or "stages" of kill power, they are signal numbers
– Fox
Jul 8 '17 at 16:14
I've added an expanded explanation of signal numbers.
– Bob Eager
Jul 8 '17 at 16:19
I've added an expanded explanation of signal numbers.
– Bob Eager
Jul 8 '17 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 '17 at 17:10
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 '17 at 17:10
That's what I said:
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.
I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.– Bob Eager
Jul 8 '17 at 17:15
That's what I said:
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.
I was thinking of SIGEMT and SIGBUS, which are not relevant to much modern hardware. Of course, other hardware events might be mapped onto them.– Bob Eager
Jul 8 '17 at 17:15
|
show 4 more comments
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
fuser -ck and kill -9 are does the same process?.
– Athiri
Aug 14 '17 at 15:20
add a comment |
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
fuser -ck and kill -9 are does the same process?.
– Athiri
Aug 14 '17 at 15:20
add a comment |
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
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
edited Jul 8 '17 at 22:31
answered Jul 8 '17 at 22:10
Chev_603
23128
23128
fuser -ck and kill -9 are does the same process?.
– Athiri
Aug 14 '17 at 15:20
add a comment |
fuser -ck and kill -9 are does the same process?.
– Athiri
Aug 14 '17 at 15:20
fuser -ck and kill -9 are does the same process?.
– Athiri
Aug 14 '17 at 15:20
fuser -ck and kill -9 are does the same process?.
– Athiri
Aug 14 '17 at 15:20
add a comment |
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.
New contributor
add a comment |
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.
New contributor
add a comment |
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.
New contributor
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.
New contributor
New contributor
answered 25 mins ago
Xenfomation
1
1
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f377191%2fwhy-are-we-using-kill-9-always%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
How can we explain your reasons?
– Jeff Schaller
Jul 8 '17 at 15:55
9
I'm not amongst the "we". You shouldn't blindingly use "kill -9" first.
– jlliagre
Jul 8 '17 at 16:24
kill -9
is numeric shorthand forkill -KILL
: usekill
to send theSIGKILL
signal. On many systems you can usekill -l
to list available signals.– user4556274
Jul 8 '17 at 17:22
Don't use
kill -9
. Start with justkill
.– roaima
Jul 8 '17 at 17:24
1
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.– George Vasiliou
Jul 8 '17 at 20:46