Bash ` &` behaviour inconsistent when there's a loop at the end of the script
Clash Royale CLAN TAG#URR8PPP
When I start up Linux Mint 19, I like to launch a few things. So I've been using a script (./get-to-work
) in a MATE Terminal window to launch them all at once:
chromium-browser --start-maximized &
thunderbird &
code -n path/to/my/workspace &
That works great. I launch the script, close the terminal window, and the three programs continue running.
However, I recently added a line to open a big yellow window every five minutes (to remind me to sit up straight):
chromium-browser --start-maximized &
thunderbird &
code -n path/to/my/workspace &
for i in 1..1000; do sleep 300 ; xterm -bg yellow -g 240x80 ; done
Now if I close the terminal I launched this in, the script is still running, and it gets killed, and then I don't get any yellow popups. That's actually a feature for me--I keep the terminal open as long as I want popups, and close it, for example, when I'm screen-sharing.
For whatever reason, though, closing the terminal and killing the script not only stops the popup loop, it now closes Chromium and Thunderbird too. VSCode (code
) stays open. Why?
bash
add a comment |
When I start up Linux Mint 19, I like to launch a few things. So I've been using a script (./get-to-work
) in a MATE Terminal window to launch them all at once:
chromium-browser --start-maximized &
thunderbird &
code -n path/to/my/workspace &
That works great. I launch the script, close the terminal window, and the three programs continue running.
However, I recently added a line to open a big yellow window every five minutes (to remind me to sit up straight):
chromium-browser --start-maximized &
thunderbird &
code -n path/to/my/workspace &
for i in 1..1000; do sleep 300 ; xterm -bg yellow -g 240x80 ; done
Now if I close the terminal I launched this in, the script is still running, and it gets killed, and then I don't get any yellow popups. That's actually a feature for me--I keep the terminal open as long as I want popups, and close it, for example, when I'm screen-sharing.
For whatever reason, though, closing the terminal and killing the script not only stops the popup loop, it now closes Chromium and Thunderbird too. VSCode (code
) stays open. Why?
bash
add a comment |
When I start up Linux Mint 19, I like to launch a few things. So I've been using a script (./get-to-work
) in a MATE Terminal window to launch them all at once:
chromium-browser --start-maximized &
thunderbird &
code -n path/to/my/workspace &
That works great. I launch the script, close the terminal window, and the three programs continue running.
However, I recently added a line to open a big yellow window every five minutes (to remind me to sit up straight):
chromium-browser --start-maximized &
thunderbird &
code -n path/to/my/workspace &
for i in 1..1000; do sleep 300 ; xterm -bg yellow -g 240x80 ; done
Now if I close the terminal I launched this in, the script is still running, and it gets killed, and then I don't get any yellow popups. That's actually a feature for me--I keep the terminal open as long as I want popups, and close it, for example, when I'm screen-sharing.
For whatever reason, though, closing the terminal and killing the script not only stops the popup loop, it now closes Chromium and Thunderbird too. VSCode (code
) stays open. Why?
bash
When I start up Linux Mint 19, I like to launch a few things. So I've been using a script (./get-to-work
) in a MATE Terminal window to launch them all at once:
chromium-browser --start-maximized &
thunderbird &
code -n path/to/my/workspace &
That works great. I launch the script, close the terminal window, and the three programs continue running.
However, I recently added a line to open a big yellow window every five minutes (to remind me to sit up straight):
chromium-browser --start-maximized &
thunderbird &
code -n path/to/my/workspace &
for i in 1..1000; do sleep 300 ; xterm -bg yellow -g 240x80 ; done
Now if I close the terminal I launched this in, the script is still running, and it gets killed, and then I don't get any yellow popups. That's actually a feature for me--I keep the terminal open as long as I want popups, and close it, for example, when I'm screen-sharing.
For whatever reason, though, closing the terminal and killing the script not only stops the popup loop, it now closes Chromium and Thunderbird too. VSCode (code
) stays open. Why?
bash
bash
edited Feb 27 at 16:45
ilkkachu
62.5k10103179
62.5k10103179
asked Feb 27 at 9:54
KevKev
95841839
95841839
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
What happens in the first case:
After the last command in the script is backgrounded, the shell executing the script exits immediately. This shell process was the parent process of the 3 programs started from the script. Now that their parent process has exited, the PID-1 process (init
or systemd
often nowadays) becomes their parent process.
The link between the terminal and the programs started from the script is gone, because the terminal program is not their (grand)parent process anymore.
What happens in the second case:
After the last backgrounded process, the script stays alive to run the loop. When the terminal exits, it sends SIGHUP to its child processes; the shell being its child, propagates this signal to its child processes (your programs).
The default action when a process receives a HUP signal is to exit. Apparently VSCode
ignores SIGHUP, or fork()
s away from its parent process, so it is not affected.
1
Note:nohup thunderbird &
should make the difference in the 2nd case.
– Kamil Maciorowski
Feb 27 at 17:45
2
@KamilMaciorowski or better(trap '' HUP; thunderbird &)
– mosvy
Feb 27 at 18:47
1
In the first case, they're not receiving a SIGHUP because their process group is not the foreground process group in the terminal, *not( because the terminal emulator is no longer their grandparent. You can easily check withxterm -e sh -c 'sleep 3600 &'
-- the sleep will be killed by SIGHUP despite it being adopted by init.
– mosvy
Feb 27 at 19:28
In the second case, resending SIGHUP is something very specific tobash
, other shells don't do that (only sleeping background processes will be sent CONT + HUP by the kernel). Also, onlyxterm
is sending aSIGHUP
to the fg process group in the terminal -- most other terminal emulators will just close the master side of the pty, causing aSIGHUP
to be sent by kernel.
– mosvy
Feb 27 at 19:37
1
@Kev any program (eg. chromium) may reset the SIGHUP handler to default (ie terminate). Try running it assetsid chromium &
instead.
– mosvy
Mar 3 at 16:43
|
show 2 more comments
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%2f503289%2fbash-behaviour-inconsistent-when-theres-a-loop-at-the-end-of-the-script%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
What happens in the first case:
After the last command in the script is backgrounded, the shell executing the script exits immediately. This shell process was the parent process of the 3 programs started from the script. Now that their parent process has exited, the PID-1 process (init
or systemd
often nowadays) becomes their parent process.
The link between the terminal and the programs started from the script is gone, because the terminal program is not their (grand)parent process anymore.
What happens in the second case:
After the last backgrounded process, the script stays alive to run the loop. When the terminal exits, it sends SIGHUP to its child processes; the shell being its child, propagates this signal to its child processes (your programs).
The default action when a process receives a HUP signal is to exit. Apparently VSCode
ignores SIGHUP, or fork()
s away from its parent process, so it is not affected.
1
Note:nohup thunderbird &
should make the difference in the 2nd case.
– Kamil Maciorowski
Feb 27 at 17:45
2
@KamilMaciorowski or better(trap '' HUP; thunderbird &)
– mosvy
Feb 27 at 18:47
1
In the first case, they're not receiving a SIGHUP because their process group is not the foreground process group in the terminal, *not( because the terminal emulator is no longer their grandparent. You can easily check withxterm -e sh -c 'sleep 3600 &'
-- the sleep will be killed by SIGHUP despite it being adopted by init.
– mosvy
Feb 27 at 19:28
In the second case, resending SIGHUP is something very specific tobash
, other shells don't do that (only sleeping background processes will be sent CONT + HUP by the kernel). Also, onlyxterm
is sending aSIGHUP
to the fg process group in the terminal -- most other terminal emulators will just close the master side of the pty, causing aSIGHUP
to be sent by kernel.
– mosvy
Feb 27 at 19:37
1
@Kev any program (eg. chromium) may reset the SIGHUP handler to default (ie terminate). Try running it assetsid chromium &
instead.
– mosvy
Mar 3 at 16:43
|
show 2 more comments
What happens in the first case:
After the last command in the script is backgrounded, the shell executing the script exits immediately. This shell process was the parent process of the 3 programs started from the script. Now that their parent process has exited, the PID-1 process (init
or systemd
often nowadays) becomes their parent process.
The link between the terminal and the programs started from the script is gone, because the terminal program is not their (grand)parent process anymore.
What happens in the second case:
After the last backgrounded process, the script stays alive to run the loop. When the terminal exits, it sends SIGHUP to its child processes; the shell being its child, propagates this signal to its child processes (your programs).
The default action when a process receives a HUP signal is to exit. Apparently VSCode
ignores SIGHUP, or fork()
s away from its parent process, so it is not affected.
1
Note:nohup thunderbird &
should make the difference in the 2nd case.
– Kamil Maciorowski
Feb 27 at 17:45
2
@KamilMaciorowski or better(trap '' HUP; thunderbird &)
– mosvy
Feb 27 at 18:47
1
In the first case, they're not receiving a SIGHUP because their process group is not the foreground process group in the terminal, *not( because the terminal emulator is no longer their grandparent. You can easily check withxterm -e sh -c 'sleep 3600 &'
-- the sleep will be killed by SIGHUP despite it being adopted by init.
– mosvy
Feb 27 at 19:28
In the second case, resending SIGHUP is something very specific tobash
, other shells don't do that (only sleeping background processes will be sent CONT + HUP by the kernel). Also, onlyxterm
is sending aSIGHUP
to the fg process group in the terminal -- most other terminal emulators will just close the master side of the pty, causing aSIGHUP
to be sent by kernel.
– mosvy
Feb 27 at 19:37
1
@Kev any program (eg. chromium) may reset the SIGHUP handler to default (ie terminate). Try running it assetsid chromium &
instead.
– mosvy
Mar 3 at 16:43
|
show 2 more comments
What happens in the first case:
After the last command in the script is backgrounded, the shell executing the script exits immediately. This shell process was the parent process of the 3 programs started from the script. Now that their parent process has exited, the PID-1 process (init
or systemd
often nowadays) becomes their parent process.
The link between the terminal and the programs started from the script is gone, because the terminal program is not their (grand)parent process anymore.
What happens in the second case:
After the last backgrounded process, the script stays alive to run the loop. When the terminal exits, it sends SIGHUP to its child processes; the shell being its child, propagates this signal to its child processes (your programs).
The default action when a process receives a HUP signal is to exit. Apparently VSCode
ignores SIGHUP, or fork()
s away from its parent process, so it is not affected.
What happens in the first case:
After the last command in the script is backgrounded, the shell executing the script exits immediately. This shell process was the parent process of the 3 programs started from the script. Now that their parent process has exited, the PID-1 process (init
or systemd
often nowadays) becomes their parent process.
The link between the terminal and the programs started from the script is gone, because the terminal program is not their (grand)parent process anymore.
What happens in the second case:
After the last backgrounded process, the script stays alive to run the loop. When the terminal exits, it sends SIGHUP to its child processes; the shell being its child, propagates this signal to its child processes (your programs).
The default action when a process receives a HUP signal is to exit. Apparently VSCode
ignores SIGHUP, or fork()
s away from its parent process, so it is not affected.
edited Feb 27 at 23:24
Jeff Schaller
43.9k1161141
43.9k1161141
answered Feb 27 at 16:35
HkoofHkoof
1,13269
1,13269
1
Note:nohup thunderbird &
should make the difference in the 2nd case.
– Kamil Maciorowski
Feb 27 at 17:45
2
@KamilMaciorowski or better(trap '' HUP; thunderbird &)
– mosvy
Feb 27 at 18:47
1
In the first case, they're not receiving a SIGHUP because their process group is not the foreground process group in the terminal, *not( because the terminal emulator is no longer their grandparent. You can easily check withxterm -e sh -c 'sleep 3600 &'
-- the sleep will be killed by SIGHUP despite it being adopted by init.
– mosvy
Feb 27 at 19:28
In the second case, resending SIGHUP is something very specific tobash
, other shells don't do that (only sleeping background processes will be sent CONT + HUP by the kernel). Also, onlyxterm
is sending aSIGHUP
to the fg process group in the terminal -- most other terminal emulators will just close the master side of the pty, causing aSIGHUP
to be sent by kernel.
– mosvy
Feb 27 at 19:37
1
@Kev any program (eg. chromium) may reset the SIGHUP handler to default (ie terminate). Try running it assetsid chromium &
instead.
– mosvy
Mar 3 at 16:43
|
show 2 more comments
1
Note:nohup thunderbird &
should make the difference in the 2nd case.
– Kamil Maciorowski
Feb 27 at 17:45
2
@KamilMaciorowski or better(trap '' HUP; thunderbird &)
– mosvy
Feb 27 at 18:47
1
In the first case, they're not receiving a SIGHUP because their process group is not the foreground process group in the terminal, *not( because the terminal emulator is no longer their grandparent. You can easily check withxterm -e sh -c 'sleep 3600 &'
-- the sleep will be killed by SIGHUP despite it being adopted by init.
– mosvy
Feb 27 at 19:28
In the second case, resending SIGHUP is something very specific tobash
, other shells don't do that (only sleeping background processes will be sent CONT + HUP by the kernel). Also, onlyxterm
is sending aSIGHUP
to the fg process group in the terminal -- most other terminal emulators will just close the master side of the pty, causing aSIGHUP
to be sent by kernel.
– mosvy
Feb 27 at 19:37
1
@Kev any program (eg. chromium) may reset the SIGHUP handler to default (ie terminate). Try running it assetsid chromium &
instead.
– mosvy
Mar 3 at 16:43
1
1
Note:
nohup thunderbird &
should make the difference in the 2nd case.– Kamil Maciorowski
Feb 27 at 17:45
Note:
nohup thunderbird &
should make the difference in the 2nd case.– Kamil Maciorowski
Feb 27 at 17:45
2
2
@KamilMaciorowski or better
(trap '' HUP; thunderbird &)
– mosvy
Feb 27 at 18:47
@KamilMaciorowski or better
(trap '' HUP; thunderbird &)
– mosvy
Feb 27 at 18:47
1
1
In the first case, they're not receiving a SIGHUP because their process group is not the foreground process group in the terminal, *not( because the terminal emulator is no longer their grandparent. You can easily check with
xterm -e sh -c 'sleep 3600 &'
-- the sleep will be killed by SIGHUP despite it being adopted by init.– mosvy
Feb 27 at 19:28
In the first case, they're not receiving a SIGHUP because their process group is not the foreground process group in the terminal, *not( because the terminal emulator is no longer their grandparent. You can easily check with
xterm -e sh -c 'sleep 3600 &'
-- the sleep will be killed by SIGHUP despite it being adopted by init.– mosvy
Feb 27 at 19:28
In the second case, resending SIGHUP is something very specific to
bash
, other shells don't do that (only sleeping background processes will be sent CONT + HUP by the kernel). Also, only xterm
is sending a SIGHUP
to the fg process group in the terminal -- most other terminal emulators will just close the master side of the pty, causing a SIGHUP
to be sent by kernel.– mosvy
Feb 27 at 19:37
In the second case, resending SIGHUP is something very specific to
bash
, other shells don't do that (only sleeping background processes will be sent CONT + HUP by the kernel). Also, only xterm
is sending a SIGHUP
to the fg process group in the terminal -- most other terminal emulators will just close the master side of the pty, causing a SIGHUP
to be sent by kernel.– mosvy
Feb 27 at 19:37
1
1
@Kev any program (eg. chromium) may reset the SIGHUP handler to default (ie terminate). Try running it as
setsid chromium &
instead.– mosvy
Mar 3 at 16:43
@Kev any program (eg. chromium) may reset the SIGHUP handler to default (ie terminate). Try running it as
setsid chromium &
instead.– mosvy
Mar 3 at 16:43
|
show 2 more comments
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.
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%2f503289%2fbash-behaviour-inconsistent-when-theres-a-loop-at-the-end-of-the-script%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