Кто является исходным отправителем SIGHUP, когда ssh-соединение закрыто? - PullRequest
2 голосов
/ 06 марта 2019

Как мы знаем, когда соединение ssh исчезло, bash получит сигнал SIGHUP и направит этот сигнал всем своим дочерним элементам.

Интересно, кто является исходным отправителем этого SIGHUP, это ssh клиент, ssh сервер, ОС или что-то еще?

Я прочитал код openssh-portabal и обнаружил, что только здесь используется SIGHUP: https://github.com/openssh/openssh-portable/blob/master/sshconnect.c#L285

И вызывающий абонент, кажется, клиент: https://github.com/openssh/openssh-portable/blob/master/ssh.c#L1533

Я не нашел кода отправителя в серверном sshd.c

Значит ли это, что отправитель является клиентом? В этом случае SIGHUP не будет получен сервером, если соединение было прервано. Я не совсем уверен в этом, но по моему опыту это не похоже на правду.

Так что мне интересно, кто должен быть первоначальным отправителем. Есть ли для этого стандарт?

1 Ответ

4 голосов
/ 06 марта 2019

Процесс bash на стороне сервера соединения выполняется с его управляющим терминалом, установленным на подчиненную сторону пары псевдотерминалов, а ведущая сторона подключена к процессу sshd.

Когда соединение завершается, процесс sshd закрывает главную сторону псевдотерминала, что приводит к тому, что драйвер псевдотерминала ядра вешает ведомую сторону псевдотерминала. Когда подчиненная сторона зависает, ядро ​​tty ядра отправляет сигналы SIGHUP и SIGCONT руководителю сеанса терминала (обычно это процесс bash) и каждому процессу в группе процессов руководителя сеанса.

Это не относится только к псевдотерминалам и ssh - то же самое происходит, если вы подключаетесь к серверу через модем, подключенный к последовательному порту, и модем зависает (именно здесь "зависает" / SIGHUP присвоение имен происходит). Как вы можете сказать, это историческое поведение очень давно.

...