De seguro muchas veces les ha pasado que tienen que loguearse remotamente a un servidor, y ejecutar muchos comandos en simultáneo, y monitorear sus salidas. Esta tarea implica por cada comando establecer una nueva conexión ssh, para de este modo tener una terminal para dicho comando, algo bastante molesto. Por suerte screen puede ayudarnos a hacer simple esta tarea, estableciendo una sola conexión y multiplexando nuestra terminal para poder ejecutar varios comandos en simultáneo.
Veamos un ejemplo: supongamos que queremos monitorear nuestro sistema con tres comandos en simultáneo, por ejemplo el comando top, el comando tail -f /var/log/syslog y el comando watch netstat -t4u4n. Bien, para esto nos conectamos a nuestro equipo remotamente,y ejecutamos
mboscovich@fuser3:~$ screen
( con esto empezamos a utilizar la bestia 
)
bien, en esa misma consola ejecutamos el primer comando (top)
mboscovich@fuser3:~$ top
top - 17:11:47 up 1:00, 3 users, load average: 0.05, 0.05, 0.03
Tasks: 155 total, 1 running, 154 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.0%us, 1.8%sy, 0.0%ni, 93.0%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 2057784k total, 2039872k used, 17912k free, 58876k buffers
Swap: 4000176k total, 6404k used, 3993772k free, 994096k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2069 mboscovi 20 0 379m 41m 17m S 3 2.1 0:09.64 konsole
860 root 20 0 686m 93m 14m S 2 4.7 2:45.82 Xorg
......
bien, ahora tenemos corriendo en nuestra primer consola virtual, el proceso top. Si ahora hacemos ctrl+A+c (la c es de create), crearemos una nueva consola virtual colgada de la misma sesión . Ejecutamos eso y luego ejecutamos el segundo comando (tail -f /var/log/syslog)
mboscovich@fuser3:~$ tail -f /var/log/syslog
Oct 5 17:12:59 fuser3 dhclient: bound to 192.168.1.14 -- renewal in 28 seconds.
Oct 5 17:13:27 fuser3 dhclient: DHCPREQUEST of 192.168.1.14 on eth0 to 192.168.1.1 port 67
Oct 5 17:13:27 fuser3 dhclient: DHCPACK of 192.168.1.14 from
......
bien, ahora tenemos dos consolas colgadas de la misma sesión, corriendo en simultáneo 
. Si queremos crear una nueva consola (la tercera), volvemos a ejecutar ctrl+a+c , así que hacemos eso y ejecutamos el tercer comando ( watch netstat -tunp)
mboscovich@fuser3:~$ netstat -tupn
Every 2,0s: netstat -tupn Mon Oct 5 17:19:36 2009
(No todos los procesos pueden ser identificados, no hay informacin de propiedad del proceso
no se mostrarn, necesita ser superusuario para verlos todos.)
Conexiones activas de Internet (servidores w/o)
Protocolo Recv-Q Send-Q Direccin Local Direccin Externa Estado PID/Program name
tcp 0 0 192.168.1.14:45049 76.13.15.40:5050 ESTABLECIDO 3839/kopete
tcp 0 0 192.168.1.14:52069 64.233.169.125:5223 ESTABLECIDO 3839/kopete
tcp 0 0 192.168.1.14:35523 65.54.50.160:1863 ESTABLECIDO 3839/kopete
.....
Listo, ya tenemos los tres procesos ejecutándose en simultáneo, como queríamos. Ahora para navegar entre las distintas consolas creadas, y ver la salidas que se muestran en las mismas, simplemente hacemos ctrl+a+n (la n es de next), o ctrl+a+p (previous), no es lindo ?? .
Bien, pero ahí no termina la mágia de screen…. supongamos que por alguna razón tenemos que cerrar nuestra conexión al servidor remoto, pero no queremos que estos procesos dejen de ejecutarse en el servidor. Bien en este caso lo que hacemos es simplemente desconectarnos del proceso screen que controla las consolas creadas, lo que en screen se conoce como detach. Para realizar esto simplemente ejecutamos ctrl+a+d, y después si, cerramos la sessión al servidor ( nos desconectamos de el digamos). Bien, ahora la magia, si volvemos a loguearnos en el servidor, y hacemos un screen -ls, apareceran los procesos screen que se continuan ejecutando en el servidor, por ejemplo
mboscovich@fuser3:~$ screen -ls
There is a screen on:
4450.pts-4.fuser3 (05/10/09 17:09:24) (Detached)
1 Socket in /var/run/screen/S-mboscovich
esto nos muestra que tenemos un proceso screen corriendo (el 4450.pts-4.fuser3) desde las 17:09 del día 05/10/09, y que este esta detached. Bien para volver a conectarnos a dicho proceso screen, hacemos
mboscovich@fuser3:~$ screen -r 4450.pts-4.fuser3
y chan! tenemos nuestras tres consolas virtuales, que siguen ejecutándose en el servidor, y podemos seguir monitoreando el mismo sin tener que volver a lanzar dichos procesos .
Imaginen la potencia de esto, si tiene que lagar un proceso en el servidor que va a demorar varias horas, y ustedes no quieren dejar su pc cliente prendida mientras se ejecuta el mismo, sino que ejecutan este por medio de screen, detachan la consola que muestra la salida del mismo, se desconectan del servidor, para luego, al rato, volver a conectarse al mismo, y al proceso screen que tiene la consola con el proceso que se continua ejecutando, es una excelente solución para estos casos no… .
Por último, si queremos cerrar los procesos que se estan ejecutando en dichas consolas virtuales, simplemente hacemos exit en cada una y listo.
Siempre podemos chequear que no quedo ninguna consola abierta, con el comando screen -ls
Bueno, espero que a alguien le sirva, en mi caso fue de mucha utilidad, sobre todo porque había usado screen hace ya unos años, pero me había olvidado de su magia, hasta que hoy tuve que volver a sacarle el jugo .
Hoy me encontré con que mi Ubuntu 11.04 (leí por ahí que también sabe pasar con otras distros) se ponía extremadamente lento al copiar un archivo grande a un pendrive. Miro la carga y estaba en 8! lo pario… algo raro había… buscando encontré que todas las operaciones que tenían acceso a discos externos (como el pendrive) producían este problema (por ejemplo si formateaba el pendrive). Buscando en internet encontré que es un viejo bug [1] que lo raro que tiene es que sucede raras veces (en mi caso siempre 
). La solución era cambiar el scheduler de la cola de acceso a estos dispositivos de bloque, pasándole por parámetro al kernel la siguiente opción “elevator=deadline”. Esto en el caso de tener grub2, se hace editando el archivo /etc/default/grub, y seteando la variable GRUB_CMDLINE_LINUX_DEFAULT a lo siguiente
. Después de un thunderbird –help, encontré como seguir investigando que pasaba, y ejecute el mismo con las opciones de modo seguro y debug (thunderbird -safe-mode -jsconsole). Siguiendo con la investigación, llegue a que era un addons el que estaba dando el problema, así que hice lo más rápido para continuar con el debug, y fue ir a la parte de addons (tools–>add-ons) y desactivar el único que tenía, firetray (firetray es un add-ons que permite iniciar y mantener minimizado en la bandeja del sistema el thunderbird, e indicar la cantidad de mails no leídos). Luego de deshabilitar este add-ons, el thunderbird volvio a levantar sin problemas. Bien, hasta acá todo de lujo, pero de inmediato recordé que ese add-ons era fundamental en mi vida, porque es algo totalmente molesto para mí tener el thunderbird minimizado en la barra de tareas (cada uno tiene sus propias mañas, esta es una de las mías). Así que luego de darme cuenta de este hecho, me dirigí a la 
Al actualizar mi kubuntu desde la versión jaunty 9.04 a la versión de desarrollo karmic koala 9.10, me encontré con que una de mis grandes debilidades, el juego UrbanTerror (www.urbanterror.net ) funcionaba pero sin sonido 
