Feeds:
Entradas
Comentarios

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 :P ). 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

GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash elevator=deadline”

Después de editar el archivo, lo guardamos y ejecutamos como root:

root@mambo-tango:~# update-grub

, para que vuelva a releer la configuración… luego reiniciamos y listo.

Para los que quieran saber mas de este parámetro y que cambia, pueden leer este link http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/

Hoy buscando info sobre V-Server (un virtualizador host-based), me encontré con esta utilidad que no conocía, y que me parece muy buena para cuando tenemos problemas de performance (sobre todo cuando consolidamos servicios diferentes en un mismo servidor) debido al uso exhaustivo que realiza un determinado proceso de lo que es red y disco (lo más lento dentro de un server, y por ende el centro al que apuntar cuando tenemos este tipo de problemas).

IOnice permite setear por proceso, la prioridad de acceso al I/O del sistema, utilizando para esto 3 tipos de comportamientos:

  1. Idle: el proceso solo accede cuando a pasado un determinado tiempo de gracia sin que ningún proceso acceda al recurso (la prioridad mas baja, util para procesos batch o que no son prioritarios).
  2. Best effort (mejor esfuerzo): Esta es la clase por defecto, y dentro de la misma se setea una prioridad de 0-7, siendo la prioridad 0 la máxima.
  3. Real time (en tiempo real): El proceso accede directamente al recurso sin esperar a que termine un proceso anterior (lo interrumpe). Es la prioridad máxima que se puede conseguir.

Algunos ejemplos de uso serían:

#~$ ionice -c3 -p8912

(Establece que el proceso “8912″ tenga acceso en tiempo real al disco.)

#~$ ionice -c2 -n0 3221

(Establece la maxima prioridad, para el proceso 3321, en la cola de procesos que estan configurados como best effort (clase 2) )

#~$ ionice -c2 -n2 bash

(Ejecuta bash con best effort, prioridad 2). Como siempre, mas info en man ionice ;).

Los tuneles ssh sirven para redirigir conexiones a nivel de tcp entre distintos equipos, utilizando hosts intermediarios. La cosa vendría a ser mas o menos así, supongamos que tenemos un equipo A que esta conectado a un equipo B, y un equipo C que esta conectado a B. Queremos que el puerto N de A se conecte al puerto M del equipo C, pasando por B para esto.

Esto en capa 3 (IP) es lo habitual si B es nuestro gateway, pero a nivel de capa4 (TCP) no lo es. Esto puede ser medio extraño para algunos, ya que nos podemos plantear que A se conecte directamente a C, pero que pasa si entre A y B está el firewall de la empresa en la que trabajamos, y por medio del cual solo pasa contenido web (puerto 80 y 443), por ej.?, y nosotros queremos tener acceso ssh a C (puerto22) ?.

En este caso lo que podemos hacer, si B es de nuestra pertenencia (el equipo de casa por ejemplo), es levantar el ssh en el puerto 80 del equipo B, armar un tunel entre nuestro equipo A (el del trabajo) y B, y hacer que B se conecte al puerto 22 de C, con lo que todas las conexiones ssh que iniciemos contra el puerto 80 de B, serán redirigidas al puerto 22 de C. Esto se traduce en el siguiente comando:

ssh -p 80 -L2222:IP-Host-C:22 usuario@Host_b

por ejemplo  ssh -p 80 -L 2222:201.122.101.2:22 mboscovich@miequipob.com

la opción -L 2222:201.122.101.2:22 quiere decir que localmente se vincula el puerto 2222 (del equipo A) con el puerto 22 del equipo 201.122.101.2 (equipo C), la opción -P 80 es para se conecte al 80 el ssh, en vez del 22 (por defecto).

Luego, si hacemos ssh -p 2222 localhost, estaremos accediendo al equipo C  :D.

Luego de actualizar el kubuntu de casa de la versión 9.10 a la 10.4 beta1 (algo que por cierto no produjo casi problemas :D) , me encontré con que el thunderbird no levantaba. Así que me fuí a la consola y lo ejecute desde allí para ver que pasaba… linda sorpresa, tiraba un segmetation fault :( . 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 página del proyecto de dicho plugin. Leyendo un poco encontré que hay una nueva versión que soluciona mi problema (aunque aún esta en desarrollo). Así que baje esta nueva versión y listo, el thunder sigue fiel en mi bandeja de sistema :D.

Debo aclarar que si bien esta es una versión de desarrollo, es totalmente funcional, y esta en este estado desde agosto de 2009, lo que probablemente indique que el desarrollador no la publico todavía por fiaca :P.

Kubuntu 9.10 no apaga :(

Mi kubuntu 9.10 karmic koala, hoy me presento un nuevo problema, y es que desde el menu de kde no podía apagar, reiniciar ni cerrar la sesión. Al parecer, el problema estaba en el demonio de kde “knotify”, que por lo visto no podía reproducir el sonido de fin de sesión y se colgaba ahí a la espera de que termine dicho proceso. Después de buscar un poco me encontré con que la solución era más sencilla de lo que parecía. Simplemente hay que borrar el archivo knotifyrc que esta dentro de la carpeta .kde de nuestro usuario (No se preocupen, este archivo se vuelve a generar en el próximo inicio de sesión). El comando sería el siguiente:

rm ~/.kde/share/config/knotifyrc

y listo, a partir de ahora podemos volver a apagar el equipo desde el menu K.

Nota: dicho comando debe ser ejecutado con el usuario que iniciamos sesión, no como root.

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

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

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 .

iourbanterrorlogo1Al 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 :(  . Así que como siempre me puse a googlear un poco, y después de renegar un rato logré que funcionara.

Los pasos que seguí fueron los siguientes:

  • Instale la librería libsdl1.2debian-pulseaudio (en mi sistema estaba instalada la libsdl1.2debian-alsa, pero alsa no es más el sistema de sonido en ubuntu 9.10, así que la reemplace por la versión para pulseaudio).
  • Modifiqué el archivo /etc/default/pulseaudio, y puse PULSEAUDIO_SYSTEM_START=1
  • Agregué a mi usuario al grupo pulse-access (sudo adduser ${USER} pulse-access) (Si hay más de un usuario en el sistema, debemos agregarlo también a este grupo, sino no tendra sonido :P )

Listo, después de eso reinicie y todo funciona de maravillas :D (el reinicio es obligatorio, porque a partir del cambio en el archivo /etc/default/pulseaudio, pulseaudio corre como demonio del sistema, en vez de correr para cada sessión por medio de X11).

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.