Does backgrounded child process die with parent?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I have a script which calls several other sub-scripts. It is later killed and this seems to kill all the sub-scripts.
For the most part this is what I want. But there is a case or two where I don't want a child to die.
I think I remember being able to stop this from happening by backgrounding with a & when calling a script.
Can anyone confirm this?
bash process background-process
edited Feb 9 at 0:47
Jeff Schaller
31.3k846105
asked Feb 9 at 0:21
Philip Kirkbride
2,2872369
add a comment |Â
up vote
3
down vote
favorite
I have a script which calls several other sub-scripts. It is later killed and this seems to kill all the sub-scripts.
For the most part this is what I want. But there is a case or two where I don't want a child to die.
I think I remember being able to stop this from happening by backgrounding with a & when calling a script.
Can anyone confirm this?
bash process background-process
edited Feb 9 at 0:47
Jeff Schaller
31.3k846105
asked Feb 9 at 0:21
Philip Kirkbride
2,2872369
In case of shell or scripts, if child process ( a command ) was launched withnohupand then backgrounded, then no it won't die when parent shell process exits.
– Sergiy Kolodyazhnyy
Feb 9 at 1:08
Always take comment-answers with a huge dose of salt, because as here (where there is an awful lot more to the story, sadly) they can often be quite wrong, cannot be improved, and push potentially right answers down.
– JdeBP
Feb 9 at 6:32
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I have a script which calls several other sub-scripts. It is later killed and this seems to kill all the sub-scripts.
For the most part this is what I want. But there is a case or two where I don't want a child to die.
I think I remember being able to stop this from happening by backgrounding with a & when calling a script.
Can anyone confirm this?
bash process background-process
edited Feb 9 at 0:47
Jeff Schaller
31.3k846105
asked Feb 9 at 0:21
Philip Kirkbride
2,2872369
I have a script which calls several other sub-scripts. It is later killed and this seems to kill all the sub-scripts.
For the most part this is what I want. But there is a case or two where I don't want a child to die.
I think I remember being able to stop this from happening by backgrounding with a & when calling a script.
Can anyone confirm this?
bash process background-process
edited Feb 9 at 0:47
Jeff Schaller
31.3k846105
asked Feb 9 at 0:21
Philip Kirkbride
2,2872369
edited Feb 9 at 0:47
Jeff Schaller
31.3k846105
edited Feb 9 at 0:47
Jeff Schaller
31.3k846105
edited Feb 9 at 0:47
Jeff Schaller
31.3k846105
31.3k846105
asked Feb 9 at 0:21
Philip Kirkbride
2,2872369
asked Feb 9 at 0:21
Philip Kirkbride
2,2872369
asked Feb 9 at 0:21
Philip Kirkbride
2,2872369
2,2872369
In case of shell or scripts, if child process ( a command ) was launched withnohupand then backgrounded, then no it won't die when parent shell process exits.
– Sergiy Kolodyazhnyy
Feb 9 at 1:08
Always take comment-answers with a huge dose of salt, because as here (where there is an awful lot more to the story, sadly) they can often be quite wrong, cannot be improved, and push potentially right answers down.
– JdeBP
Feb 9 at 6:32
add a comment |Â
In case of shell or scripts, if child process ( a command ) was launched withnohupand then backgrounded, then no it won't die when parent shell process exits.
– Sergiy Kolodyazhnyy
Feb 9 at 1:08
Always take comment-answers with a huge dose of salt, because as here (where there is an awful lot more to the story, sadly) they can often be quite wrong, cannot be improved, and push potentially right answers down.
– JdeBP
Feb 9 at 6:32
In case of shell or scripts, if child process ( a command ) was launched with
nohup and then backgrounded, then no it won't die when parent shell process exits.– Sergiy Kolodyazhnyy
Feb 9 at 1:08
In case of shell or scripts, if child process ( a command ) was launched with
nohup and then backgrounded, then no it won't die when parent shell process exits.– Sergiy Kolodyazhnyy
Feb 9 at 1:08
Always take comment-answers with a huge dose of salt, because as here (where there is an awful lot more to the story, sadly) they can often be quite wrong, cannot be improved, and push potentially right answers down.
– JdeBP
Feb 9 at 6:32
Always take comment-answers with a huge dose of salt, because as here (where there is an awful lot more to the story, sadly) they can often be quite wrong, cannot be improved, and push potentially right answers down.
– JdeBP
Feb 9 at 6:32
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
There are a lot of factors to consider here. Please take this answer with a slight grain of salt as I'm writing all these details from memory. (And please correct me via edits or comments if you spot any mistakes.)
If you background a command with & and then the parent shell exits normally, the background command will keep running.
However, if you're running interactively, the "backgrounded" command will get blocked when it tries to read from or write to the terminal. (This applies whether or not the parent shell is still running.) If stdout, stdin and stderr are redirected this won't matter.
If you background a command and then e.g. your SSH session is disconnected, you can expect the backgrounded command to terminate. I believe this is because your shell will send SIGHUP to all its child processes, but I'm not 100% certain on the details of that.
If you disown a job (with the bash builtin disown) after you background it, then it won't be terminated just because e.g. your SSH session is terminated. However, the aspect of getting blocked when trying to write to terminal or read from terminal still applies (for interactive sessions).
The most general way I know of to start a sub-script or process in the background such that it will not be affected no matter what happens to the shell which spawns it (and regardless of whether it's being started interactively or from a script), is:
nohup somecommand >/dev/null 2>&1 </dev/null &
This assumes you don't care about ANY output of the command to its standard out or standard error, and don't need to feed it any standard input.
If you're happy for the sub-script to inherit the file descriptors of its parent (i.e. terminal is not a problem or you have some other solution), then really all you need should be:
./some-sub-script &
exit
And just a side comment, if you're writing a daemon which is intended to be left running, please (a) use logs and (b) take care of rotating your logs cleanly.
answered Feb 9 at 1:00
Wildcard
22k855153
nice nice ..........
– mlvljr
May 28 at 23:10
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
There are a lot of factors to consider here. Please take this answer with a slight grain of salt as I'm writing all these details from memory. (And please correct me via edits or comments if you spot any mistakes.)
If you background a command with & and then the parent shell exits normally, the background command will keep running.
However, if you're running interactively, the "backgrounded" command will get blocked when it tries to read from or write to the terminal. (This applies whether or not the parent shell is still running.) If stdout, stdin and stderr are redirected this won't matter.
If you background a command and then e.g. your SSH session is disconnected, you can expect the backgrounded command to terminate. I believe this is because your shell will send SIGHUP to all its child processes, but I'm not 100% certain on the details of that.
If you disown a job (with the bash builtin disown) after you background it, then it won't be terminated just because e.g. your SSH session is terminated. However, the aspect of getting blocked when trying to write to terminal or read from terminal still applies (for interactive sessions).
The most general way I know of to start a sub-script or process in the background such that it will not be affected no matter what happens to the shell which spawns it (and regardless of whether it's being started interactively or from a script), is:
nohup somecommand >/dev/null 2>&1 </dev/null &
This assumes you don't care about ANY output of the command to its standard out or standard error, and don't need to feed it any standard input.
If you're happy for the sub-script to inherit the file descriptors of its parent (i.e. terminal is not a problem or you have some other solution), then really all you need should be:
./some-sub-script &
exit
And just a side comment, if you're writing a daemon which is intended to be left running, please (a) use logs and (b) take care of rotating your logs cleanly.
answered Feb 9 at 1:00
Wildcard
22k855153
nice nice ..........
– mlvljr
May 28 at 23:10
add a comment |Â
up vote
3
down vote
accepted
There are a lot of factors to consider here. Please take this answer with a slight grain of salt as I'm writing all these details from memory. (And please correct me via edits or comments if you spot any mistakes.)
If you background a command with & and then the parent shell exits normally, the background command will keep running.
However, if you're running interactively, the "backgrounded" command will get blocked when it tries to read from or write to the terminal. (This applies whether or not the parent shell is still running.) If stdout, stdin and stderr are redirected this won't matter.
If you background a command and then e.g. your SSH session is disconnected, you can expect the backgrounded command to terminate. I believe this is because your shell will send SIGHUP to all its child processes, but I'm not 100% certain on the details of that.
If you disown a job (with the bash builtin disown) after you background it, then it won't be terminated just because e.g. your SSH session is terminated. However, the aspect of getting blocked when trying to write to terminal or read from terminal still applies (for interactive sessions).
The most general way I know of to start a sub-script or process in the background such that it will not be affected no matter what happens to the shell which spawns it (and regardless of whether it's being started interactively or from a script), is:
nohup somecommand >/dev/null 2>&1 </dev/null &
This assumes you don't care about ANY output of the command to its standard out or standard error, and don't need to feed it any standard input.
If you're happy for the sub-script to inherit the file descriptors of its parent (i.e. terminal is not a problem or you have some other solution), then really all you need should be:
./some-sub-script &
exit
And just a side comment, if you're writing a daemon which is intended to be left running, please (a) use logs and (b) take care of rotating your logs cleanly.
answered Feb 9 at 1:00
Wildcard
22k855153
nice nice ..........
– mlvljr
May 28 at 23:10
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
There are a lot of factors to consider here. Please take this answer with a slight grain of salt as I'm writing all these details from memory. (And please correct me via edits or comments if you spot any mistakes.)
If you background a command with & and then the parent shell exits normally, the background command will keep running.
However, if you're running interactively, the "backgrounded" command will get blocked when it tries to read from or write to the terminal. (This applies whether or not the parent shell is still running.) If stdout, stdin and stderr are redirected this won't matter.
If you background a command and then e.g. your SSH session is disconnected, you can expect the backgrounded command to terminate. I believe this is because your shell will send SIGHUP to all its child processes, but I'm not 100% certain on the details of that.
If you disown a job (with the bash builtin disown) after you background it, then it won't be terminated just because e.g. your SSH session is terminated. However, the aspect of getting blocked when trying to write to terminal or read from terminal still applies (for interactive sessions).
The most general way I know of to start a sub-script or process in the background such that it will not be affected no matter what happens to the shell which spawns it (and regardless of whether it's being started interactively or from a script), is:
nohup somecommand >/dev/null 2>&1 </dev/null &
This assumes you don't care about ANY output of the command to its standard out or standard error, and don't need to feed it any standard input.
If you're happy for the sub-script to inherit the file descriptors of its parent (i.e. terminal is not a problem or you have some other solution), then really all you need should be:
./some-sub-script &
exit
And just a side comment, if you're writing a daemon which is intended to be left running, please (a) use logs and (b) take care of rotating your logs cleanly.
answered Feb 9 at 1:00
Wildcard
22k855153
There are a lot of factors to consider here. Please take this answer with a slight grain of salt as I'm writing all these details from memory. (And please correct me via edits or comments if you spot any mistakes.)
If you background a command with & and then the parent shell exits normally, the background command will keep running.
However, if you're running interactively, the "backgrounded" command will get blocked when it tries to read from or write to the terminal. (This applies whether or not the parent shell is still running.) If stdout, stdin and stderr are redirected this won't matter.
If you background a command and then e.g. your SSH session is disconnected, you can expect the backgrounded command to terminate. I believe this is because your shell will send SIGHUP to all its child processes, but I'm not 100% certain on the details of that.
If you disown a job (with the bash builtin disown) after you background it, then it won't be terminated just because e.g. your SSH session is terminated. However, the aspect of getting blocked when trying to write to terminal or read from terminal still applies (for interactive sessions).
The most general way I know of to start a sub-script or process in the background such that it will not be affected no matter what happens to the shell which spawns it (and regardless of whether it's being started interactively or from a script), is:
nohup somecommand >/dev/null 2>&1 </dev/null &
This assumes you don't care about ANY output of the command to its standard out or standard error, and don't need to feed it any standard input.
If you're happy for the sub-script to inherit the file descriptors of its parent (i.e. terminal is not a problem or you have some other solution), then really all you need should be:
./some-sub-script &
exit
And just a side comment, if you're writing a daemon which is intended to be left running, please (a) use logs and (b) take care of rotating your logs cleanly.
answered Feb 9 at 1:00
Wildcard
22k855153
answered Feb 9 at 1:00
Wildcard
22k855153
answered Feb 9 at 1:00
Wildcard
22k855153
answered Feb 9 at 1:00
Wildcard
22k855153
22k855153
nice nice ..........
– mlvljr
May 28 at 23:10
add a comment |Â
nice nice ..........
– mlvljr
May 28 at 23:10
nice nice ..........
– mlvljr
May 28 at 23:10
nice nice ..........
– mlvljr
May 28 at 23:10
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f422938%2fdoes-backgrounded-child-process-die-with-parent%23new-answer', 'question_page');
);
Post as a guest
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
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
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
In case of shell or scripts, if child process ( a command ) was launched with
nohupand then backgrounded, then no it won't die when parent shell process exits.– Sergiy Kolodyazhnyy
Feb 9 at 1:08
Always take comment-answers with a huge dose of salt, because as here (where there is an awful lot more to the story, sadly) they can often be quite wrong, cannot be improved, and push potentially right answers down.
– JdeBP
Feb 9 at 6:32