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?

score 4 · Accepted Answer · edited Feb 27 '19 at 23:24

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.

edited Feb 27 '19 at 23:24

Jeff Schaller

67,283
35
116
255

answered Feb 27 '19 at 16:35

Hkoof

1,667

1

Note: nohup thunderbird & should make the difference in the 2nd case. – Kamil Maciorowski Feb 27 '19 at 17:45
2

@KamilMaciorowski or better (trap '' HUP; thunderbird &) – Feb 27 '19 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. – Feb 27 '19 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. – Feb 27 '19 at 19:37
It's interesting that the nohup and trap tricks both don't seem to work for keeping Chromium open, but they do keep Thunderbird going. – Kev Mar 01 '19 at 06:52
1

@Kev any program (eg. chromium) may reset the SIGHUP handler to default (ie terminate). Try running it as setsid chromium & instead. – Mar 03 '19 at 16:43
@mosvy Indeed, that works! Great to know! :) – Kev Mar 04 '19 at 06:36

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

1 Answers1