I read an answer from a user who claimed that running
foo 2>&1 >& output.log &
would result in
foo continuing to run even when they log out. According to this user, this even worked over SSH connections.
I didn't really believe that, as I was under the impression that in the case of disconnecting from SSH, or terminating the TTY, the shell and therefore its processes would receive a SIGHUP, causing them to terminate. This, under my assumption, was the sole reason for using
nohup in such cases, or
screen et al.
I then looked into glibc's manual:
This signal is also used to report the termination of the controlling process on a terminal to jobs associated with that session; this termination effectively disconnects all processes in the session from the controlling terminal.
This seems to confirm my thoughts. But looking further, it says:
If the process is a session leader that has a controlling terminal, then a SIGHUP signal is sent to each process in the foreground job, and the controlling terminal is disassociated from that session.
So, does this mean jobs put in background will not receive SIGHUP?
To my further confusion, I ran an interactive Zsh session, ran
yes >& /dev/null &, and typed
exit, when Zsh warned me that I had running jobs, and after typing
exit for a second time, told me that it had SIGHUPed one job. Doing exactly the same in Bash leaves the job running…
yesis still running.