Febrero
2008
Peligros en la programación con hilos
Hay un par de aplicaciones de TCOS (tcos-volume-manager y tcos-devices-ng) que vienen arrastrando un comportamiento un tanto aleatorio, a veces arrancan, a veces no, este tipo de bugs son los más dificiles de depurar porque no sabes muy bien por donde empezar...
La razón de ellos es siempre la misma "error: xauth access denied" por lo que hemos estado revisando como se producía el «login» usando la cookie de las X.
El método de autenticación es muy simple (basado en el que se usa con LTSPFS), se lee la cookie (xauth list) cuando arranca tcos-devices y se envía al terminal para ver si es válida y permite hacer una conexión a las X del terminal.
Este método funciona bien cuando no hay conexiones concurrentes pero ¿qué pasa cuando llegan dos peticiones a la vez?
Pues la segunda petición puede llegar cuando aún se está procesando la primera y tirar una de las dos dando acceso denegado cuando en realidad los datos son válidos.
¿Cómo hemos descubierto el problema?
Siempre había probado tcos-devices-ng con pendrive de una partición pero cuando el pendrive tiene 2 (o más), udev genera 3 eventos (suponiendo que el pincho sea /dev/sda):
* ACTION=add DEVNAME=/dev/sda (este evento es la detección del dispositivo completo, sino tuviera particiones también lleva ID_FS_TYPE)
* ACTION=add DEVNAME=/dev/sda1 ID_FS_TYPE=vfat (primera partición)
* ACTION=add DEVNAME=/dev/sda2 ID_FS_TYPE=vfat (segunda partición)
tcos-devices-ng toma estos eventos y los procesa...
Para el primero se muestra una notificación con la marca y modelo del pendrive, para los eventos con FS_TYPE se genera un nuevo thread (el ACTION=add con ID_BUS=usb lo que hace es montar en remoto y esperar a otro evento ACTION=mount para montar en local)
Por cada petición y para que el terminal acepte las conexiones se manda la cookie de las X, si las dos acciones ACTION=add se producen casi a la vez (como así ocurría) se hacían peticiones concurrentes al método handle_xauth lo que provocaba que a veces sí, a veces no, se montasen las dos particiones.
Soluciones:
1.- Hacer una especie de semáforo «en ámbar» (no rojo) en GetDevicesInfo (el método python que habla con el terminal ligero) para que sólo se ejecute una a la vez, la forma de hacerlo es con una función wait y una variable lock que hace una espera entre 0 segundos y un máximo de 4.
2.- Modificar handle_xauth para que use un archivo temporal basado en mkstemp: ver
Espero de esta forma haber solucionado bastantes problemas aleatorios que ocurrían cuando se usaban estas aplicaciones y que las hacían un tanto defectuosas...
Macho, estás hecho un fiera. ¿Sigues intentando meter TCOS en Debian? La última vez creo que no te habían hecho caso porque decían que ya había otros proyectos parecidos, ¿no?
Un par de apuntes:
¿Distribuyes TCOS con diferentes licencias según que partes del paquete? xauth.c (no sé si has escrito tú este fichero) tiene la LGPL y TcosXmlRpc.py tiene GPL v.2 o posterior.
¿No te planteas la actualización a GPL3?
Gracias por los cumplidos ;)
El tema Debian aún está en el aire, varios DD están interesados en subirlo pero ahora mismo personalmente no lo veo una prioridad para el proyecto, tenemos repositorios con un montón de versiones de Debian y Ubuntu y todavía hay gente que no lo ve con muy buenos ojos... espero que el mes que viene, con un artículo en una revista conocida, cambie un poco esto.
En cuanto al tema de la licencia me acabas de sacar los colores, esa cabecera la he copiado de algún sitio pensando que era GPL2+ y ha resultado ser LGPL, todo el proyecto es GPL2+ porque en principio era la más cómoda para trabajar, de hecho me han propuesto pasar a Afero-GPL para obligar a que los trabajos derivados publiquen los cambios... en fin no se que haremos con el tema copyright/copyleft...
pues lo de la afero no me parece mala idea la verdad, así se obliga a los trabajos derivados a publicar los cambios y no se convierte esto en un jaleo de versiones :-)