Solución 1:
Intentar conectar los descriptores de archivo STD* actuales de una terminal nueva a un proceso antiguo en ejecución es solo buscar problemas. Incluso si logra hacer eso, el control de trabajo de la terminal no funcionará como se esperaba. Tendrá un lío dejado atrás si finalmente sale del programa tomado, y lo que sucede con el shell que sacrificó sus descriptores de archivo para pasar al proceso recién en segundo plano. ¿Se mantendrá ssh abierto cuando desaparezca ese caparazón? Probablemente no. Por lo tanto, primero deberá redirigirlo a otro lugar.
Posible o no, apostaría a que es más deseable dejar que el proceso abandonado se elimine "naturalmente". Si está haciendo algo lo suficientemente importante como para justificar el intento de realizar toda la piratería necesaria para retomar 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 bote de control separado). :)
Solución 2:
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 desconectará la sesión ssh. El proceso junto con la sesión de tty parece seguir ejecutándose, pero no podemos volver a conectarnos. 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/cambiando-ctty/
Solución 3:
En general, la forma correcta de manejar esto es prepararse con anticipación, usando GNU screen o el nohup de bash o disown mecanismos. Si está utilizando tcsh , el shell rechazará los trabajos en segundo plano cuando finalice de forma anormal.
Si no estás usando screen pero he logrado mantener su proceso en ejecución a través de uno de los disown métodos, es posible que pueda fingir que se vuelve a conectar al proceso con gdb (fuente):
[...] con algunos trucos sucios, no es imposible reabrir un proceso'stdout/stderr/stdin. [...]
Y luego use gdb, por ejemplo, para adjuntarlo al proceso, haga alguna llamada close (0)
cierre de llamada (1)
cierre de llamada (2)
llamada abierta("/dev/pts/xx", ...)
duplicar llamada(0)
duplicar llamada(0)
separar
Ahora, tendría que modificar este proceso para su situación. Dudo que te ayude si no has logrado repudiar el proceso. Si estás usando bash , vea esta publicación sobre cómo hacer bash automáticamente desautorizar procesos en segundo plano al salir (básicamente, desactivar huponexit con comprar ). Con un proceso en primer plano, debe haber utilizado nohup .