linux – ¿Desconectarse de una sesión SSH mata sus programas?

Pregunta:

Entonces, digamos que me desconecto de una sesión SSH después de haber iniciado rsync o cp o cualquier otro comando que pueda durar mucho tiempo. ¿Ese comando sigue ejecutándose hasta que finaliza después de que me desconecten o simplemente lo matan?

Siempre me pregunté esto.

Respuesta:

Editar para 2016:

Esta sesión de preguntas y respuestas es anterior a la debacle de systemd v230 . A partir de systemd v230, el nuevo valor predeterminado es eliminar a todos los hijos de una sesión de inicio de sesión que finaliza, independientemente de las precauciones históricamente válidas que se hayan tomado para evitar esto. El comportamiento se puede cambiar configurando KillUserProcesses=no en /etc/systemd/logind.conf , o se puede eludir usando los mecanismos específicos de systemd para iniciar un demonio en el espacio de usuario. Esos mecanismos están fuera del alcance de esta pregunta.

El texto siguiente describe cómo las cosas han funcionado tradicionalmente en el espacio de diseño de UNIX durante más tiempo del que ha existido Linux.


Serán asesinados, pero no necesariamente de inmediato. Depende de cuánto tiempo le tome al demonio SSH decidir que su conexión está muerta. Lo que sigue es una explicación más extensa que le ayudará a comprender cómo funciona realmente.

Cuando inició sesión, el demonio SSH le asignó un pseudo-terminal y lo adjuntó al shell de inicio de sesión configurado por su usuario. Esto se llama terminal de control. Cada programa que inicie normalmente en ese punto, sin importar cuántas capas de caparazones tenga, finalmente rastreará su ascendencia hasta ese caparazón. Puede observar esto con el comando pstree .

Cuando el proceso del demonio SSH asociado con su conexión decide que su conexión está muerta, envía una señal de SIGHUP ( SIGHUP ) al shell de inicio de sesión. Esto notifica al caparazón que ha desaparecido y que debería comenzar a limpiarse después de sí mismo. Lo que sucede en este punto es específico del shell (busque en su página de documentación "HUP"), pero en su mayor parte comenzará a enviar SIGHUP a los trabajos en ejecución asociados con él antes de terminar. Cada uno de esos procesos, a su vez, hará lo que esté configurado 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 de la terminal de control son aquellos que se desvincularon de tener una terminal (procesos demonio que inició dentro de ella), o aquellos que fueron invocados con un comando nohup prefijado. (es decir, "no cuelgue esto") Los demonios interpretan 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 su lugar 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 de "colgar" de esta señal para los que no son demonios hasta mucho, mucho más tarde. ¡Por eso estás leyendo esto!

Los multiplexores de terminal 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 adjuntarlos 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 solicitó que explicara cuánto tiempo tarda el demonio SSH en decidir que su conexión está muerta. Este es un comportamiento que es específico para cada implementación de un demonio SSH, pero puede contar con que todos terminen cuando cualquiera de los lados restablezca la conexión TCP. Esto sucederá rápidamente si el servidor intenta escribir en el socket y los paquetes TCP no son reconocidos, o lentamente si nada intenta escribir en el PTY.

En este contexto particular, los factores con más probabilidad de desencadenar una escritura son:

  • Un proceso (normalmente 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 normalmente 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íen paquetes con poca frecuencia al otro lado, incluso cuando nada tendría una razón para escribir en el socket. Si bien esto generalmente tiene la intención de evitar los firewalls que agotan 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 de 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 enviará HUP y terminará automáticamente (como se describió anteriormente), o el cliente notificará al usuario del problema detectado. Vale la pena señalar que el hecho de que 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.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım