Feeds:
Entradas
Comentarios

Archive for the ‘howtos’ Category

konsole-128x128

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… :D.

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 .

Read Full Post »

Ayer me encontré con un pendrive, del que sospechaba que tenía ciertos sectores defectuosos en el disco, dado que muchas veces que guardaba archivos en el mismo, al leerlos, estos estaban corruptos.

Buscando como testear el pendrive, me encontré con una aplicación que se llama badblocks, que como su nombre lo indica, se encarga de buscar bloques defectuosos en las particiones o en discos.

La forma de usar esta aplicación es muy simple, solo basta con ejecutar

sudo badblocks /dev/sdX

donde sdX es el nombre del dispositivo, en mi caso sdb.

Esto realizará el testeo y mostrará los errores que encuentre. En el caso de que la partición ó el disco (en este caso un pendrive) no contenga errores, no mostrará nada en la salida.

Badblocks tiene un montón de opciones (man badblocks para más info 😉 ), una de las interesantes es -o, que nos permite guardar la lista de bloques malos en un archivo, el que luego puede ser pasado como parámetro al programa mkfs para decirle que, a la hora de crear el filesystem, no utilice dichos bloques 😉 .

En definitiva, los pasos para detectar y no utilizar bloques malos en un dispositivos, son los siguientes (Ojo!!!, esto borrará el contenido completo del dispositivo!!!):

# busca bloques malos y los lista en un archivo
sudo badblocks -o bloquesmalos /dev/sdX
# Crea el filesystem, ignorando los bloques malos.
sudo mkfs.vfat -l bloquesmalos /dev/sdX

(Donde sdX es el dispositivo en cuestión)

y listo 😀 .

Read Full Post »