Why doesn't the Linux kernel send SIGCONT first and then SIGHUP to a newly orphaned process group containing...
APUE says
Since the process group is orphaned when the parent terminates, and the
process group contains a stopped process, POSIX.1 requires that every process in
the newly orphaned process group be sent the hang-up signal (SIGHUP)
followed by the continue signal (SIGCONT).
The kernel sends SIGCONT after SIGHUP, but the process is waken up by SIGCONT before acting on SIGHUP. So why doesn't the Linux kernel send SIGCONT before SIGHUP?
Thanks.
Related to but not answered by Does the default action of SIGCONT resume the execution of a stopped process before or after first handling any pending unblocked signals?
I did not answer my question.
linux signals sighup
asked Dec 26 '18 at 13:46
Tim
26.3k74246455
add a comment |
APUE says
Since the process group is orphaned when the parent terminates, and the
process group contains a stopped process, POSIX.1 requires that every process in
the newly orphaned process group be sent the hang-up signal (SIGHUP)
followed by the continue signal (SIGCONT).
The kernel sends SIGCONT after SIGHUP, but the process is waken up by SIGCONT before acting on SIGHUP. So why doesn't the Linux kernel send SIGCONT before SIGHUP?
Thanks.
Related to but not answered by Does the default action of SIGCONT resume the execution of a stopped process before or after first handling any pending unblocked signals?
I did not answer my question.
linux signals sighup
asked Dec 26 '18 at 13:46
Tim
26.3k74246455
3
You just answered your own question; to ensure SIGHUP is pending and so handled when the process is resumed.
– Stephen Harris
Dec 26 '18 at 13:58
add a comment |
APUE says
Since the process group is orphaned when the parent terminates, and the
process group contains a stopped process, POSIX.1 requires that every process in
the newly orphaned process group be sent the hang-up signal (SIGHUP)
followed by the continue signal (SIGCONT).
The kernel sends SIGCONT after SIGHUP, but the process is waken up by SIGCONT before acting on SIGHUP. So why doesn't the Linux kernel send SIGCONT before SIGHUP?
Thanks.
Related to but not answered by Does the default action of SIGCONT resume the execution of a stopped process before or after first handling any pending unblocked signals?
I did not answer my question.
linux signals sighup
asked Dec 26 '18 at 13:46
Tim
26.3k74246455
APUE says
Since the process group is orphaned when the parent terminates, and the
process group contains a stopped process, POSIX.1 requires that every process in
the newly orphaned process group be sent the hang-up signal (SIGHUP)
followed by the continue signal (SIGCONT).
The kernel sends SIGCONT after SIGHUP, but the process is waken up by SIGCONT before acting on SIGHUP. So why doesn't the Linux kernel send SIGCONT before SIGHUP?
Thanks.
Related to but not answered by Does the default action of SIGCONT resume the execution of a stopped process before or after first handling any pending unblocked signals?
I did not answer my question.
linux signals sighup
linux signals sighup
asked Dec 26 '18 at 13:46
Tim
26.3k74246455
asked Dec 26 '18 at 13:46
Tim
26.3k74246455
edited Dec 26 '18 at 20:13
asked Dec 26 '18 at 13:46
Tim
26.3k74246455
asked Dec 26 '18 at 13:46
Tim
26.3k74246455
asked Dec 26 '18 at 13:46
Tim
26.3k74246455
26.3k74246455
3
You just answered your own question; to ensure SIGHUP is pending and so handled when the process is resumed.
– Stephen Harris
Dec 26 '18 at 13:58
add a comment |
3
You just answered your own question; to ensure SIGHUP is pending and so handled when the process is resumed.
– Stephen Harris
Dec 26 '18 at 13:58
3
3
You just answered your own question; to ensure SIGHUP is pending and so handled when the process is resumed.
– Stephen Harris
Dec 26 '18 at 13:58
You just answered your own question; to ensure SIGHUP is pending and so handled when the process is resumed.
– Stephen Harris
Dec 26 '18 at 13:58
add a comment |
1 Answer
1
active
oldest
votes
Not only do you answer your question, the link you added at the end also answers your question.
When a process is stopped, all signal processing is stopped, except for SIGCONT and SIGKILL - which are, in practice handled by the operating system.
This means that SIGHUP can only the handled after the process is resumed, which happens when SIGCONT is recieved and handled, so, even if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order.
Now, in practice, the kernel sending SIGHUP before will result in less stuff being done by a process between handling SIGCONT and handling SIGHUP, as the second is already queued to be handled.
answered Dec 26 '18 at 19:02
theMage
462
This is the part that I am not sure: "if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order."
– Tim
Dec 26 '18 at 20:13
Hi @Tim. If the process is stopped, they have to be, because until the process handles SIGCONT, it doesn't handle any other signal, except SIGCONT and SIGKILL.
– theMage
Dec 27 '18 at 9:09
So isn't it the same reacting order, regardless of sending order?
– Tim
Dec 27 '18 at 12:29
It is. However, you can't warranty that the process sending the signals will not be paused between serving the two signals, which would, potentially, resulting in the second process doing other stuff between handling the two signals.
– theMage
Dec 27 '18 at 16:19
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%2f490987%2fwhy-doesnt-the-linux-kernel-send-sigcont-first-and-then-sighup-to-a-newly-orpha%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
Not only do you answer your question, the link you added at the end also answers your question.
When a process is stopped, all signal processing is stopped, except for SIGCONT and SIGKILL - which are, in practice handled by the operating system.
This means that SIGHUP can only the handled after the process is resumed, which happens when SIGCONT is recieved and handled, so, even if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order.
Now, in practice, the kernel sending SIGHUP before will result in less stuff being done by a process between handling SIGCONT and handling SIGHUP, as the second is already queued to be handled.
answered Dec 26 '18 at 19:02
theMage
462
This is the part that I am not sure: "if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order."
– Tim
Dec 26 '18 at 20:13
Hi @Tim. If the process is stopped, they have to be, because until the process handles SIGCONT, it doesn't handle any other signal, except SIGCONT and SIGKILL.
– theMage
Dec 27 '18 at 9:09
So isn't it the same reacting order, regardless of sending order?
– Tim
Dec 27 '18 at 12:29
It is. However, you can't warranty that the process sending the signals will not be paused between serving the two signals, which would, potentially, resulting in the second process doing other stuff between handling the two signals.
– theMage
Dec 27 '18 at 16:19
add a comment |
Not only do you answer your question, the link you added at the end also answers your question.
When a process is stopped, all signal processing is stopped, except for SIGCONT and SIGKILL - which are, in practice handled by the operating system.
This means that SIGHUP can only the handled after the process is resumed, which happens when SIGCONT is recieved and handled, so, even if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order.
Now, in practice, the kernel sending SIGHUP before will result in less stuff being done by a process between handling SIGCONT and handling SIGHUP, as the second is already queued to be handled.
answered Dec 26 '18 at 19:02
theMage
462
This is the part that I am not sure: "if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order."
– Tim
Dec 26 '18 at 20:13
Hi @Tim. If the process is stopped, they have to be, because until the process handles SIGCONT, it doesn't handle any other signal, except SIGCONT and SIGKILL.
– theMage
Dec 27 '18 at 9:09
So isn't it the same reacting order, regardless of sending order?
– Tim
Dec 27 '18 at 12:29
It is. However, you can't warranty that the process sending the signals will not be paused between serving the two signals, which would, potentially, resulting in the second process doing other stuff between handling the two signals.
– theMage
Dec 27 '18 at 16:19
add a comment |
Not only do you answer your question, the link you added at the end also answers your question.
When a process is stopped, all signal processing is stopped, except for SIGCONT and SIGKILL - which are, in practice handled by the operating system.
This means that SIGHUP can only the handled after the process is resumed, which happens when SIGCONT is recieved and handled, so, even if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order.
Now, in practice, the kernel sending SIGHUP before will result in less stuff being done by a process between handling SIGCONT and handling SIGHUP, as the second is already queued to be handled.
answered Dec 26 '18 at 19:02
theMage
462
Not only do you answer your question, the link you added at the end also answers your question.
When a process is stopped, all signal processing is stopped, except for SIGCONT and SIGKILL - which are, in practice handled by the operating system.
This means that SIGHUP can only the handled after the process is resumed, which happens when SIGCONT is recieved and handled, so, even if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order.
Now, in practice, the kernel sending SIGHUP before will result in less stuff being done by a process between handling SIGCONT and handling SIGHUP, as the second is already queued to be handled.
answered Dec 26 '18 at 19:02
theMage
462
answered Dec 26 '18 at 19:02
theMage
462
answered Dec 26 '18 at 19:02
theMage
462
answered Dec 26 '18 at 19:02
theMage
462
462
This is the part that I am not sure: "if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order."
– Tim
Dec 26 '18 at 20:13
Hi @Tim. If the process is stopped, they have to be, because until the process handles SIGCONT, it doesn't handle any other signal, except SIGCONT and SIGKILL.
– theMage
Dec 27 '18 at 9:09
So isn't it the same reacting order, regardless of sending order?
– Tim
Dec 27 '18 at 12:29
It is. However, you can't warranty that the process sending the signals will not be paused between serving the two signals, which would, potentially, resulting in the second process doing other stuff between handling the two signals.
– theMage
Dec 27 '18 at 16:19
add a comment |
This is the part that I am not sure: "if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order."
– Tim
Dec 26 '18 at 20:13
Hi @Tim. If the process is stopped, they have to be, because until the process handles SIGCONT, it doesn't handle any other signal, except SIGCONT and SIGKILL.
– theMage
Dec 27 '18 at 9:09
So isn't it the same reacting order, regardless of sending order?
– Tim
Dec 27 '18 at 12:29
It is. However, you can't warranty that the process sending the signals will not be paused between serving the two signals, which would, potentially, resulting in the second process doing other stuff between handling the two signals.
– theMage
Dec 27 '18 at 16:19
This is the part that I am not sure: "if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order."
– Tim
Dec 26 '18 at 20:13
This is the part that I am not sure: "if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order."
– Tim
Dec 26 '18 at 20:13
Hi @Tim. If the process is stopped, they have to be, because until the process handles SIGCONT, it doesn't handle any other signal, except SIGCONT and SIGKILL.
– theMage
Dec 27 '18 at 9:09
Hi @Tim. If the process is stopped, they have to be, because until the process handles SIGCONT, it doesn't handle any other signal, except SIGCONT and SIGKILL.
– theMage
Dec 27 '18 at 9:09
So isn't it the same reacting order, regardless of sending order?
– Tim
Dec 27 '18 at 12:29
So isn't it the same reacting order, regardless of sending order?
– Tim
Dec 27 '18 at 12:29
It is. However, you can't warranty that the process sending the signals will not be paused between serving the two signals, which would, potentially, resulting in the second process doing other stuff between handling the two signals.
– theMage
Dec 27 '18 at 16:19
It is. However, you can't warranty that the process sending the signals will not be paused between serving the two signals, which would, potentially, resulting in the second process doing other stuff between handling the two signals.
– theMage
Dec 27 '18 at 16:19
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%2f490987%2fwhy-doesnt-the-linux-kernel-send-sigcont-first-and-then-sighup-to-a-newly-orpha%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
3
You just answered your own question; to ensure SIGHUP is pending and so handled when the process is resumed.
– Stephen Harris
Dec 26 '18 at 13:58