Bash ` &` behaviour inconsistent when there's a loop at the end of the script

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












1















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?










share|improve this question




























    1















    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?










    share|improve this question


























      1












      1








      1








      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?










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Feb 27 at 16:45









      ilkkachu

      62.5k10103179




      62.5k10103179










      asked Feb 27 at 9:54









      KevKev

      95841839




      95841839




















          1 Answer
          1






          active

          oldest

          votes


















          4














          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.






          share|improve this answer




















          • 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 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






          • 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










          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
          );



          );













          draft saved

          draft discarded


















          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









          4














          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.






          share|improve this answer




















          • 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 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






          • 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















          4














          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.






          share|improve this answer




















          • 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 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






          • 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













          4












          4








          4







          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.






          share|improve this answer















          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          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 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






          • 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












          • 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 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






          • 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







          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

















          draft saved

          draft discarded
















































          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.




          draft saved


          draft discarded














          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





















































          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






          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay