Reanudar comando que se ejecuta en sesión SSH caída

Leer esta pregunta me hizo preguntarme. Suponiendo screenque no se está utilizando. Si una sesión SSH en un destino Linux se descarta, por cualquier razón, y se vuelve a conectar antes de que el servidor cierre la sesión debido al tiempo de espera, ¿es posible recuperar el control del comando en ejecución de modo que no se cancele debido a la sesión interrumpida? ?

Intentar conectar los descriptores de archivo STD * actuales de un nuevo terminal a un antiguo proceso en ejecución es solo pedir problemas. Incluso si logras hacer eso, el control de trabajo de la terminal no funcionará como se esperaba. Tendrá un desastre si finalmente sale del programa tomado y lo que le sucede al shell que sacrificó sus descriptores de archivo para ser entregados al proceso de fondo. ¿SSH permanecerá abierto cuando ese caparazón desaparezca? Probablemente no. Por lo tanto, primero deberá redirigirlo a otro lugar.

Posible o no, apostaría que es más deseable simplemente dejar que el proceso abandonado sea asesinado "naturalmente". Si está haciendo algo lo suficientemente importante como para justificar el intento de hacer todo el pirateo informático necesario para reanudar el control y está en un enlace inestable, probablemente debería saberlo de antemano y simplemente usar la pantalla (o vnc, o lo que sea que flote en su dispositivo separado) barco de control). :)

Sé que esta es una vieja pregunta, pero sentí que es importante agregar mis hallazgos en caso de que alguien más se encuentre con esto como yo.

No he visto ninguna consecuencia inusual al hacer esto, sí, pero esto es lo que usé y funcionó increíblemente. A veces, cuando ejecutamos procesos largos en nuestro servidor, ocasionalmente desconecta la sesión ssh. El proceso junto con la sesión tty parece seguir ejecutándose, pero no podemos volver a conectarnos con él. Encontré el programa a continuación para llevar el proceso a la sesión recién conectada.

https://github.com/nelhage/reptyr

Aquí hay más información

https://blog.nelhage.com/2011/02/changing-ctty/

En general, la forma correcta de manejar esto es prepararse con anticipación, utilizando GNU screeno bash nohupo disownmecanismos. Si está utilizando tcsh, el shell rechazará los trabajos en segundo plano cuando salga de forma anormal.

Si no está usando screenpero ha logrado mantener su proceso ejecutándose a través de uno de los métodos desconocidos , es posible que pueda simular la reconexión al proceso con gdb( fuente ):

[...] con algunos trucos sucios, no es imposible volver a abrir un proceso 'stdout / stderr / stdin. [...]

Y luego use gdb, por ejemplo, para adjuntarlo al proceso, haga una llamada close (0)
call close (1)
call close (2)
call open ("/ dev / pts / xx", ...)
call dup (0)
llamar a dup (0)
separar

Ahora, tendría que ajustar este proceso para su situación. Dudo que ayude si no has logrado rechazar el proceso. Si está utilizando bash, vea esta publicación sobre cómo hacer que bash rechace automáticamente los procesos en segundo plano al salir (básicamente, apague huponexit con shopt ). Con un proceso en primer plano, debe haber usado nohup .

Probablemente no. No puedo garantizar que sea imposible, pero realmente lo dudo.

Una cosa es la falta de matar el shell y los posibles comandos que se ejecutan como consecuencia de la terminación de la conexión ssh. Esto no es tan difícil, debería poder usar nohup y mecanismos similares como se menciona en la otra pregunta.

Pero entonces, suponga que comenzó ssh somehost nuhup vim /some/filey la conexión se apaga. Ejecuta ssh somehostpara iniciar sesión nuevamente y puede ver que su proceso vim todavía se está ejecutando. Pero entonces, ¿cómo te conectas a ese proceso nuevamente? Los procesos forground interactivos tienen un tty de control y el que se abrió para su proceso vim cuando comenzó se habría cerrado desde entonces. No estoy seguro de si hay alguna forma de "reabrirlo" nuevamente en su nuevo shell (al igual que si tiene varios trabajos en segundo plano ejecutándose en un shell, no puede poner en primer plano ninguno de los de otro shell).

Screense ha escrito explícitamente para tener esta funcionalidad. Al inicio, bifurca dos procesos, un proceso de administración de terminales y un proceso de cliente. La interacción es la aplicación cliente <--> terminal manager <-->, y cuando desconecta o pierde la conexión, el proceso del cliente muere mientras el administrador de terminal continúa vivo. Screen tiene algún soporte específico para adjuntar al proceso de administración de terminales nuevamente más adelante, y no creo que esto sea posible en el caso general.

retty podría ayudarte, pero las renuncias son muy reales y relevantes :)

Si la sesión se descarta, significa que TTL ya ha expirado, por lo que no hay más tty para usted (según tengo entendido). Pero, si su conexión de red se interrumpe, es posible que su sesión de SSH no deba interrumpirse, y debería poder reanudar su conexión y continuar. ¿Es eso lo que estás preguntando?

Había un enlace a algún código de robo hacky tty en esta pregunta . Teóricamente deberías poder usar esto para recuperar el control de un proceso nohup.