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

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?

Answer 1

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.