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


Entonces, digamos que me desconecto de una sesión SSH después de haber comenzado rsync o cp o cualquier otro comando que pueda ser de larga duración. ¿El comando continúa ejecutándose hasta que finaliza después de que me desconecte o simplemente muere?

Siempre me preguntaba esto.


75
2018-01-06 03:09


origen


Solo quiero agregar a lo que se ha dicho anteriormente, si se encuentra en una situación en la que necesita poner un proceso ya en ejecución en screen, tratar reptyr. - a sad dude


Respuestas:


Edición para el 2016:

Esta Q&A es anterior a la systemd v230 debacle. A partir de systemd v230, el nuevo valor predeterminado es matar a todos los hijos de una sesión de inicio de sesión de terminación, independientemente de las precauciones históricamente válidas que se tomaron para evitar esto. El comportamiento se puede cambiar configurando KillUserProcesses=no en /etc/systemd/logind.conf, o evitado utilizando los mecanismos específicos de systemd para iniciar 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 UNIX por más tiempo que ha existido Linux.


Los matarán, pero no necesariamente de inmediato. Depende de cuánto tiempo demore el demonio SSH para decidir que su conexión está muerta. Lo que sigue es una explicación más larga que te ayudará a entender 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 de su usuario. Esto se llama el terminal de control. Cada programa que comienzas normalmente en ese punto, sin importar en cuántas capas de conchas estén profundas, finalmente remontará su ascendencia a esa concha. Puedes observar esto con la pstree mando.

Cuando el proceso del demonio SSH asociado con su conexión decide que su conexión está muerta, envía una señal de bloqueo (SIGHUP) al shell de inicio de sesión. Esto notifica al shell que has 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 la página de documentación "HUP"), pero en su mayor parte comenzará a enviar SIGHUP para ejecutar trabajos asociados con él antes de terminar. Cada uno de esos procesos, a su vez, hará lo 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 una suspensión del terminal de control son aquellos que se desvincularon de tener un terminal (procesos de demonio que inició dentro de él) o aquellos que se invocaron con un prefijo nohup mando. (es decir, "no cuelgue de esto") Los demonios interpretan la señal HUP de manera diferente; Ya 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 recargar 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. ¡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 separarse de sus procesos de shell de una manera que puede volver a unirlos más tarde, sin importar si esa desconexión fue accidental o deliberada. tmuxy 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 explique 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 todos ellos para terminar cuando cualquiera de los dos lados reinicia 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 propensos a 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 manera 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 al otro lado con poca frecuencia, incluso cuando nada tendría una razón para escribir en el socket. Si bien esto normalmente está destinado a evitar los cortafuegos que agotan el tiempo de las conexiones demasiado rápido, tiene el efecto secundario adicional de hacer que el remitente se dé cuenta de que la otra parte no responde mucho más rápidamente.

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 ninguno de los dos lados 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 son generalmente inmediatos: el proceso sshd se enviará HUP y finaliza automáticamente (como se describió anteriormente), o el cliente notificará al usuario del 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 normalmente permanecerá abierto hasta que intente escribir en él y se agote el tiempo de espera, o reciba un reinicio 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 servidor ha notado


108
2018-01-06 04:36



También agregaría el comando 'dtach' a esa lista: es una especie de opuesto a screen / tmux en que le permite conectar múltiples terminales a una sola sesión, y también es ideal para prolongar una sesión, aunque no Proporcionar cualquier medio de reproducir la historia reciente. - fluffy
dtach url está aquí: dtach.sourceforge.net - slm
excelente explicacion ¡Ya me siento más linuxey! - fregas
Además, si bien no es técnicamente parte de tu respuesta, aquí hay un poco de curiosidad interesante: puedes usar kill -HUP como root para forzar el terminal de alguien a colgar. No deberías hacer esto sin una buena razón. Aprovecho la mayor parte de mi kilometraje cuando los usuarios dejan shells en ejecución durante el mantenimiento y necesito desmontar un sistema de archivos que su shell mantiene abierto. Si el usuario está conectado pero está inactivo, envíe la señal a su proceso sshd. De lo contrario, si se está ejecutando dentro de un multiplexor de terminal, envíelo al shell que desea detener. ¡Solo cuelga la concha que te impide trabajar! - Andrew B
@AndrewB, ¿podría explicar cómo "el proceso del demonio SSH ... decide que su conexión está muerta"? ¿Y cómo puedo saber si el demonio SSH piensa / sabe que la conexión (que) está muerta o no? - Xiao Peng - ZenUML.com


Como han mencionado otros, una vez que se desconecta de ssh, todo lo que se ejecuta dentro de él desaparece.

Como @Michael Hampton y otros han mencionado que puedes usar herramientas como tmux o screen para desconectarse / reconectarse a los terminales sin perder su contenido (es decir, procesos secundarios).

Además, puede poner un proceso en segundo plano utilizando un símbolo & y luego usar el comando disown Para desasociarlos con el shell actual.

# start a command
% sleep 5000 &
[1] 3820

# check it
% jobs
[1]+  Running                 sleep 5000 &

# disown everything
% disown -a

# check it again (gone from shell)
% jobs
%

# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml      3820 23791  0 00:16 pts/1    00:00:00 sleep 5000
%

21
2018-01-06 05:27



¿Es posible volver a conectar una sesión de terminal a un disownproceso de ed? - Fake Name
Sí. Vea esta pregunta de U&L para detalles: unix.stackexchange.com/questions/4034/… - slm


No, cualquier programa que aún esté conectado al terminal y que no esté en segundo plano con algo como nohup, sería asesinado.

Es por esto que existen soluciones de terminal virtual como tmux y el mayor screen que crea sesiones que continúan ejecutándose incluso si está desconectado, y a las que puede volver a conectar más tarde.


11
2018-01-06 03:16