Archivo de la categoría: tutoriales

DBus en Vala

Actualizado Estoy trabajando en un nuevo proyecto, escrito íntegramente en Vala, y la verdad es que cuantas más cosas aprendo sobre él, más me gusta.

Lo último que descubrí fue como trabajar con DBus en Vala, y resulta que es extremadamente sencillo y elegante, aunque tuve que investigar bastante hasta encontrar como hacer algunas cosas, pues los ejemplos que vienen en la página tratan de como trabajar con un servidor hecho por uno mismo, cuando yo necesitaba acceder a un servicio del sistema.

Así pues, y sin más dilación, veamos como se puede usar DBus para obtener una lista de los discos duros conectados por USB al ordenador, y como formatearlos.

Lo primero que vemos es que toda esa información la gestiona el demonio UDisk, el cual exporta una serie de funciones y objetos a través de DBus para que cualquier programa pueda acceder a ellos. Si echamos un vistazo a la documentación de la API, vemos que se exporta el método EnumerateDevices, el cual nos devuelve un array de objetos.

¿Y como accedemos a este método del objeto UDisk desde Vala? Pues con este código:

[DBus (name = "org.freedesktop.UDisks")]
interface UDisk_if : GLib.Object {
    public abstract ObjectPath[] EnumerateDevices() throws IOError;
}

UDisk_if udisk = Bus.get_proxy_sync<UDisk_if> (BusType.SYSTEM, "org.freedesktop.UDisks","/org/freedesktop/UDisks");
var retval = udisk.EnumerateDevices();

Aquí vemos que primero definimos una interfaz con todos los métodos a los que vamos a querer acceder (en este caso sólo uno), sacando de la documentación los parámetros y demás, y le añadimos antes una cabecera con el nombre del objeto. Luego, creamos un proxy síncrono, conectándonos a través del bus del sistema (BusType.SYSTEM), al servidor UDisk (org.freedesktop.UDisks) y pedimos acceso al objeto deseado (/org/freedesktop/UDisks). Finalmente, llamamos al método deseado, almacenando el resultado en una nueva variable.

Es importante recalcar que cualquier método que se defina puede emitir, siempre, una excepción de tipo IOError, por lo que siempre se debe añadir al final de la definición la coletilla throws IOError. De no hacerlo se producirá un error de compilación. También comentar que dado que esta función sólo devuelve un parámetro, la he escrito en formato resultado metodo(parametros); sin embargo, también es perfectamente válida la sintaxis void metodo (parametros,…, out resultado). Esta segunda forma es obligatoria cuando un método devuelve más de un resultado. Con esa sintaxis, la interfaz tendría esta forma:

[DBus (name = "org.freedesktop.UDisks")]
interface UDisk_if : GLib.Object {
    public abstract void EnumerateDevices(out ObjectPath[] path) throws IOError;
}

En retval tenemos ahora un array de objetos ObjectPath, cada uno de tipo Device, representando una unidad extraíble. ¿Y ahora, qué? Pues ahora vamos a imprimir el punto de montaje de cada uno de ellos. Si miramos la documentación del objeto Device, vemos que dicha información se almacena como una propiedad, así que definimos nuestra interfaz así:

[DBus (name = "org.freedesktop.UDisks.Device")]
interface Device_if : GLib.Object {
    public abstract string IdLabel { owned get; }
    public abstract string[] DeviceMountPaths { owned get; }

    public abstract void FilesystemUnmount(string[] options) throws IOError;
    public abstract void FilesystemCreate(string type, string[] options) throws IOError;
    public abstract void PartitionModify (string type, string label, string[] options) throws IOError;
    public abstract void FilesystemMount(string type, string[] options, out string mount_path) throws IOError;
}

Ponemos { owned get; } en lugar de {owned get; set; } porque los campos son de sólo lectura. También he añadido los cuatro métodos necesarios para poder formatear una partición, aunque en el ejemplo no los voy a utilizar.

Ahora llega el momento del código que accede a los datos, que es éste:

Device_if device2;
foreach (ObjectPath o in retval) {
    device2 = Bus.get_proxy_sync<Device_if> (BusType.SYSTEM, "org.freedesktop.UDisks",o);
    GLib.stdout.printf("Disco %s montado en:n",device2.IdLabel);
    foreach (string s in device2.DeviceMountPaths) {
        GLib.stdout.printf("    %sn",s);
    }
}

Así, primero recorremos la lista de objetos que obtuvimos con la anterior llamada (en retval), y creamos un proxy síncrono para cada uno de ellos, contra el servidor de UDisk (él es quien nos dio la lista de objetos, por lo que estos tienen que estar en él). Luego imprimimos la etiqueta simplemente leyendo la propiedad del objeto, y por último imprimimos todos los puntos de montaje (una misma partición puede estar montada en varios sitios a la vez).

Actualización: Uno de los problemas que tuve fue que la llamada a FilesystemCreate (que formatea la unidad especificada) tarda varios segundos en ejecutarse, lo que hacía que la GUI se quedase colgada. La primera solución que encontré fue ejecutarla en un thread aparte, y usar espera activa para detectar cuando terminó, pero era muy poco elegante. La solución definitiva consiste en realizar llamadas asíncronas a DBus, explicadas en el tutorial de Vala. La idea consiste en añadir la palabra reservada async en la definición de la función en la clase, con lo que la llamada a DBus será no-bloqueante, y definir un callback anónimo.

[DBus (name = "org.freedesktop.UDisks.Device")]
interface Device_if : GLib.Object {
  [...]
  public abstract async void FilesystemCreate(string type, string[] options) throws IOError;
  [...]
}

  // Llamamos a la función, añadiéndo como último parámetro
  // una función anónima que se ejecutará al terminar la
  // ejecución
  device2.FilesystemCreate.begin(format,options, (obj,res) => {
    try {
      // La llamada a .end recoge los valores devueltos (de haberlos)
      // y dispara cualquier excepción que se haya producido
      device2.FilesystemCreate.end(res);
      return;
    } catch (IOError e) {
      // Captura de excepciones (en este caso, fallo durante el formateo)
    }
  });

Una vez que hemos hecho la llamada, podemos volver al bucle principal de GTK o llamar a la función run() de un cuadro de diálogo, y éste seguirá funcionando en paralelo a la ejecución de nuestra llamada a DBus.

Instalando Eclipse Indigo en Ubuntu (u otro Linux)

Actualizado Ha salido la versión 3.7 (Indigo) del famoso IDE Eclipse. Por desgracia, todavía no está disponible como fichero .deb para Ubuntu, así que vamos a instalarlo «a mano».

Lo primero, desinstalar cualquier versión anterior de Eclipse.

A continuación, bajarse la versión correspondiente (32 o 64 bits) desde la página de descargas de Eclipse. Yo he instalado la edición Classic. Lo descomprimimos (como root, obviamente) en /opt/eclipse.

Instalamos la máquina virtual de Java, si es que todavía no la tenemos: sudo apt-get install openjdk-6-jre

Creamos un fichero eclipse.desktop en /usr/share/applications o en ~/.local/share/applications con el siguiente contenido:

[Desktop Entry]
X-MultipleArgs=false
Type=Application
Name=Eclipse
GenericName=Eclipse IDE
TryExec=/opt/eclipse/eclipse
Exec=/opt/eclipse/eclipse
Categories=Development;
Icon=/opt/eclipse/icon.xpm

¡Y listo! Ya tenemos Eclipse Indigo en nuestro sistema y en nuestro menú de aplicaciones.

Instalando Windows desde un pen

Por una serie de circunstancias, este fin de semana necesité instalar un Windows XP en mi portátil, y una tarea tan aparentemente sencilla se convirtió en una tortura. ¿Por qué?

Lo que todo el mundo pensará es que basta con meter el CD en la unidad, reiniciar, y listo. Pero mi portátil es un EEE PC sin lector de CDs. Así que lo siguiente que se piensa es en utilizar un lector de CDs por USB… pero no tenía ninguno a mano, y no me apetecía comprar uno sólo para una vez.

Una opción era utilizar WinToFlash, una utilidad que permite meter el instalador en un pendrive; por desgracia sólo funciona en Windows… y no tengo ningún windows a mano. Incluso intenté hacerlo desde una máquina virtual, pero no funciona: es muy exigente y quiere un pincho «de verdad», no le sirve un disco duro, y la emulación de pinchos USB en KVM da problemas (ya ni hablemos de VirtualBox…).

También intenté utilizar UnetBootin, que está disponible para Linux, pero desgraciadamente no sirve para el instalador de XP.

Sin embargo, a tozudo no me gana nadie, y al final conseguí instalarlo con mucha paciencia, así que aquí está el método, por si a alguien más le puede ser de utilidad.

Lo primero, avisar que el proceso de instalación será mucho más lento de lo normal, así que tomadlo con mucha paciencia y una buena infusión.

Ingredientes necesarios:

Lo primero, copiamos cualquier dato importante que tengamos en nuestro pincho USB a otro lado, porque vamos a tener que formatearlo.

Antes de comenzar la instalación, necesitamos disponer de una partición primaria reservada para el nuevo disco. En caso de que no la tengamos, la mejor opción consiste en crear, mediante UnetBootin, un pincho USB de Ubuntu, arrancar con ella el portátil y utilizar GParted para reducir el tamaño de una de las particiones actuales y dejar sitio para la nueva. Sobre como hacer esto hay  abundante material en Internet, así que no profundizaré.

Cuando ya tengamos una partición primaria en el disco, etiquetada con sistema de archivos FAT32 (importante) y situada antes que cualquier otra partición primaria de tipo FAT en el disco, procedemos a particionar el pincho USB. Lanzamos GParted, borramos todas las particiones que hubiese, creamos una partición extendida, y dentro una unidad lógica, etiquetándola como de tipo FAT32.

Una vez hecho esto, arrancamos UnetBootin, escogemos la imagen de CD fdfullws.iso, y la volcamos en el pincho. Cuando esté listo, copiamos en el pincho todos los archivos del CD de instalación de Windows.

Ahora estamos listos para hacer la instalación de FreeDOS: reiniciamos el ordenador con el pincho, y cuando pregunte, iniciamos con HYMEM y EMM386. Nos saldrá un prompt de DOS, en el que teclearemos D:. Gracias a que el pincho tiene solamente una partición extendida, C: se corresponderá con la partición primaria del disco duro, y D: será el pincho en sí. Si hubiésemos utilizado una partición primaria en el pincho, como éste aparece como primer disco haría que C: fuese el pincho en sí, con lo que no podríamos instalar correctamente FreeDOS.

Ahora tecleamos setup para iniciar la instalación de FreeDOS. Instalamos todo (excepto las fuentes, que no son necesarias), y salimos de nuevo al prompt. Ahora copiamos también todo el CD de instalación de Windows al disco duro mediante xcopy:

    xcopy /E d:*.* c:

Ahora tenemos que asegurarnos de que podremos iniciar el sistema correctamente, para lo que tecleamos

    sys c:
    fdisk /mbr

El primero asegura de que el sistema de arranque de FreeDOS está instalado en C:; el segundo borra el MBR (lo que incluye a GRUB; luego lo recuperaremos) y pone en su lugar el código de arranque básico de DOS.

Reiniciamos el ordenador y debería arrancar FreeDOS. Ahora tecleamos:

    ./i386/winnt.exe

lo que lanzará el instalador de Windows XP. Nos dirá que la caché de disco no está instalada y que podemos cancelar el proceso. No lo haremos; eso sí, la copia de archivos se demorará durante un par de horas (y no sirve la caché que incluye el propio FreeDOS: no funciona). Nos tomaremos un buen café hasta que, por fin, termine de copiar los archivos básicos y reinicie, continuando, ahora sí, por fin, la instalación como siempre.

En determinado punto nos indicará que la unidad está en formato FAT32 y si queremos convertirla a NTFS. En teoría el cambio no supone la pérdida de los datos, pero por si acaso yo preferí hacer la conversión después de instalar todo, y, efectivamente, se puede hacer sin riesgo.

Recuperando GRUB

Ahora que ya está instalado Windows nos queda recuperar GRUB para poder arrancar de nuevo Linux. Para ello volvemos a particionar el pincho, dejando una única partición primaria, instalamos en ella un CD Live de Ubuntu u otra distribución preferida y arrancamos desde él.

Una vez hecho, abrimos un terminal y procedemos a montar la partición raíz de nuestro sistema Linux, así como enlazar los pseudo sistemas de archivos /proc, /dev y /sys. Finalmente, usamos chroot para entrar en nuestro viejo sistema. Si la partición raíz está en /dev/sda1 y tenemos el directorio /tmp disponible para montar en él lo que queramos, haríamos:

    mount /dev/sda1 /mnt
    mount -o bind /proc /mnt/proc
    mount -o bind /dev /mnt/dev
    mount -o bind /dev/pts /mnt/dev/pts
    mount -o bind /sys /mnt/sys
    sudo chroot /mnt /bin/bash

Ahora ya estamos dentro de nuestro sistema como root,  y podemos proceder a reinstalar GRUB. En Ubuntu es tan sencillo como

    dpkg-reconfigure grub-common

el cual reconfigurará GRUB para añadir automáticamente el nuevo windows instalado. En otras distribuciones de Linux es necesario utilizar un editor para modificar el fichero de configuración de GRUB y luego ejectuar grub-install /dev/sda para reinstalarlo en el MBR.

¡Y listo!

Enlace dinamico

Acabo de lanzar la versión 8.0 de FPT_BT4LXMedia. La primera novedad es la nueva versión de Transmission, la 2.21. La segunda es que, por fin, los ejecutables utilizan enlazado dinámico.

Como recordareis, las versiones anteriores utilizaban enlazado estático porque no conseguía que arrancasen desde el disco, a pesar de utilizar LD_LIBRARY_PATH para apuntar al directorio con las nuevas bibliotecas. Para los que no sepan qué es eso, es una variable de entorno que permite añadir nuevas rutas en donde buscar bibliotecas de enlace dinámico, y éstas tienen prioridad sobre las «normales» del sistema. Así, si tengo un programa enlazado con una versión concreta de libc, diferente de la del sistema, puedo instalarla en otro directorio (por ejemplo, /tmp/libs) y lanzar el programa con:

LD_LIBRARY_PATH=/tmp/libs mi_programa

Por desgracia, esto no funcionaba en mi disco duro. Tras investigar mucho, descubrí que el problema estaba en el enlazador dinámico en tiempo de arranque. Resulta que el núcleo sólo es capaz de arrancar, por sí solo, binarios que estén enlazados estáticamente. Para los dinámicos lo que hace es delegar en /lib/ld-linux.so (o /lib/ld-uclibc en la biblioteca uClib). A pesar de llevar extensión .so, este fichero es realmente un programa (enlazado estáticamente, claro) diseñado para cargar en memoria el programa dinámico deseado, analizar qué bibliotecas necesita, cargarlas en memoria si aún no están, realizar toda la operación de enlazado y, finalmente, lanzar el código.

Por desgracia, la versión del enlazador dinámico de la gentoo que utilizo para desarrollar es más reciente que la de mi disco duro, lo que hacía que recibiese un error cada vez que intentaba ejecutar un programa compilado directamente. Para complicar aún más las cosas, la ruta del enlazador dinámico está especificada en cada ejecutable de manera inamovible, estableciéndose dicho valor durante la compilación. Y por si fuera poco, el enlazador de Busybox no permite su ejecución directa, por lo que tampoco podía hacer un simple /lib/ld-uclibc mi_programa.

Ante todo esto, la única solución que me quedó fue la de copiar el enlazador dinámico del entorno de desarrollo en una carpeta diferente y, al compilar bftpd, transmission y ctransmission, especificar la ruta deseada. Esto se hace en la etapa final de enlazado mediante la opción -Wl,–dynamic-linker=path/al/enlazador. De esta manera bastó con copiar el enlazador y el resto de bibliotecas a /tmp/hdd/root/libs y lanzar los programas con

LD_LIBRARY_PATH=/tmp/hdd/root/libs mi_programa

Con esto espero ahorrar algo de memoria. También haré algunas pruebas para ver si los programas funcionan bien con la versión de la uClib del propio disco duro, en cuyo caso podría ahorrar aún más.

Entre signos anda el juego

Una de las frases preferidas de mi madre es Está el viejo muriendo, y está aprendiendo; y como en la gran mayoría de los refranes, hay una grandísima verdad oculta en ella.

Y es que estos días estoy peleándome con el micro ARM de un TomTom, y me encontraba con que el código que iba perfectamente en mi PC daba un fallo rarísimo en el GPS: al imprimir el carácter ‘/’ no lo hacía bien; pero sólo ese, el resto los renderizaba perfectamente. Después de mucho depurar, descubrí que el fallo era debido, nada menos, que al signo de una variable. Y es que, a pesar de utilizar el mismo compilador (GCC) para ambos casos, resulta que un char a secas en PC es signed, como todo el mundo asume, pero en ARM es unsigned, por lo que un valor que tenía que ser -1 se convertía en 255 (la segunda parte del problema es que luego operaba con ese valor y con otro de 32 bits, con lo que, al añadirle los 24 bits restantes, no expandía el bit de signo). Una vez añadido el modificador correspondiente, todo pasó a funcionar perfectamente.

Así pues, nunca deis por supuesto el signo de una variable. Consejo de amigo.

Desplazando bits

Hace mucho tiempo, cuando empecé a programar en C, leí una curiosa advertencia sobre los operadores de desplazamiento de bits, los famosos >> y <<. Se afirmaba allí que, al desplazar una variable con ellos, los bits que salían se perdían (lógico, siendo un desplazamiento), pero que los bits que entraban por el lado opuesto tenían un valor indefinido, que podía ser cero o uno según la implementación.

Es cierto que todos los programadores asumen que lo que entra es cero siempre; pero pese a todo, yo, que tiendo a ser demasiado cauto, opté por añadir siempre una máscara AND para poner a cero los bits entrantes y así evitarme sorpresas.

Sin embargo, hace unos días, mientras optimizaba unas rutinas que hacen uso de desplazamientos, decidí investigar más a fondo el tema, porque a fin de cuentas una máscara consume ciclos de reloj, así que si había alguna forma de evitarla siempre sería una mejora. Y lo que descubrí me dejó gratamente sorprendido, porque en realidad el valor de los bits que entran no depende del compilador, sino que está perfectamente definido en el estándar.

Cuando se utiliza el desplazamiento hacia la izquierda (<<), por el lado derecho siempre entran ceros. Ahí nunca hay problemas. Por otro lado, cuando se utiliza el desplazamiento hacia la derecha (>>) en una variable sin signo (por ejemplo, en un unsigned int), por la izquierda también entran siempre ceros.

Sin embargo, cuando utilizamos variables con signo (por ejemplo, short int) en un desplazamiento hacia la derecha, los bits que entren por la izquierda serán una copia del bit de mayor peso del valor original. Así, si teníamos un número negativo (su bit de mayor peso está a uno), al desplazarlo hacia la derecha seguirá siendo negativo, porque los bits entrantes serán unos; en cambio, si era un número positivo (su bit de mayor peso está a cero) los bits entrantes serán cero.

Supongo que la razón de hacerlo así es que, si se utilizan rotaciones para hacer divisiones, se conserva el signo.

Este código ilustra perfectamente lo dicho aquí:

#include <stdio.h>

void desplaza(unsigned int o) {

  signed int s1,s2;
  unsigned int u1,u2;

  s1=s2=u1=u2=o; // asignamos el mismo valor a las cuatro variables

  s1>>=4; // desplazamos cuatro veces cada una de ellas
  s2<<=4;
  u1>>=4;
  u2<<=4;

  printf("Con signo:ntdesplazamiento a la derecha   %08Xn",s1);
  printf("tdesplazamiento a la izquierda %08Xn",s2);
  printf("Sin signo:ntdesplazamiento a la derecha   %08Xn",u1);
  printf("tdesplazamiento a la izquierda %08Xnn",u2);
}

int main() {

  printf("nDesplazamiento de 4 posiciones.n");
  printf("Valor original: 0xA50000A5 (bit de mayor peso a uno).n");
  desplaza(0xA50000A5);
  printf("nValor original: 0x5A00005A (bit de mayor peso a cero).n");
  desplaza(0x5A00005A);

  return 0;
}

La salida es la siguiente, donde se aprecia claramente como el bit superior se replica en los desplazamientos a la derecha de las variables con signo, pero no en el resto de los casos:

Desplazamiento de 4 posiciones.
Valor original: 0xA50000A5 (bit de mayor peso a uno).
Con signo:
  desplazamiento a la derecha   FA50000A
  desplazamiento a la izquierda 50000A50
Sin signo:
  desplazamiento a la derecha   0A50000A
  desplazamiento a la izquierda 50000A50

Valor original: 0x5A00005A (bit de mayor peso a cero).
Con signo:
  desplazamiento a la derecha   05A00005
  desplazamiento a la izquierda A00005A0
Sin signo:
  desplazamiento a la derecha   05A00005
  desplazamiento a la izquierda A00005A0

Trabajando con señales

Estos días he seguido trasteando con Bftpd, y me puse a trabajar en resolver un problema bastante molesto: la cantidad de procesos zombie que deja tras de sí.

Para entender lo que pasa, primero hay que explicar que Bftpd lanza un nuevo proceso por cada nuevo usuario que se conecta, en lugar de utilizar un solo proceso para gestionar todas las conexiones. Así, tenemos un proceso padre que se limita a escuchar, y cada vez que llega una petición de conexión crea un proceso hijo para que la gestione; también comprueba cuando un hijo se muere (porque se haya cerrado la conexión).

Y aquí es de donde surge el problema: cada vez que un hijo termina, emite una señal (en concreto SIGCHLD) hacia el padre, el cual, al recibirla, ejecutará una pequeña función o callback y luego seguirá su ejecución normal. En el caso de Bftpd, dicho callback comprueba qué hijo es el que se ha muerto, pide su valor de retorno (para evitar que se quede zombie) y libera una serie de recursos que le reservó. En concreto, el código de dicha función comienza con un:

pid = wait(NULL);
[codigo para liberar los recursos del proceso PID]

Hasta aquí todo parece correcto; por desgracia, después de cada sesión con Bftpd quedaban varios procesos zombie. La razón era, obviamente, que el proceso padre no había leído su valor de retorno, por lo que el sistema operativo no los podía hacer desaparecer; sin embargo, en el callback se lee siempre dicho valor, así que es obvio que algo raro estaba pasando.

Para depurar el código empecé por añadir unos printfs: uno en el punto en que se crean los procesos hijo, mostrando su PID; otro en el punto de finalización de dichos hijos, y otro en la función de callback de SIGCHLD. Ejecuté el servidor, hice unas cuantas operaciones, vi la salida por pantalla, y… ¡Sorpresa! ¡Había menos llamadas a la función de callback que muertes! Si todo funcionase como se esperaba, el número debería ser exactamente el mismo (cada muerte debería emitir una señal SIGCHLD, la cual haría que se ejecutase el callback). Sin embargo, por alguna misteriosa razón, algunos procesos morían sin emitir la señal.

Para aquellos a los que les de igual el por qué, y simplemente necesiten saber el como, daré primero la solución: se trata de leer los PIDs de todos los hijos muertos en cada llamada al callback, en lugar de leer el de uno sólo. En otras palabras, el código del callback para SIGCHLD debe ser:

do {
        pid = waitpid(-1,NULL,WNOHANG);
        if (pid>0) {
            [codigo para liberar los recursos del proceso PID]
        }
} while (pid>0);

Vale, pero ¿por qué ocurre esto?

Para entender lo que ocurre hay que irse un poco a las profundidades del núcleo, porque se debe a un problema de cómo están implementadas las señales.

En Linux, cada proceso tiene un conjunto de bits, y cada uno representa una señal. Cuando un proceso quiere enviar una señal a otro, lo que hace realmente es poner a uno el bit de dicha señal en el proceso receptor.

¿Y cuando comprueba el receptor la llegada de una señal? En cada cambio de contexto: en un sistema operativo multitarea, los procesos se van turnando en el uso de la CPU, de manera que primero la usa unos milisegundos el proceso A, luego otros milisegundos el proceso B, y así sucesivamente hasta que se acaba la lista y se vuelve al proceso A. Cada vez que se cambia de un proceso al siguiente se realiza un cambio de contexto, en el que primero se guarda el estado del proceso actual, se busca quien será el siguiente proceso, se carga su estado y se le cede el control. Pero, y aquí está la cuestión, antes de este último paso se comprueba la máscara de bits de las señales, y si alguna está activa se ejecutará primero el callback correspondiente.

¿Y por qué se pierden entonces señales SIGCHLD? Pues porque dos o más procesos se mueren «a la vez»; esto es, se mueren dentro del mismo intervalo entre dos ejecuciones del proceso padre. Así, lo que ocurre es que cuando se muere el primero, pone a 1 el bit de la señal SIGCHLD del proceso padre; el repartidor de tareas, al ver que ha muerto, libera todo lo que puede y pasa al siguiente proceso; éste muere también, y también pone a 1 el bit de la señal SIGCHLD del proceso padre… pero ese bit ya estaba a uno, por lo que se queda como está. Finalmente, el repartidor decidirá que es el momento de ejecutar de nuevo el proceso padre, pero antes verá que el bit de la señal SIGCHLD está activo, por lo que lo pondrá a cero y  llamará al callback. El resultado: se murieron dos procesos pero sólo se ejecutó una vez la función asociada a la señal, por culpa de que las señales se almacenan con un único bit.

Es por esto que la solución indicada arriba funciona: la señal nos indica que se ha muerto AL MENOS un proceso hijo, así que debemos comprobar todos, y no asumir que cada uno enviará una señal.

Este caso nos demuestra que las señales son un sistema de comunicación bastante frágil, por lo que no se debe abusar de él. Cosas como «contar el número de veces que llega una señal» o similares pueden dar problemas incluso si hay un único emisor, porque si emite varias veces la misma señal antes de que el padre recupere el control de la CPU, contarán como una única señal. Y como muestra para los incrédulos, un pequeño programita que ejemplifica todo esto:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <signal.h>

int v;

void senal(int valor) {

 printf("Recibidan");
 v++;
}

int main(int argc, char **argv) {

 int pid1,pid2,pid3,pid4,loop;

 v=0;
 signal(SIGUSR1,senal);
 pid1=getpid();
 pid2=fork();
 if(pid2==0) {
 fork();
 fork();
 printf("hijon");
 kill(pid1,SIGUSR1);
 kill(pid1,SIGUSR1);
 kill(pid1,SIGUSR1);
 kill(pid1,SIGUSR1);
 kill(pid1,SIGUSR1);
 sleep(2);
 } else {
 printf("padren");
 for(loop=0;loop<21;loop++) {
 sleep(1);
 }
 printf("Total: %dn",v);
 }
}

Este código crea un primer hijo, el cual se divide en cuatro hijos en total, y cada uno emite, de golpe, cinco señales SIGUSR1 al padre. Sin embargo, al ejecutarlo veremos que nunca se detectan todas ellas, sino, como mucho, una por proceso hijo (y a veces ni eso).

Transmission

Un nuevo avance en mi disco duro multimedia: he conseguido compilar el cliente de bittorrent Transmission. Las ventajas de éste sobre el viejo cTorrent son muchas, en concreto:

  • Código más reciente y mantenido: la última versión de cTorrent es del 14 de junio de 2008, lo que parece indicar que el autor lo ha dejado de lado, mientras que Transmission (versión 1.76) es del 24 de octubre de 2009, además de que ya están preparando la próxima versión (1.80).
  • Soporta cifrado: sólo por esto ya merece una atención especial, porque puede duplicar (o más) el número de sitios de los que descargar ficheros, además de que muchos Torrents que no funcionaban en cTorrent sí lo harán en éste.
  • Soporta uPNP: para los que no lo conozcan, es un estándar que, entre otras cosas, permite que un dispositivo situado detrás de un router con NAT pueda pedirle de manera automática la redirección de los puertos externos que necesite. Esto elimina por completo la necesidad de abrir a mano puertos específicos en el router; simplemente funcionará.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Avisados estáis.

Aquí podeis descargar el código completamente compilado, junto con los scripts para lanzar todo el sistema (1,2 MBytes), ajustados para el MemUp LX. Como en el caso anterior, hay que editar el fichero btpd para activar o desactivar los servicios que se deseen. He conservado cTorrent por si alguien prefiere utilizarlo de manera puntual (o incluso tener ambos a la vez en marcha, que a saber…), aunque lo normal será tener sólo Transmission y bFTPd. Al igual que en el paquete anterior, hay un fichero con instrucciones más detalladas.

Respecto a como lo compilé, pocas novedades, salvo el hecho de que, por mucho que especifiqué que quería un ejecutable estático, se empeñó en hacerlo dinámico. Encima, al utilizar autoconf y automake, no muestra la línea de comandos que está ejecutando en cada momento, con lo que ni siquiera podía hacer el enlazado «a mano». La solución, afortunadamente, fue tan sencilla como lanzar make V=1, para hacer la salida más verbosa y que lo mostrase. Así pude copiar y pegar la línea y añadir el -static.

Por desgracia, ni siquiera esto fue suficiente porque se empeñaba en enlazar con un fichero .la (libevent.la, para ser exactos), los cuales son para ejecutables dinámicos. La solución consistió en reemplazar ese fichero por un simple *.o, de manera que pudiese coger lo que más le interesase. Finalmente, un strip dejó el ejecutable limpio como una patena. El resultado es que las descargas ahora son más rápidas al contar con más peers, y encima la interfaz ha ganado aún más.

Obviamente, al ser ejecutables estáticos funcionarán en cualquier equipo con un procesador MIPSel y suficiente memoria, lo que permite reutilizarlos para otros discos multimedia. Lo mismo ocurre con los otros ejecutables (bFTPd, cTorrent y Yodctcs).

Aproveché además para hacer un cambio en la organización de directorios. Hasta la revisión anterior, en DOWNLOADS se almacenaban los ficheros temporales de cTorrent, y en BT los ficheros bajados. Para no ensuciar tanto el raíz del disco, he optado por crear dentro de BT una carpeta, ctorrent_tmp, para albergar esos ficheros, y otra, transmission_tmp, para que transmission haga lo propio. Estas carpetas se crean automáticamente si no existen. Si estabais bajando algo con cTorrent y quereis pasarlo a Transmission, basta con abrir el torrent (que estará, bien en ctorrent_tmp, bien en DOWNLOADS)  y, como el directorio de descargas es el mismo para ambos y no ha cambiado, Transmission comprobará la integridad de los datos que hay ahí y seguirá descargando justo desde donde se quedó el otro. Por tanto, una vez pasados los ficheros, es seguro borrar la carpeta DOWNLOADS.

Por último, actualicé el fichero de instrucciones.

Los que quieran acceder al nuevo bittorrent Transmission, sólo deben abrir la IP del disco en su navegador, contra el puerto 9090 (ej: http://192.168.1.101:9090).

Para finalizar, una captura de pantalla del nuevo cliente:

A disfrutar.

Compilacion en masa

En la entrada Emergiendo expliqué como generar un entorno de compilación cruzada basado en Gentoo para poder compilar cosas para nuestro disco duro, pero luego, en FTP-ando, eché todo por tierra al no poner binarios creados por mí. Ahora ya he sido capaz de compilar, así que, para los impacientes, aquí está el paquete con las últimas versiones de CTorrent (3.2.2), BFTP (2.6) y YAOD (0.7.2). Las instrucciones de instalación son las mismas que en el artículo anterior (FTP-ando). Como gran ventaja, algunos fallos de BFTP han desaparecido, y encima la tasa de transferencia ha subido a 3MBytes/seg.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Pasando ya a la chicha, la razón de que haya tardado tanto es que la cosa no es tan sencilla, por varias razones:

  • Para empezar, el disco duro tiene su propia versión de la uClibc, por lo que la única manera de garantizar que un programa funcione correctamente es compilarlo contra esa misma versión.
  • Por otro lado, en algunas versiones del compilador GCC cambia el fomato binario de las bibliotecas en C++, por lo que también es conveniente utilizar la misma versión de compilador GCC: para garantizar que la interfaz binaria entre la aplicación y las bibliotecas es la misma.
  • Por último, muchos paquetes no se pueden instalar en un sistema mediante compilación cruzada porque su configure hace cosas raras, como comprobar si GCC compila correctamente un programa de prueba… programa que estará en arquitectura MIPS y, por tanto, no correrá en un Intel, abortando el proceso de compilación.

Y si ya la cosa se veía complicada, encima nos encontramos con que Gentoo no tiene la versión de GCC utilizada en nuestro disco duro (la 3.4.4), y que algunas versiones de uClibc (entre ellas la 0.9.28.3, la de nuestro disco duro) no compilan con según qué compiladores o versiones de binutils. El resultado era desalentador.

La primera idea que consideré para resolver el problema fue meter un sistema Gentoo completo en el disco y ejecutar en él las aplicaciones usando chroot. Por desgracia esta solución es muy ineficiente porque necesita mucho espacio en disco y porque las aplicaciones sólo tendrían acceso a los directorios contenidos dentro del chroot, pero nunca a los de fuera.

La segunda idea consistía en intentar generar un conjunto nativo de compilador GCC, binutils y biblioteca uClibc con las versiones correctas a partir de fuentes oficiales. Por desgracia, el proceso es demasiado complejo y tampoco funciona con todas las versiones de GCC, binutils y uClibc que interesaba.

La tercera idea era usar BuildRoot, el entorno de generación de compiladores cruzados de BusyBox. Por desgracia, una vez más, no sólo no tenía las versiones necesarias, sino que tampoco compilaba cualquier combinación.

Por último, la cuarta, que ha sido la que decidí emplear, consiste en compilar estáticamente los programas deseados utilizando un compilador nativo en el propio disco duro multimedia. De esta manera, al no depender de ninguna biblioteca de enlazado dinámico, el programa funcionará en cualquier sistema, ahorrándonos el problema de la incompatibilidad de versiones. Además, al no importar la versión de binutils, GCC ni uClibc, podemos utilizar versiones más modernas, que siempre tendrán mayor seguridad y fiabilidad. Por último, al compilarse en el sistema de manera nativa, no habrá problemas con ficheros configure que hagan cosas «raras». Como inconveniente, necesita más memoria que un programa compilado dinámicamente.

Sin embargo, seguía con el problema de conseguir un toolchain para MIPS que funcionase correctamente, cosa compleja porque en Gentoo hay nueve versiones de GCC, cuatro de binutils y tres de uClibc (sin contar revisiones), y no todas las combinaciones compilan. Además, no bastaba con el toolchain, sino que también necesitaba instalar en nativo Bash, GCC, binutils, uClibc, make y el entorno básico con BusyBox. ¿Por donde empezar? Por desgracia la versión más reciente no compilaba, y no podía probar las 108 combinaciones posibles… O al menos, no a mano, así que hice un pequeño script en python que probase a compilar todas las posibles combinaciones. Lo dejé una noche, y el resultado fue que sólo compilaba con el GCC 3.4.6-R2 y GCC 4.1.2, las Binutils 2.18-R4, 2.19.1-R1 o 2.20, y sólo con uClibc 0.9.30.1-R1. En el resto de casos, o fallaba la generación del toolchain para compilación cruzada, o fallaba la compilación de las utilidades nativas.

Una vez descubiertas las versiones, sólo fue necesario generar un toolchain adecuado para compilación cruzada:

crossdev --target mipsel-unknown-linux-uclibc --without-headers --gcc 4.1.2 --binutils 2.20 --libc 0.9.30.1-r1
emerge-wrapper --init

Luego, compilar e instalar las aplicaciones básicas necesarias para poder compilar (lo he cortado por razones de espacio, pero es una única línea):

emerge-mipsel-unknown-linux-uclibc  =binutils-2.20 =gcc-4.1.2 =uclibc-0.9.30.1-r1 bash make gzip bzip2 
unzip tar gnuconfig m4 sys-apps/texinfo gawk coreutils sed grep shadow procps net-tools iputils 
debianutils cpio attr sys-apps/acl kbd nano less diffutils

Vemos que instalamos las mismas versiones de binutils, gcc y uclibc que las usadas para generar la cadena de compilación cruzada. Instalamos coreutils y demás en lugar de busybox (o system) porque las utilidades de éste son versiones recortadas y dan problemas con algunas compilaciones. También instalamos tar, gnuconfig, m4 y texinfo, los cuales serán necesarios para instalar autoconf, automake y libtool. La razón de no instalar estos últimos directamente es que la instalación de Perl por compilación cruzada no funciona; tendremos que hacerlo luego a mano.

Por último, creamos los directorios /proc, /dev y /sys en /usr/mipsel-unknown-linux-uclibc, y ya podemos comprimir ese directorio utilizando

tar -cpvf buildchain.tar /usr/mipsel-unknown-linux-uclibc

copiarlo en el disco duro, en /tmp/hdd/volumes/HDD1, descomprimirlo, y lanzar un entorno de compilación utilizando este script, que automáticamente montará mediante bind los directorios del sistema y utilizará chroot para cambiar al nuevo entorno. Ahora nos bajamos Perl, lo descomprimimos y lo compilamos con

sh Configure -de
make
make install

Cabe recordar que el procesador de este disco duro es MUY LENTO, por lo que es posible que necesite toda la noche para compilarlo. Por otro lado, podemos tener problemas con las fechas de los archivos, por lo que es fundamental cambiarlas utilizando el comando touch * en cada directorio. Esto se puede hacer más cómodamente con la línea

find -type d -exec touch {}/* ;

que hará un touch * de manera recursiva en cada directorio. Una vez hecho esto, instalamos autoconf, automake y libtool (no olvidarse de touch en cada uno), y ya tendremos nuestro sistema de desarrollo completo con el que podremos compilar cualquier utilidad. Sólo hay que tener en cuenta algunos detalles:

  • El procesador del disco duro no es gran cosa, así que la compilación tarda BASTANTE tiempo
  • Es fundamental añadir la opción -static en las opciones de enlazado. En algunos programas es posible hacerlo añadiendo LDFLAGS=-static justo antes de ./configure (ejemplo: para configurar ctorrent, la línea sería LDFLAGS=-static ./configure); otra opción es lanzar primero ./configure y luego editar el Makefile para añadirlo donde se defina LDFLAGS. Como opción final, se puede compilar normalmente y, cuando termine, copiar y pegar las líneas de enlazado (suele ser la última) y añadir -static a mano antes de ejecutarla.
  • Es muy recomendable eliminar el parámetro -g durante la compilación, pues lo que hace es añadir información de depuración totalmente innecesaria, además de impedir que el compilador pueda aplicar muchas optimizaciones. Para hacer esto no queda más remedio que editar manualmente el fichero Makefile (no olvidar que puede haber varios Makefiles en otros subdirectorios. Hay que editarlos todos). También es bueno utilizar el comando strip en el ejecutable final para eliminar los últimos restos de datos de depuración
  • Algunos programas están preparados para versiones de autoconf o automake anteriores a la que hemos instalado. En ese caso basta con hacer un autoreconf para regenerar los ficheros. Este debe hacerse después de autogen.sh si lo hubiera. Una vez hecho esto ya se puede ejecutar ./configure y make.
  • Es necesario ajustar las fechas de los archivos porque, si no, Make se lía y no sabe qué compilar. Para ello basta con ejecutar el comando touch * en todos y cada uno de los directorios del programa a compilar (la línea find -type d -exec touch {}/* ; lo hará de manera recursiva por nosotros). No recomiendo cambiar la hora del disco duro porque, por alguna razón, las veces que lo hice el sistema se volvió inestable, llegando a colgarse incluso.
  • En algunos programas, libtool «se vuelve loco» y empieza a lanzar copias de sí mismo indiscriminadamente, llegando a ahogar al procesador y colgando el disco duro. Si, cuando va a enlazar el código, un PS nos devuelve una gran cantidad de procesos libtool, hay que matarlos rápidamente y enlazar «a mano» el código.

Para aquellos que no quieran pasar todo el trabajo, pueden bajarse el entorno de compilación completo aquí. Basta con descomprimir el .zip, copiar el .tar en el directorio /tmp/hdd/volumes/HDD1 del disco duro y descomprimirlo mediante

tar -xpvf buildchain_1.0.tar

entrar en el directorio con cd buildchain, montar los sistemas de archivos virtuales (proc, dev y sys) con ./mount.sh y lanzar un chroot con ./launch.sh. Una vez se haya terminado, salir y desmontar los sistemas de archivos virtuales con ./umount.sh.

FTP-ando

Actualizado; el enlace a los binarios estaba mal.Tras curiosear y probar, ya he conseguido meter un nuevo cliente de BitTorrent y un servidor de FTP en mi disco duro, aunque, por diversas razones (que comentaré en otra entrada), el código proviene de la página del MediaPlayer RTD1261, en lugar de haber sido compilado con la Gentoo que comentaba en entradas anteriores.

El nuevo servidor BitTorrent es cTorrent, junto con la interfaz web yodctcs. Respecto al servidor FTP, se trata de bftpd. Básicamente he retocado las configuraciones para que todo funcione sin tener que meter ficheros en carpetas del directorio raíz (por ejemplo, en /etc o en /lib). La razón es que, por defecto, toda esa parte (que está almacenada en la Flash) se monta en modo sólo-lectura; pero aunque pudiese escribir, sería bastante arriesgado (un error y tendré un caro pisapapeles), por lo que mi intención es hacer cualquier cambio únicamente en el disco duro, en donde se pueda recuperar todo simplemente ejecutando la opción de formateo desde el menú principal.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Avisados estáis.

Lo primero es copiar el contenido del fichero con los binarios (este) en el disco duro multimedia, en concreto el fichero upgrade.tar. En él están todos los binarios y ficheros de configuración.

Una vez que lo tenemos (en /tmp/hdd/volumes/HDD1) entramos por telnet, lo movemos a /tmp/hdd/root y lo descomprimimos en esa carpeta con tar -xpvf upgrade.tar, de manera que se conserven los permisos de los ficheros. Dentro hay cuatro carpetas y un fichero script:

  • etc: contiene los ficheros de configuración del cliente BitTorrent y del servidor FTP
  • bftpd: contiene los binarios del servidor FTP
  • ctorrent: contiene los binarios del cliente BitTorrent cTorrent y de su interfaz web dctcs
  • lib: contiene las bibliotecas libgcc_s.so y libstdc++.so, necesarias para dctcs
  • btpd: reemplaza al script original.

El script btpd permite lanzar y parar todos los nuevos servicios de manera selectiva, relanzando aquellos procesos que queremos que estén lanzados si se caen, y matando los que no queremos si, por la razón que sea, se ejecutan (todo esto es posible porque el disco duro ejecuta regularmente este script, junto con el de samba, con el comando start). También monta, si se desea, la partición principal como EXT3. Por último, asigna a la variable de entorno LD_LIBRARY_PATH el valor /tmp/hdd/root/lib de manera que los programas lanzados desde él puedan utilizar las bibliotecas aunque éstas no se encuentren en los directorios por defecto (/lib, /usr/lib o /usr/local/lib). Es necesario editar este script (por ejemplo, con vi) para ajustar la configuración a nuestras necesidades. En concreto, si lo abrimos, vemos al principio lo siguiente:

# change here to set the services you want:
# 1: launch it
# 0: don't launch it

# main partition in EXT3 format
HD_EXT3=1

# old BitTorrent service
OLD_BT=0

# new BitTorrent service (cTorrent)
NEW_BT=1

# FTP server
FTP=1

Así, si queremos utilizar el cliente de BitTorrent original, tenemos que almacenar un 1 en OLD_BT. Si queremos utilizar el nuevo cliente BitTorrent, ponemos un 1 en NEW_BT. Si queremos activar el servidor FTP ponemos a 1 FTP. Y si hemos formateado en EXT3 la partición principal del disco duro, entonces tenemos que poner a 1 HD_EXT3 (si la tenemos en NTFS es imprescindible ponerla a 0). Una vez hecho esto, movemos dicho script a la carpeta script, reemplazando al viejo btpd. En el tar.bz2 incluyo la versión original, por si alguien se arrepiente.

Finalmente, lanzamos los nuevos programas mediante el comando ./btpd start y listo, ya tenemos acceso por FTP y un nuevo cliente BitTorrent.

Para acceder al cliente bittorrent hay que abrir con un navegador una conexión al puerto 8080 del disco duro multimedia. El usuario por defecto es admin, y la clave 123, pero se pueden cambiar editando el fichero /tmp/hdd/root/etc/dtcts.conf. Algunos cambios que hice en él con respecto al original de la página del otro disco duro fueron, por una parte, aumentar el buffer de recepción hasta 64Kbytes para conseguir la misma velocidad de transferencia (2,4MBytes/seg) que con SMB (con los 2Kbytes originales sólo se conseguían 200Kbytes/seg, diez veces más lento), así como eliminar toda la parte de registro (log) para no consumir disco duro inútilmente (quien quiera activarlo sólo tiene que echar un vistazo al fichero de configuración de demostración que viene en el paquete original de dtcts). Por último, cambié los nombres de las carpetas: en /tmp/hdd/volumes/HDD1/BT almacena los ficheros recibidos, igual que el viejo cliente BitTorrent, y en DOWNLOADS almacena los .torrent de los ficheros que se están descargando.

Respecto al servidor FTP, por defecto se puede entrar como anónimo, pero se puede cambiar la configuración en el fichero /tmp/hdd/root/etc/bftpd.conf.