Gilles said
nohup and disown both can be said to suppress SIGHUP, but in different ways. nohup makes the program ignore the signal initially (the program may change this). nohup also tries to arrange for the program not to have a controlling terminal, so that it won't be sent SIGHUP by the kernel when the terminal is closed. disown is purely internal to the shell; it causes the shell not to send SIGHUP when it terminates.
$ nohup sleep 100 &
[1] 7882
nohup: ignoring input and appending output to 'nohup.out'
$ get-terminal-info-of-a-process.sh 7882
COMMAND CMD TT PID PPID CGNAME CGROUP PGID TPGID SESS SESSION OWNER
sleep 100 sleep 100 pts/5 7882 6780 systemd:/user.slice/user-10 7:pids:/user.slice/user-100 7882 7885 6780 c2 1000
$ tty
/dev/pts/5
the nohup
ed process still has the same tty as the invoking shell: /dev/pts/5
. So I wonder what Gilles meant by "nohup also tries to arrange for the program not to have a controlling terminal, so that it won't be sent SIGHUP by the kernel when the terminal is closed"?
If what he said is true, how does nohup
achieve to detach a program from a controlling terminal, in terms of which Linux API or system call function(s)?
Thanks.
Best Answer
As I, in turn, said, a process running via
nohup
most definitely still is associated with a login session and a controlling terminal. After all, if it were not, there would be no point to the gynmastics of ignoring controlling terminal hangup.nohup
is a simple chain loading program that does two things, redirect standard output and ignore the hangup signal, before chain loading the target program.Here is the code of
nohup
from FreeBSD, from NetBSD, from OpenBSD, and from the TENEX C shell. As can be seen, there is no manipulation of sessions or controlling terminals.