¿Cómo puedo volver a conectarme a una sesión ssh después de una tubería rota?

Así que estaba corriendo apt-get upgradeen un servidor cuando el enrutador decidió que había pasado demasiado tiempo desde la última vez que me enojó: se cortó toda conexión. La moraleja de la historia es usar screenmucho cuando estás en un enrutador bum.

De todos modos, volví a iniciar sesión y encontré en htop que el proceso todavía estaba suspendido allí, todavía esperando que mi Y / n se actualizara (por suerte, aún no lo había alcanzado). ¿Hay alguna forma de volver a conectar una sesión que se había interrumpido? Terminé simplemente matándolo, ya que no estaba en el medio de la administración de paquetes, pero sería genial saberlo para referencia futura.

La respuesta a su pregunta correcta es: no puede . Creo que el principal problema es que los procedimientos de autenticación no estarán sincronizados. Simplemente no funciona así.

Como te habrás dado cuenta, la solución es usar la pantalla cuando sea posible (por cierto, tmux es una alternativa a la pantalla).

Para ejecutar procesos duraderos, uso screen o byobu si quieres una interfaz más amigable.

Para la pantalla, puede usar:

screen [program] [args]

Esto ejecutará [programa] y sus [args] dentro de una sesión de pantalla . Una vez que finaliza el programa, la sesión se cierra automáticamente. Si desea mantener la sesión después de que se ejecute su programa, simplemente ejecute la pantalla sin ningún argumento y aparecerá un nuevo mensaje dentro de la sesión. CTRL + A + D separa el terminal de la sesión actual.

Para volver a adjuntar a una sesión anterior:

screen -r

Si solo hay una sesión abierta, se volverá a conectar de inmediato. Si hay varias sesiones en curso, le preguntará a cuál desea adjuntar. Si conoce el nombre de la sesión, puede agregarlo como argumento a esta línea de comando.

Byobu es una buena mejora. Se basa en la pantalla , pero proporciona una barra en la parte inferior que muestra todas las sesiones actuales como pestañas y proporciona accesos directos más fáciles para moverse por ellas. Usted puede:

• F2 comienza una nueva sesión
• F3 pasar a la pestaña de la próxima sesión a la izquierda
• F4 pasar a la pestaña de la próxima sesión a la derecha
• F8 da un nombre descriptivo a la pestaña de la sesión actual
• F9 abre un menú de opciones
• CTRL + A + D separa todas las sesiones del terminal.

PALABRA DE CONSEJO : evite dejar abierta una sesión con el usuario root . Si alguien obtiene acceso a su terminal (local o remotamente), puede volver a conectarse fácilmente a una sesión en curso y utilizar su sistema como root. Si es necesario, es mejor comenzar una sesión usando un usuario común y sudo líneas de comando individuales según sea necesario.

Si bien no puede volver a adjuntar a una sesión SSH interrumpida, puede volver a procesar el proceso que se ejecuta dentro de SSH , funcionalmente equivalente a lo que desea.

Instrucciones

En su caso, se haría cargo del apt-getproceso para ser controlado desde una nueva sesión SSH, screensesión o similar. Mi favorito para esto es el reptyrcomando:

$ sudo apt-get install reptyr
$ ps ax | grep apt-get
10626 pts/8   R+     0:32 apt-get upgrade

Luego, con el pid que encontraste para tu proceso:

$ sudo reptyr -T 10626

O si eso no funciona, intente:

$ reptyr 10626

Después de esta etapa, toda su entrada de teclado va al programa que asumió. Lamentablemente, no verá la salida anterior de la sesión SSH, como la apt-getsalida que le pide confirmación.

Explicaciones

Hay varias otras herramientas que básicamente funcionan igual que reptyr(es decir, a través de ptracearchivos adjuntos de depuración). Vea las siguientes preguntas y respuestas donde se discuten:

• ¿Cómo puedo rechazar un proceso en ejecución y asociarlo a un nuevo shell de pantalla?
• Reanudar comando que se ejecuta en sesión SSH caída

En las instrucciones anteriores, reptyr 10626usa el ptracearchivo adjunto de depuración mientras que el sudo reptyr -T 10626comando usa el robo de TTY y es preferible ( detalles ).

Finalmente, la razón por la que no puede hacerse cargo de una sesión SSH de esta manera es porque un sshdproceso no está controlado por un terminal host, sino que proporciona la parte esclava de un terminal, un ptsdispositivo, mientras que la parte maestra que lo controla reside en el máquina cliente, aquí con una sesión SSH desglosada en el medio. Cuando fuerza la toma de tal sshdproceso con reptyr -s <pid>, su entrada de teclado va a ese proceso, no a su proceso secundario activo. Entonces un "Ctrl + Z" simplemente matará eso sshd.

Estaba haciendo do-dist-upgradevía ssh desde una computadora portátil que entró en suspensión, por lo tanto Broken pipe. Al volver a la máquina, veía que los procesos relacionados con la actualización aún se estaban ejecutando, entre los cuales whiptailme pedían entradas (qué administrador de pantalla elegir) y, lo que es más relevante, una propiedad de root SCREEN. Pude hacer sudo su -y screen -radjuntar a la sesión y, he aquí, tengo el diálogo de cola de látigo frente a mí capaz de tomar entrada. Pude reanudar la actualización sin problemas.

Nota: esta fue una actualización de Ubuntu 14.04 a 16.04.