where is SIGHUP from? (sshd forks a child to create a new session, kill this child and all processes in the session dies)

sshd forks a child process to create a new session. here is the output(partial) of pstree:

sshd(1230) -- sshd(1234) -- bash
           (...)    
             |- sshd(12开发者_运维技巧35) -- bash -- a.out -- a.out

After running "kill -9 1235" , a.out dies (the signal captured is SIGHUP)

Why?

tks!

---

ssh (along with terminal emulators, screen, tmux, script, and some other programs) uses a thing called a "pseudo-tty" (or "pty"), which behaves like a dialup modem connection. I describe it that way because that's the historical origin of this behavior: if you lost your modem connection for some reason, the tty (or pty) driver detected the loss of carrier and sent SIGHUP ("Hangup") to your session. This enables programs to save their state (for example, vi/vim will save any files you had modified but not saved for recovery) and shut down cleanly. Similarly, if the network connection goes away for some reason (someone tripped over the power or network cable? ...or sssh dumped core for some odd reason), the pty sends SIGHUP to your session so it gets a chance to save any unsaved data.

Technically, the tty/pty driver sends the signal to every process in the process group attached to the terminal (process groups are also related to shell job control, but this was their original purpose). Some other terminal signals are handled the same way, for example Ctrl + C sends SIGINT and Ctrl + \ sends SIGQUIT (and Ctrl + Z sends SIGTSTP, and programs that don't handle SIGTSTP by suspending themselves are sent SIGSTOP; this double signal allows vim to set the terminal back from editing mode to normal mode and in many terminal emulators swap to the pre-editing screen buffer).