screen y gestión de procesos en Linux


Todos los admins hemos tenido la necesidad de dejar un proceso corriendo en background que esta haciendo una tarea que va a tardar mucho. La primera solución es:

./proceso.sh &

De manera que el programa se queda corriendo en background. Los inconvenientes de esta forma de hacerlo es que la salida de errores del proceso saldrá por la consola que estemos usando, y que si se nos desconecta la sesión el proceso simplemente muere.

Si jugamos un poco con los comandos “jobs”, “fg” y “bg” veremos que si dejamos un par de procesos en background y ejecutamos “jobs”, devuelve sale un mensaje del estilo:


[1] 3844
[2] 3981

Con esto sabemos que tenemos dos procesos en background. Podemos pasar uno de ellos al foreground con el comando fg:

fg %1

Ojo! 1 sería el número de trabajo, no el pid! Luego, para poder devolverlo al background usaríamos:


[Ctrl-Z]
bg %1

Nota: Control Z es la señal STOP, así que se podría hacer tambien con un kill -SIGSTOP PID

Con estos comandos, ya podemos mandar y devolver procesos al background y gestionar con cierta soltura los procesos.

Bien, y ¿qué pasa si se desconecta nuestra sesión? Esto nos lo soluciona nohup. Normalmente, si un usuario se conectar por SSH o cualquier otro medio y lanza procesos en background al desconectarse todos los procesos que hubiera lanzado se matan automáticamente. Así que para evitar esto, la solución pasaría por algo como:

$ nohup ./proceso.sh &

Nota: también hay que poner el & porque nohup no hace que el proceso se lance al background. Si olvidamos ponerle el & al final, siempre podemos mandarle un ^Z y bg %1. Por defecto la salida estándar del proceso (STDOUT) se escribirá en el archivo “nohup.out” en el directorio desde el que se lanza nohup. Así que haciendo un “tail -f nohup.out” podremos ver las últimas lineas que haya escrito el proceso por STDOUT. Pero, si después queremos ver o interactuar con este proceso usando el mismo usuario u otro, lo tenemos un poco crudo (igual se puede, pero yo no he encontrado la manera).

Bien, aquí es donde entra en juego screen. Screen sirve para multiplexar terminales. Pero veamos screen en acción:

Creamos una sesión:

$ screen

o

$ screen -S monitorizando

En el primer caso, se crea una sesión con un nombre formado por el PID, TTY y hostname desde donde se ha creado. En el segundo, se está dando el nombre “monitorizando” a la sesión creada.

Vale, tenemos una sesión de screen creada. ¿Y ahora qué?

Para pasar comandos a la sesión de screen, siempre hay que pulsar Control+A (^A). Si queremos ver la lista completa de opciones y cosas que se pueden hacer sobre una sesión de screen sería:

^A ?

La lista de opciones es apabullante. Así que seguimos con las opciones más básicas y cada uno que explore lo que le apetezca.

Las operaciones más básicas que se pueden hacer con una sesión abierta de screen con attach y detach. Al crear una sesión de screen, ejecutamos unos procesos que tardarán días o estarán hasta que los matemos … pero una vez lanzados queremos volver a nuestro bash de toda la vida hasta que tengamos curiosidad por saber de aquél proceso que dejamos … bien, pues tenemos que detachar la sesión con:

^A d

Supongamos que dentro de esa sesión estamos recompilando un kernel en nuestro pequeño servidor casero. Vamos al trabajo o a clase y … ¿como andará mi compilación?. Pues nos logamos por SSH por ejemplo, y … ¿veamos que sesiones de screen hay abiertas?

$ screen -ls
There are screens on:
450.monitorizando1 (Detached)
454.monitorizando1 (Detached)
458.monitorizando2 (Detached)
3 Sockets in /tmp/uscreens/S-melon.

Mmm, vale veo que hay tres sesiones. Si sólo hubiera una, bastaría con “screen -r”, pero como hay tres para attachar un sesión listada, sería algo como

screen -r [pid] o [nombre]

Vemos que el kernel sigue con su compilación, y detachamos otra vez con ^A d. Si cuando estabamos en casa, hubieramos olvidado detachar la sesión, podemos attacharla “por la fuerza” con:

screen -x [pid] o [nombre]

Si nos atachamos una sesión “por la fuerza”, vemos virtualmente lo mismo desde casa y desde el curro. Puede ser una manera curiosa de chatear con otros usuarios. Además de la sesión (lo que vemos con screen -ls) hay conceptos como windows y region, y dentro de una sesión podemos lanzar más sesiones. También esta la posibilidad de dar permisos a otro usuario para que vea la sesión o interactue con ella:

^A :multiuser on
^A :aclchg invitado +r "#"

Así daríamos permisos de lectura al usuario “invitado” sobre todas las ventanas de nuestra sesión.

Resumiendo

Permite compartir sesiones entre varios administradores. En ese caso, puede uno seguir exactamente donde el otro se quedó hasta que se acabó su turno, ahorrándose el volver a empezar o cargar listas de variables de entorno, pero quizá sea demasiado complejo. Da la sensación de ser el equivalente de un gestor de ventanas en X, pero para consola. Resuelve el problema de la movilidad del usuario (con screen podemos detachar desde un sitio, y al llegar a otro conectarnos y atachar), se pueden crear ventanas como el equivalente a multiples ttys, y se pueden compartir las sesiones entre usuarios.

Espero que le sea útil a quien no lo conociera antes!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: