Imagina que inicias una sesión SSH en un servidor Linux de producción con Putty, te pones a compilar una aplicación crítica o a actualizar el sistema y de repente pierdes la conectividad con el servidor. Por supuesto la sesión SSH se cierra de forma abrupta… ¿habrá finalizado la compilación o se ha quedado a medias? ¿el sistema habrá quedado inútil al cortarse de golpe la actualización? Para evitar situaciones como estas es buena idea utilizar un multiplexador de terminal. Veremos cómo hacer uso de uno de los mas sencillos: screen.
Para instalarlo, según la distro con la que estemos trabajando:
# RHEL/CentOS/Fedora yum update yum install screen # Debian/Ubuntu apt-get update apt-get upgrade apt-get install screen # Arch Linux sudo pacman -Sy sudo pacman -S screen
Vamos a ver cómo funciona con un caso práctico muy sencillo:
- Conecta con tu sistema Linux con tu cliente SSH favorito, por ejemplo Putty.
- Una vez dentro inicia una sesión de screen, ejecutando:
screen
Para la prueba que queremos hacer, a continuación haz un
tail -f
de un log cualquiera en/var/log
. Por ejemplo:tail -f /var/log/dmesg
- No interrumpas el
tail
anterior. Cierra de forma abrupta la conexión por SSH al sistema Linux. Directamente cierra la consola de Putty que tienes abierta. - Repite los pasos 1 y 2. Una vez estés dentro puedes hacer un listado de las sesiones de screen iniciadas. En nuestro caso sólo veremos una:
screen -ls
- Vamos a hacer un reattach a esa sesión de screen iniciada. Podemos hacerlo a partir de su PID con
screen -r [PID]
, en nuestro caso:screen -r 3408
- Observamos que la sesión SSH anteriormente iniciada se encuentra realizando las tareas que le habíamos asignado antes de “perder” la conexión SSH. En nuestro caso sigue con
tail -f /var/log/dmesg
Ahora imagina que estás actualizando Debian Wheezy a Jessie. Nada debería salir mal, pero por Ley de Murphy ocurre un desastre y en medio de la actualización pierdes la conexión SSH con tu servidor. Si hubiéramos tomado la precaución de utilizar screen desde el principio tendríamos cubiertas las espaldas:
- Por una parte, el proceso de actualización continuaría ejecutándose en el sistema a pesar de haber sido expulsados de nuestra sesión SSH.
- Posteriormente podríamos hacer un reattach (volver a unirnos) abriendo una nueva conexión SSH con Putty y recuperando la sesión de screen que dejamos ejecutando anteriormente.
Además, screen no sólo nos ahorra disgustos en caso de un problema de conectividad durante un proceso crítico que hayamos lanzado en el sistema remoto, sino que además abre la puerta a la paralelización de tareas con diversas sesiones de screen sin necesidad de abrir más sesiones SSH.
Hay más multiplexadores de terminal como tmux, dtach o dvtm, pero como he dicho screen es de los más fáciles de implementar.