Editar para 2016:
Estas preguntas y respuestas son anteriores a la debacle de systemd v230 . A partir de systemd v230, el nuevo valor predeterminado es matar a todos los hijos de una sesión de inicio de sesión final, independientemente de las precauciones históricamente válidas que se tomaron para evitar esto. El comportamiento se puede cambiar mediante el establecimiento KillUserProcesses=no
en /etc/systemd/logind.conf
, o eludidas mediante los mecanismos de systemd específico para el inicio de un daemon en el espacio de usuario. Esos mecanismos están fuera del alcance de esta pregunta.
El texto a continuación describe cómo las cosas han funcionado tradicionalmente en el espacio de diseño de UNIX durante más tiempo del que Linux ha existido.
Los matarán, pero no necesariamente de inmediato. Depende de cuánto tiempo le tome al demonio SSH decidir que su conexión está desconectada. Lo que sigue es una explicación más larga que lo ayudará a comprender cómo funciona realmente.
Cuando inició sesión, el daemon SSH le asignó un pseudo-terminal y lo adjuntó al shell de inicio de sesión configurado de su usuario. Esto se llama terminal de control. Cada programa que inicie normalmente en ese punto, sin importar cuántas capas de capas profundas, finalmente rastreará su ascendencia hasta esa capa. Puedes observar esto con el pstree
comando.
Cuando el proceso del demonio SSH asociado con su conexión decide que su conexión está inactiva, envía una señal de bloqueo ( SIGHUP
) al shell de inicio de sesión. Esto notifica al shell que desapareció y que debería comenzar a limpiarse después de sí mismo. Lo que sucede en este punto es específico del shell (busque "HUP" en su página de documentación), pero en su mayor parte comenzará a enviarse SIGHUP
a trabajos en ejecución asociados antes de finalizar. Cada uno de esos procesos, a su vez, hará lo que sea que estén configurados para hacer al recibir esa señal. Por lo general, eso significa terminar. Si esos trabajos tienen trabajos propios, la señal a menudo también se transmitirá.
Los procesos que sobreviven a un bloqueo del terminal de control son aquellos que se desasociaron de tener un terminal (procesos de daemon que comenzaste dentro de él) o que se invocaron con un nohup
comando prefijado . (es decir, "no cuelgues en esto") Daemons interpreta la señal HUP de manera diferente; dado que no tienen un terminal de control y no reciben automáticamente una señal HUP, en cambio, se reutiliza como una solicitud manual del administrador para volver a cargar la configuración. Irónicamente, esto significa que la mayoría de los administradores no aprenden el uso "colgado" de esta señal para los no demonios hasta mucho, mucho más tarde. ¡Es por eso que estás leyendo esto!
Los multiplexores de terminales son una forma común de mantener intacto su entorno de shell entre desconexiones. Le permiten desconectarse de sus procesos de shell de manera que pueda volver a conectarlos más tarde, independientemente de si esa desconexión fue accidental o deliberada. tmux
y screen
son los más populares; la sintaxis para usarlos está más allá del alcance de su pregunta, pero vale la pena analizarlos.
Se me solicitó que explicara cuánto tiempo le lleva al demonio SSH decidir que su conexión está desconectada. Este es un comportamiento que es específico de cada implementación de un demonio SSH, pero puede contar con que todos terminen cuando cualquier lado restablezca la conexión TCP. Esto sucederá rápidamente si el servidor intenta escribir en el socket y no se reconocen los paquetes TCP, o lentamente si nada intenta escribir en el PTY.
En este contexto particular, los factores más probables para desencadenar una escritura son:
- Un proceso (generalmente el que está en primer plano) que intenta escribir en el PTY en el lado del servidor. (servidor-> cliente)
- El usuario que intenta escribir en el PTY en el lado del cliente. (cliente-> servidor)
- Keepalives de cualquier tipo. Por lo general, estos no están habilitados de forma predeterminada, ya sea por el cliente o el servidor, y generalmente hay dos tipos: nivel de aplicación y basado en TCP (es decir
SO_KEEPALIVE
). Keepalives equivale a que el servidor o el cliente envían paquetes con poca frecuencia al otro lado, incluso cuando nada tendría una razón para escribir en el socket. Si bien esto normalmente tiene como objetivo eludir los cortafuegos que desconectan las conexiones demasiado rápido, tiene el efecto secundario adicional de hacer que el remitente se dé cuenta cuando el otro lado no responde mucho más rápido.
Las reglas habituales para las sesiones TCP se aplican aquí: si hay una interrupción en la conectividad entre el cliente y el servidor, pero ninguna de las partes intenta enviar un paquete durante el problema, la conexión sobrevivirá siempre que ambas partes respondan después y reciban el TCP esperado números de secuencia
Si un lado ha decidido que el socket está muerto, los efectos suelen ser inmediatos: el proceso sshd se enviará HUP
y finalizará automáticamente (como se describió anteriormente), o el cliente notificará al usuario el problema detectado. Vale la pena señalar que solo porque un lado piense que el otro está muerto no significa que el otro haya sido notificado de esto. El lado huérfano de la conexión generalmente permanecerá abierto hasta que intente escribir en él y se agote el tiempo de espera, o reciba un restablecimiento de TCP desde el otro lado. (si la conectividad estaba disponible en ese momento) La limpieza descrita en esta respuesta solo ocurre una vez que el servidor se ha dado cuenta.
screen
, intente reptyr .