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?


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

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.