Cómo usar screen para mantener una aplicación corriendo tras cerrar SSH
Aprende a usar screen en Linux para mantener scripts y aplicaciones corriendo después de desconectarte por SSH, con sesiones persistentes y reanexables.
Cada vez que abres una conexión SSH y ejecutas un script largo — una compilación, un entrenamiento de modelo, un deploy, cualquier cosa que tarde más que unos minutos — quedas rehén de la conexión. Caídas de red, cerrar la tapa del portátil, expiración del timeout del router: cualquiera de estos eventos derriba el SSH, y cuando eso pasa, el proceso que estaba corriendo en primer plano recibe un SIGHUP y muere junto.
screen resuelve este problema desacoplando el proceso del terminal interactivo. Creas una sesión, ejecutas lo que necesitas dentro de ella, te desanexas, cierras el SSH y te vas. El proceso sigue corriendo indefinidamente en el servidor. Cuando vuelvas — minutos o días después — reanexas la sesión y estás exactamente donde lo dejaste, con la salida completa preservada.
Este tutorial muestra la instalación, los comandos esenciales y los atajos que vas a usar el 90% del tiempo. Tiempo estimado de ejecución: 10 a 15 minutos, incluyendo práctica.
Requisitos previos
Necesitas una máquina Linux con acceso SSH funcionando (cualquier distribución moderna sirve: Ubuntu 22.04+, Debian 12+, Rocky 9, Alma 9). Acceso sudo es necesario solo para instalar el paquete — el uso de screen en sí corre como usuario común.
screen ~600 KB libc, libutempter 4.x o superior Instalando screen
En la mayoría de servidores de producción, screen ya viene instalado por defecto. Comprueba primero antes de instalar.
Verifica si screen ya está disponible:
which screen && screen --versionSi el comando retorna la ruta (/usr/bin/screen) y la versión, salta a la siguiente sección. Si retorna vacío o “command not found”, continúa con la instalación.
Instala en sistemas basados en Debian/Ubuntu:
sudo apt update
sudo apt install -y screenEn distribuciones de la familia Red Hat (Rocky Linux, AlmaLinux, CentOS Stream):
sudo dnf install -y screenConfirma la instalación:
screen --versionLa salida esperada es algo como Screen version 4.09.00 (GNU) — cualquier versión 4.x sirve. Las versiones 3.x todavía funcionan pero son raras hoy en día.
Creando tu primera sesión
La creación de sesiones nombradas es el patrón recomendado — facilita identificar y reanexar después.
Crea una sesión nombrada. Usa un nombre descriptivo de lo que va a correr dentro:
screen -S deployVas a notar una pantalla “limpia” — parece un terminal normal, pero ahora estás dentro de una sesión screen. Ejecuta cualquier comando largo aquí. Para ejemplificar:
ping -c 1000 8.8.8.8Desanexa la sesión sin matar el proceso. Esta es la operación más importante de screen — el atajo Ctrl+a seguido de d:
Presiona Ctrl+a (mantén Ctrl, pulsa a, suelta los dos), después pulsa d solo.
Vuelves al shell original. El mensaje [detached from 12345.deploy] confirma que la sesión sigue corriendo en background. Puedes incluso cerrar el SSH ahora — el ping sigue contando ahí dentro.
Casi todos los comandos de screen empiezan con el prefijo Ctrl+a. Se le llama “comando de control” y funciona como un modo: pulsas Ctrl+a para entrar al modo de comando, y la siguiente tecla es la acción. Ctrl+a d = detach. Ctrl+a c = create new window. Ctrl+a ? = ayuda completa.
Listando y reanexando sesiones
Después de desanexar, necesitas saber qué sesiones existen antes de volver a alguna.
Lista todas tus sesiones activas:
screen -lsLa salida muestra cada sesión con PID, nombre y estado:
There are screens on:
12345.deploy (Detached)
12890.build (Detached)
2 Sockets in /run/screen/S-root.El número antes del punto es el PID del daemon, lo que viene después es el nombre que le diste. Estados comunes: (Detached) = suelta esperando reanexar, (Attached) = alguien está conectado ahora, (Dead) = muerta pero con socket huérfano (límpialo con screen -wipe).
Reanexa la sesión. Usa el nombre o el PID:
screen -r deployVas a caer exactamente donde lo dejaste — toda la salida del proceso, posición del cursor, comandos en el historial. Todo preservado. Si hay solo una sesión desanexada, screen -r sin argumentos lo resuelve.
Forzar reanexación. Si te olvidas de desanexar y abres una nueva conexión SSH intentando reanexar, vas a obtener el error There is no screen to be resumed matching .... Resuélvelo forzando:
screen -dr deployLa flag -d fuerza el detach de la sesión actual (incluso si otro terminal está anexado) antes de reanexar para el tuyo. Usa -D -RR para “force detach, attach, create if not exists” — útil en scripts.
Comandos esenciales durante la sesión
Una vez dentro de la sesión, algunos atajos extra van a facilitar el día a día.
| Atajo | Acción |
|---|---|
Ctrl+a d | Desanexa la sesión (la deja corriendo en background) |
Ctrl+a c | Crea una nueva “ventana” dentro de la sesión |
Ctrl+a n | Siguiente ventana |
Ctrl+a p | Ventana anterior |
Ctrl+a " | Lista todas las ventanas para seleccionar |
Ctrl+a A | Renombra la ventana actual |
Ctrl+a [ | Entra en modo copia/scroll (usa flechas, q para salir) |
Ctrl+a k | Mata la ventana actual (pide confirmación) |
Ctrl+a ? | Lista todos los atajos disponibles |
El concepto de “ventanas dentro de la sesión” es poderoso: dentro de una única sesión deploy puedes tener una ventana corriendo el build, otra con htop monitorizando, otra con tail -f en logs. Todo aislado, todo persistente.
Por defecto, screen guarda solo 100 líneas de historial en el buffer. Si tu aplicación escupe mucho log, considera redirigir la salida a un archivo vía comando 2>&1 | tee /tmp/salida.log — o aumenta el buffer permanentemente creando ~/.screenrc con defscrollback 10000.
Cerrando sesiones correctamente
Cuando la aplicación termine, necesitas cerrar la sesión para que no quede como zombi en screen -ls.
Reanexa la sesión y termina el proceso normalmente (Ctrl+C o comando de salida de la app). Después, cierra el shell de la sesión:
exitEsto cierra el shell que screen creó. La sesión se destruye y desaparece de screen -ls. Es la forma limpia.
Matar una sesión a la fuerza sin reanexar (úsalo cuando esté trabada):
screen -X -S deploy quitLa flag -X envía un comando a una sesión específica, y quit la termina. Útil cuando el proceso dentro está trabado y no quieres reanexar para depurar.
Limpia sesiones muertas que aún aparecen en screen -ls:
screen -wipeEste comando elimina todos los sockets huérfanos de sesiones cuyo proceso ya murió. Corre rápido y es seguro — no toca sesiones activas o desanexadas válidas.
Verificación
Para confirmar que todo funcionó, haz la prueba del mundo real: desconéctate del SSH con una aplicación corriendo y reconéctate después.
Crea una sesión de prueba con un contador simple:
screen -S prueba
for i in $(seq 1 600); do echo "Tick $i — $(date +%T)"; sleep 1; doneDesanexa con Ctrl+a d y cierra la conexión SSH completamente (exit o cierra el terminal).
Reconéctate al servidor vía SSH y reanexa:
screen -r pruebaEl contador debe estar mucho más allá de donde te desanexaste — prueba de que siguió corriendo sin ti. Termina con Ctrl+C y exit.
Resolución de problemas
”Cannot open your terminal ‘/dev/pts/0’”
Aparece cuando cambias de usuario (sudo su - otro) y tratas de usar screen. El nuevo usuario no tiene permiso en el pty original. Resuélvelo ejecutando script /dev/null antes de screen — eso asigna un pty nuevo para el usuario actual.
Sesión aparece “Attached” pero no estás en ninguna
Conexión SSH anterior se cayó sin desanexar limpio. screen cree que aún tiene cliente. Resuélvelo con screen -d -r nombre — la flag -d fuerza detach antes de anexar para ti.
Colores y formato rotos dentro de screen
La variable $TERM dentro de screen se vuelve screen o screen.xterm-256color, que algunas aplicaciones no reconocen. Añade export TERM=xterm-256color en tu .bashrc o ejecútalo antes de la aplicación.
Las sesiones screen corriendo como root exponen un shell privilegiado persistente que sobrevive a desconexiones. Si la sesión es secuestrada (compartir vía -x, o acceso indebido al usuario root), el atacante hereda root directo. Prefiere siempre ejecutar como usuario común y elevar con sudo solo cuando sea necesario dentro de la sesión.
Próximos pasos
Ahora que dominas lo básico, algunos caminos para profundizar:
- Crea un archivo
~/.screenrccon configuraciones persistentes (status bar personalizada, atajos remapeados, scrollback grande). Ejemplos completos enman screen. - Aprende
tmuxcomo alternativa moderna — sintaxis similar, pero con splits gráficos nativos y configuración por archivo mucho más limpia. - Para procesos que necesitan sobrevivir a reboots, monta una service unit de systemd con
Restart=always. screen y tmux no cubren ese caso. - Estudia
journalctl --userpara centralizar logs de aplicaciones largas corriendo en background.
Si estás ejecutando workloads de larga duración — builds de horas, entrenamientos de modelo, procesamiento de datos — una VPS Hostini con SSD NVMe y CPU dedicada reduce el tiempo de ejecución y aporta previsibilidad, lo que combina bien con el uso intensivo de screen para mantener todo organizado en sesiones.
Preguntas frecuentes
¿Cuál es la diferencia entre screen, tmux y nohup?
nohup solo desacopla el proceso del terminal y redirige la salida a un archivo — no puedes reanexar ni interactuar después. screen y tmux mantienen el proceso en una sesión completa que puedes desanexar, reanexar y manipular. tmux es más moderno (splits gráficos, configuración por archivo), mientras que screen es más simple y viene instalado por defecto en casi cualquier distribución.
Si el servidor se reinicia, ¿la sesión screen sobrevive?
No. screen mantiene la sesión viva solo mientras el proceso padre (el daemon) está corriendo, y eso no sobrevive a un reboot. Para resistir reinicios, usa systemd con una service unit, o supervisord. screen es para tareas largas dentro de un mismo uptime — compilaciones, entrenamientos, scripts de mantenimiento.
¿Por qué mi sesión screen aparece como (Dead) en screen -ls?
Significa que el proceso dentro de la sesión terminó pero el socket quedó huérfano. Límpialo con `screen -wipe`, que elimina todas las sesiones muertas. Si quieres capturar la salida antes de matarla, prueba `screen -r nombre` igualmente — en algunos casos aún puedes leer las últimas líneas del buffer.
¿Puedo compartir una sesión screen con otro usuario?
Sí, usando `screen -x nombre_de_la_sesion` los dos pueden ver y escribir simultáneamente. Útil para pair-debugging remoto. Para compartir con otro usuario Linux del mismo servidor, el owner necesita ejecutar `screen -X multiuser on` y `screen -X acladd otro_user` dentro de la sesión.
¿Cómo ver la salida completa de la aplicación que corre dentro de screen?
Reanexa la sesión con `screen -r nombre` y desplázate hacia arriba usando Ctrl+a, seguido de Esc. Ahí usas las flechas o Page Up/Down para navegar por el buffer (cerca de 100 líneas por defecto). Para aumentar el buffer, añade `defscrollback 10000` en el archivo ~/.screenrc.
screen está consumiendo CPU sin nada dentro — ¿es normal?
No. Las sesiones screen en idle consumen esencialmente cero CPU. Si ves uso alto, probablemente el proceso dentro de la sesión es el que consume (algún loop infinito, spam de log, etc). Reanexa con `screen -r` e investiga. Si hay muchas sesiones muertas acumuladas, ejecuta `screen -wipe`.