What is a fatal signal?
The Linux Programming Interface says:
TASK_KILLABLE : This state is like TASK_UNINTERRUPTIBLE , but wakes the process if a fatal signal (i.e., one that would kill the process) is received. By converting relevant parts of the kernel code to use this state, various scenarios where a hung process requires a system restart can be avoided. Instead, the process can be killed by sending it a fatal signal. The first piece of kernel code to be converted to use TASK_KILLABLE was NFS.
A fatal signal can wake up a process in TASK_KILLABLE but not in TASK_UNINTERRUPTIBLE.
Does a fatal signal mean only SIGKILL, or also SIGTERM, SIGHUP, SIGQUIT, SIGINT, or ...?
linux signals
edited Dec 25 '18 at 10:15
GAD3R
25.5k1750107
asked Dec 24 '18 at 20:31
Tim
26.2k74246455
add a comment |
The Linux Programming Interface says:
TASK_KILLABLE : This state is like TASK_UNINTERRUPTIBLE , but wakes the process if a fatal signal (i.e., one that would kill the process) is received. By converting relevant parts of the kernel code to use this state, various scenarios where a hung process requires a system restart can be avoided. Instead, the process can be killed by sending it a fatal signal. The first piece of kernel code to be converted to use TASK_KILLABLE was NFS.
A fatal signal can wake up a process in TASK_KILLABLE but not in TASK_UNINTERRUPTIBLE.
Does a fatal signal mean only SIGKILL, or also SIGTERM, SIGHUP, SIGQUIT, SIGINT, or ...?
linux signals
edited Dec 25 '18 at 10:15
GAD3R
25.5k1750107
asked Dec 24 '18 at 20:31
Tim
26.2k74246455
add a comment |
The Linux Programming Interface says:
TASK_KILLABLE : This state is like TASK_UNINTERRUPTIBLE , but wakes the process if a fatal signal (i.e., one that would kill the process) is received. By converting relevant parts of the kernel code to use this state, various scenarios where a hung process requires a system restart can be avoided. Instead, the process can be killed by sending it a fatal signal. The first piece of kernel code to be converted to use TASK_KILLABLE was NFS.
A fatal signal can wake up a process in TASK_KILLABLE but not in TASK_UNINTERRUPTIBLE.
Does a fatal signal mean only SIGKILL, or also SIGTERM, SIGHUP, SIGQUIT, SIGINT, or ...?
linux signals
edited Dec 25 '18 at 10:15
GAD3R
25.5k1750107
asked Dec 24 '18 at 20:31
Tim
26.2k74246455
The Linux Programming Interface says:
TASK_KILLABLE : This state is like TASK_UNINTERRUPTIBLE , but wakes the process if a fatal signal (i.e., one that would kill the process) is received. By converting relevant parts of the kernel code to use this state, various scenarios where a hung process requires a system restart can be avoided. Instead, the process can be killed by sending it a fatal signal. The first piece of kernel code to be converted to use TASK_KILLABLE was NFS.
A fatal signal can wake up a process in TASK_KILLABLE but not in TASK_UNINTERRUPTIBLE.
Does a fatal signal mean only SIGKILL, or also SIGTERM, SIGHUP, SIGQUIT, SIGINT, or ...?
linux signals
linux signals
edited Dec 25 '18 at 10:15
GAD3R
25.5k1750107
asked Dec 24 '18 at 20:31
Tim
26.2k74246455
edited Dec 25 '18 at 10:15
GAD3R
25.5k1750107
asked Dec 24 '18 at 20:31
Tim
26.2k74246455
edited Dec 25 '18 at 10:15
GAD3R
25.5k1750107
edited Dec 25 '18 at 10:15
GAD3R
25.5k1750107
edited Dec 25 '18 at 10:15
GAD3R
25.5k1750107
25.5k1750107
asked Dec 24 '18 at 20:31
Tim
26.2k74246455
asked Dec 24 '18 at 20:31
Tim
26.2k74246455
asked Dec 24 '18 at 20:31
Tim
26.2k74246455
26.2k74246455
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Most signals are fatal by default. Any signal listed with a default action of “terminate” or “dump core” is fatal, unless it’s ignored or handled explicitly. This includes such “benign” signals as SIGUSR1, as well as SIGKILL of course, SIGTERM etc.
This matches the Linux kernel’s definition of fatal signals; for a signal to be fatal:
- it mustn’t be one of the ignored signals (from the kernel’s perspective) or one of the stop signals, i.e. respectively
SIGCONT,SIGCHLD,SIGWINCH, andSIGURGon the one hand, andSIGSTOP,SIGTSTP,SIGTTIN, andSIGTTOUon the other; - its signal handler must be the default handler.
Thus a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run).
answered Dec 24 '18 at 22:39
Stephen Kitt
165k24366445
1
I assumeSIGKILLis a fatal signal, but which other signals could be considered as such?
– nxnev
Dec 24 '18 at 22:54
Thanks. (1) "the ignored signals (from the kernel’s perspective)". Most signals can be ignored. But the first link you gave shows some specific signals, such as SIGCONT, SIGCHLD, SIGWINCH, and SIGURG. So what does "ignored" signal mean? (2) The first link you gave doesn't say anything like "a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run)". Can we derive that from the definition in the first quote?
– Tim
Dec 25 '18 at 6:03
@nxnev any signal not listed as an ignored or stop signal is fatal by default.
– Stephen Kitt
Dec 25 '18 at 8:35
(1) It means that the kernel ignores them in this context, not that they’re configured as ignored signals. (Note that the list is static.) (2) The two bullet points retranscribe the code definition; that’s how we can derive the meaning of “fatal signal”.
– Stephen Kitt
Dec 25 '18 at 8:37
Thanks. Fatal signals are defined in terms of default actions, and by set complement (not ignore, not stop or contonue, then only terminate and core)
– Tim
Dec 25 '18 at 19:05
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%2f490805%2fwhat-is-a-fatal-signal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Most signals are fatal by default. Any signal listed with a default action of “terminate” or “dump core” is fatal, unless it’s ignored or handled explicitly. This includes such “benign” signals as SIGUSR1, as well as SIGKILL of course, SIGTERM etc.
This matches the Linux kernel’s definition of fatal signals; for a signal to be fatal:
- it mustn’t be one of the ignored signals (from the kernel’s perspective) or one of the stop signals, i.e. respectively
SIGCONT,SIGCHLD,SIGWINCH, andSIGURGon the one hand, andSIGSTOP,SIGTSTP,SIGTTIN, andSIGTTOUon the other; - its signal handler must be the default handler.
Thus a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run).
answered Dec 24 '18 at 22:39
Stephen Kitt
165k24366445
1
I assumeSIGKILLis a fatal signal, but which other signals could be considered as such?
– nxnev
Dec 24 '18 at 22:54
Thanks. (1) "the ignored signals (from the kernel’s perspective)". Most signals can be ignored. But the first link you gave shows some specific signals, such as SIGCONT, SIGCHLD, SIGWINCH, and SIGURG. So what does "ignored" signal mean? (2) The first link you gave doesn't say anything like "a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run)". Can we derive that from the definition in the first quote?
– Tim
Dec 25 '18 at 6:03
@nxnev any signal not listed as an ignored or stop signal is fatal by default.
– Stephen Kitt
Dec 25 '18 at 8:35
(1) It means that the kernel ignores them in this context, not that they’re configured as ignored signals. (Note that the list is static.) (2) The two bullet points retranscribe the code definition; that’s how we can derive the meaning of “fatal signal”.
– Stephen Kitt
Dec 25 '18 at 8:37
Thanks. Fatal signals are defined in terms of default actions, and by set complement (not ignore, not stop or contonue, then only terminate and core)
– Tim
Dec 25 '18 at 19:05
add a comment |
Most signals are fatal by default. Any signal listed with a default action of “terminate” or “dump core” is fatal, unless it’s ignored or handled explicitly. This includes such “benign” signals as SIGUSR1, as well as SIGKILL of course, SIGTERM etc.
This matches the Linux kernel’s definition of fatal signals; for a signal to be fatal:
- it mustn’t be one of the ignored signals (from the kernel’s perspective) or one of the stop signals, i.e. respectively
SIGCONT,SIGCHLD,SIGWINCH, andSIGURGon the one hand, andSIGSTOP,SIGTSTP,SIGTTIN, andSIGTTOUon the other; - its signal handler must be the default handler.
Thus a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run).
answered Dec 24 '18 at 22:39
Stephen Kitt
165k24366445
1
I assumeSIGKILLis a fatal signal, but which other signals could be considered as such?
– nxnev
Dec 24 '18 at 22:54
Thanks. (1) "the ignored signals (from the kernel’s perspective)". Most signals can be ignored. But the first link you gave shows some specific signals, such as SIGCONT, SIGCHLD, SIGWINCH, and SIGURG. So what does "ignored" signal mean? (2) The first link you gave doesn't say anything like "a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run)". Can we derive that from the definition in the first quote?
– Tim
Dec 25 '18 at 6:03
@nxnev any signal not listed as an ignored or stop signal is fatal by default.
– Stephen Kitt
Dec 25 '18 at 8:35
(1) It means that the kernel ignores them in this context, not that they’re configured as ignored signals. (Note that the list is static.) (2) The two bullet points retranscribe the code definition; that’s how we can derive the meaning of “fatal signal”.
– Stephen Kitt
Dec 25 '18 at 8:37
Thanks. Fatal signals are defined in terms of default actions, and by set complement (not ignore, not stop or contonue, then only terminate and core)
– Tim
Dec 25 '18 at 19:05
add a comment |
Most signals are fatal by default. Any signal listed with a default action of “terminate” or “dump core” is fatal, unless it’s ignored or handled explicitly. This includes such “benign” signals as SIGUSR1, as well as SIGKILL of course, SIGTERM etc.
This matches the Linux kernel’s definition of fatal signals; for a signal to be fatal:
- it mustn’t be one of the ignored signals (from the kernel’s perspective) or one of the stop signals, i.e. respectively
SIGCONT,SIGCHLD,SIGWINCH, andSIGURGon the one hand, andSIGSTOP,SIGTSTP,SIGTTIN, andSIGTTOUon the other; - its signal handler must be the default handler.
Thus a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run).
answered Dec 24 '18 at 22:39
Stephen Kitt
165k24366445
Most signals are fatal by default. Any signal listed with a default action of “terminate” or “dump core” is fatal, unless it’s ignored or handled explicitly. This includes such “benign” signals as SIGUSR1, as well as SIGKILL of course, SIGTERM etc.
This matches the Linux kernel’s definition of fatal signals; for a signal to be fatal:
- it mustn’t be one of the ignored signals (from the kernel’s perspective) or one of the stop signals, i.e. respectively
SIGCONT,SIGCHLD,SIGWINCH, andSIGURGon the one hand, andSIGSTOP,SIGTSTP,SIGTTIN, andSIGTTOUon the other; - its signal handler must be the default handler.
Thus a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run).
answered Dec 24 '18 at 22:39
Stephen Kitt
165k24366445
edited Dec 25 '18 at 8:34
answered Dec 24 '18 at 22:39
Stephen Kitt
165k24366445
answered Dec 24 '18 at 22:39
Stephen Kitt
165k24366445
answered Dec 24 '18 at 22:39
Stephen Kitt
165k24366445
165k24366445
1
I assumeSIGKILLis a fatal signal, but which other signals could be considered as such?
– nxnev
Dec 24 '18 at 22:54
Thanks. (1) "the ignored signals (from the kernel’s perspective)". Most signals can be ignored. But the first link you gave shows some specific signals, such as SIGCONT, SIGCHLD, SIGWINCH, and SIGURG. So what does "ignored" signal mean? (2) The first link you gave doesn't say anything like "a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run)". Can we derive that from the definition in the first quote?
– Tim
Dec 25 '18 at 6:03
@nxnev any signal not listed as an ignored or stop signal is fatal by default.
– Stephen Kitt
Dec 25 '18 at 8:35
(1) It means that the kernel ignores them in this context, not that they’re configured as ignored signals. (Note that the list is static.) (2) The two bullet points retranscribe the code definition; that’s how we can derive the meaning of “fatal signal”.
– Stephen Kitt
Dec 25 '18 at 8:37
Thanks. Fatal signals are defined in terms of default actions, and by set complement (not ignore, not stop or contonue, then only terminate and core)
– Tim
Dec 25 '18 at 19:05
add a comment |
1
I assumeSIGKILLis a fatal signal, but which other signals could be considered as such?
– nxnev
Dec 24 '18 at 22:54
Thanks. (1) "the ignored signals (from the kernel’s perspective)". Most signals can be ignored. But the first link you gave shows some specific signals, such as SIGCONT, SIGCHLD, SIGWINCH, and SIGURG. So what does "ignored" signal mean? (2) The first link you gave doesn't say anything like "a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run)". Can we derive that from the definition in the first quote?
– Tim
Dec 25 '18 at 6:03
@nxnev any signal not listed as an ignored or stop signal is fatal by default.
– Stephen Kitt
Dec 25 '18 at 8:35
(1) It means that the kernel ignores them in this context, not that they’re configured as ignored signals. (Note that the list is static.) (2) The two bullet points retranscribe the code definition; that’s how we can derive the meaning of “fatal signal”.
– Stephen Kitt
Dec 25 '18 at 8:37
Thanks. Fatal signals are defined in terms of default actions, and by set complement (not ignore, not stop or contonue, then only terminate and core)
– Tim
Dec 25 '18 at 19:05
1
1
I assume
SIGKILL is a fatal signal, but which other signals could be considered as such?– nxnev
Dec 24 '18 at 22:54
I assume
SIGKILL is a fatal signal, but which other signals could be considered as such?– nxnev
Dec 24 '18 at 22:54
Thanks. (1) "the ignored signals (from the kernel’s perspective)". Most signals can be ignored. But the first link you gave shows some specific signals, such as SIGCONT, SIGCHLD, SIGWINCH, and SIGURG. So what does "ignored" signal mean? (2) The first link you gave doesn't say anything like "a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run)". Can we derive that from the definition in the first quote?
– Tim
Dec 25 '18 at 6:03
Thanks. (1) "the ignored signals (from the kernel’s perspective)". Most signals can be ignored. But the first link you gave shows some specific signals, such as SIGCONT, SIGCHLD, SIGWINCH, and SIGURG. So what does "ignored" signal mean? (2) The first link you gave doesn't say anything like "a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run)". Can we derive that from the definition in the first quote?
– Tim
Dec 25 '18 at 6:03
@nxnev any signal not listed as an ignored or stop signal is fatal by default.
– Stephen Kitt
Dec 25 '18 at 8:35
@nxnev any signal not listed as an ignored or stop signal is fatal by default.
– Stephen Kitt
Dec 25 '18 at 8:35
(1) It means that the kernel ignores them in this context, not that they’re configured as ignored signals. (Note that the list is static.) (2) The two bullet points retranscribe the code definition; that’s how we can derive the meaning of “fatal signal”.
– Stephen Kitt
Dec 25 '18 at 8:37
(1) It means that the kernel ignores them in this context, not that they’re configured as ignored signals. (Note that the list is static.) (2) The two bullet points retranscribe the code definition; that’s how we can derive the meaning of “fatal signal”.
– Stephen Kitt
Dec 25 '18 at 8:37
Thanks. Fatal signals are defined in terms of default actions, and by set complement (not ignore, not stop or contonue, then only terminate and core)
– Tim
Dec 25 '18 at 19:05
Thanks. Fatal signals are defined in terms of default actions, and by set complement (not ignore, not stop or contonue, then only terminate and core)
– Tim
Dec 25 '18 at 19:05
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%2f490805%2fwhat-is-a-fatal-signal%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
