3

As we know, when the ssh connection is gone, the bash will receive a SIGHUP, and forward this signal to all its children.

I wonder who is the original sender of this SIGHUP, is it ssh client, ssh server, OS or something else?

I read the code of openssh-portabal, and I found only here uses the SIGHUP: https://github.com/openssh/openssh-portable/blob/master/sshconnect.c#L285

And the caller seems to be client: https://github.com/openssh/openssh-portable/blob/master/ssh.c#L1533

I didn't find any sender code in the server-side sshd.c

Does this mean that the sender is client? In this case, the SIGHUP will not be received by the server if the connection was interrupted. I'm not pretty sure about this, but in my experience this doesn't seem to be true.

So I'm curious about who is supposed to be the original sender. Is there a standard for this?

caf
  • 233,326
  • 40
  • 323
  • 462
user3458198
  • 311
  • 1
  • 8

1 Answers1

7

The bash process on the server side of the connection is running with its controlling terminal set to the slave side of a pseudo-terminal pair, with the master side attached to the sshd process.

When the connection is terminated, the sshd process closes the master side of the pseudo-terminal, which results in the kernel pseudo-terminal driver hanging up the slave side of the pseudo-terminal. When the slave side is hung up, the kernel tty core sends SIGHUP and SIGCONT signals to the terminal's session leader (which is usually that bash process) and every process in the session leader's process group.

This isn't specific to pseudo-terminals and ssh - the same thing happens if you are dialled in to the server over a modem attached to a serial port and the modem hangs up (which is where the "hang up" / SIGHUP naming originates). As you can tell, this is historical behaviour of very long standing.

caf
  • 233,326
  • 40
  • 323
  • 462
  • It seems that the original SIGHUP is only sent to the session leader(which is usually that bash process), but not the `every process in the session leader's process group`, it is the bash that forward the SIGHUP to its children, this forwarding behavior can be controlled by Bash settings. – osexp2000 May 29 '23 at 01:28
  • Oh, found it depends on whether the child processes are foreground or background. https://man7.org/linux/man-pages/man2/setsid.2.html : `If a process that is a session leader terminates, then a SIGHUP signal is sent to each process in the foreground process group of the controlling terminal.` – osexp2000 May 29 '23 at 03:00
  • @osexp2000: Yes, background processes are in a different process group. – caf May 30 '23 at 02:50