Hace más de seis meses escribí un artículo bastante largo llamado Bugs en Xfce
(1) describiendo la busca y captura de un bug del que creía
culpable un componente de Xfce, y que resultó ser un bug de gstreamer.
El propio título sugería que iba a haber una segunda parte, que es la presente.
Pero he decidido cambiarlo ligeramente porque, como en el anterior artículo,
el bug que yo achacaba a un componente de Xfce ha terminado siendo (como ya
entonces me temía) un bug de una parte diferente, mucho más profunda, de la pila
Linux. Pero no ha sido hasta encontrar la solución cuando he podido confirmarlo.
El bug
Pero describamos el problema. Thunar, el file manager de Xfce, tiene
un plugin llamado thunar-volman
que nos muestra otras unidades o discos
—particiones realmente—, y que nos sirve para montarlas y desmontarlas, etc.
Cuando conectamos una nueva unidad como un USB stick o un disco externo nos la
muestra en la lista de dispositivos para que podamos acceder a los mismos.
Además se puede configurar para que monte automáticamente las nuevas unidades
que se conecten (creo que es el comportamiento por defecto, aunque yo lo tengo
deshabilitado).
Esta característica me estaba funcionando excepto cuando pinchaba mi teléfono
Android en modo "USB mass storage" para pasarle o extraer ficheros. Buscando
por Internet vi que otra gente tenía el mismo problema pero con CDs y DVDs.
Probé a introducir un CD en mi CD-ROM y tampoco aparecía en Thunar. Supuse
(acertadamente) que ambos problemas estaban relacionados.
Encontré un bug relacionado en el bugzilla de Xfce, pero por no abrirme una
cuenta en un sitio más, reporté el bug a Debian: #721996. En un
primer momento describía el bug como "no consistente", ya que algunas veces la
unidad si se mostraba pero la mayoría de las veces no. Más tarde me percaté que
el teléfono (o el CD) si aparecían en Thunar si el dispositivo estaba conectado
(o el CD metido en la bandeja) antes de arrancar el sistema. Era después, cuando
el sistema ya estaba en marcha, cuando las unidades no aparecían.
Podéis ver el intercambio de mensajes con el maintainer en el bug: a indicación
suya miré si el dispositivo era detectado por los distintos niveles desde el
hardware a thunar-volman (hardware → kernel → udev → udisks → dbus →
thunar-volman). Aparentemente las notificaciones subían hasta llegar a udisks,
después Thunar-volman se quejaba de errores en la consola (recogidos en el
fichero .xsession-errors
). El maintainer no volvió a decir nada y la cosa se
quedó estancada.
Para mí en ese momento era claramente un problema de thunar-volman, entre otras
razones porque si fuera un problema general, de una capa inferior, hubiera
encontrado quejas de usuarios de otros escritorios como KDE, GNOME o Unity.
Seguro que los usuarios de Ubuntu se hubieran quejado si los CDs no se vieran.
Así que el problema debía estar en Xfce, que al ser un DE "minoritario" podía
pasar desapercibido más fácilmente.
Esta idea cambió cuando encontré este post dándole cera a udisks2 y a su
desarrollador. Con la mosca detrás de la oreja, hice una
prueba: reiniciar el demonio de udisks2 teniendo el dispositivo conectado.
¡Funcionó! Así que era por eso que en el arranque detectaba los CDs y el
teléfono: porque era cuando se lanzaba el demonio. Eso me proporcionaba al menos
un workaround mientras lo arreglaban (si es que lo arreglaban, porque el
catastrofismo de la crítica dejaba poco espacio a la esperanza). Eso sí, era un
peñazo, porque el desarrollador ni se había tomado la molestia de incluir una
forma de ordenarle al demonio que se reiniciase o forzar una actualización, y la
gente de Debian tampoco (que seguro que tiene que ver con ser un servicio
D-BUS). Cuando quería conectar el teléfono o leer un CD tenía que literalmente
matar el proceso udisksd desde root y volver a lanzar el proceso a mano.
La solución
Revisando hace unos días el bug abierto, encontré referencias en el bugzilla de
Xfce a estos otros dos bugs de Debian: #725978 (de udisks2) y
#713877 (de udev). En estos bugs no sólo se describía el problema
sino que se daban un par de soluciones.
El origen del problema se describe ahí como "udisks usa sondeo (polling) en
espacio de usuario en vez de usar el interno del kernel", y las soluciones se
basan en "activar el sondeo interno del kernel para los dispositivos de bloque".
La primera solución hace eso literalmente, cambia el valor de cierta variable
del kernel haciendo que el polling de dispositivos de bloque se efectúe cada
2000 milisegundos (u otro valor) en vez de 0 (desactivado):
echo 2000 > /sys/module/block/parameters/events_dfl_poll_msecs
Para hacer este cambio persistente, lo podemos añadir a /etc/rc.local
para que
el valor se cambie en cada arranque del kernel (otra alternativa es pasar un
parámetro al kernel mediante grub).
Esta solución tiene un inconveniente, y es que es muy intrusiva: se aplica a
todos los dispositivos de bloque, incluyendo los discos duros que en realidad no
lo necesitan. Y como señala algún comentario "es una bomba de relojería bajo la
alfombra" esperando a estallarnos en cualquier momento. ¿No podríamos
restringirlo sólo a las unidades que se montan y desmontan, a las unidades
removibles? Eso es lo que hace la segunda solución, mediante una regla de
udev:
ACTION=="add", ATTR{removable}=="1", ATTR{events_poll_msecs}=="-1", ATTR{events_poll_msecs}="2000"
En cuanto a dónde poner esta regla, el parche de Ubuntu la introduce en el
fichero 60-persistent-storage.rules
, que en Debian está en el directorio
/lib/udev/rules.d/
. O puedes ponerla como aconsejan en
/etc/udev/rules.d/61-removable-storage-polling.rules
si no quieres que una
actualización del paquete te la elimine. Pero en realidad, como la regla ya se
ha introducido en el paquete udev a partir de la versión 204-9, deberías querer
que se sobreescriba en la actualización siguiente.
Sólo hay un pequeño problema, y es que udev forma parte ahora del paquete
systemd en Debian, y si no utilizas systemd init como sistema de arranque el
paquete no se actualiza. Así que el bug está corregido, pero no para los que
usamos sysvinit, que tendremos que introducir la regla a mano.
Activar el kernel polling no sólo sirve para este caso, sino que ayuda a otras
aplicaciones que "no tienen dependencia del sondeo de espacio de usuario
(udisks)" como el gestor de ficheros SpaceFM que también explica cómo
activarlo.
¿Por qué ha tardado tanto este bug en ser corregido? Pues, primero, porque en
algunas distros ya estaba corregido, como Ubuntu y derivados. Ubuntu lleva su
propia versión de udev forkeada ya que no usaban systemd sino upstart. Gentoo
usa su propio fork de udev, eudev.
Otra gente usaba todavía la antigua versión de udisks, la 1, en vez de udisks2.
En udisks1 el sondeo lo hace la propia aplicación, mientras que udisks2 se
reescribió para aprovechar las nueva característica de sondeo del kernel.
En Debian Wheezy, por ejemplo, el bug no existe porque emplea udisks1. Otra
gente, ante los contínuos problemas con udisks2 se pasó a alternativas como
udevil (del autor de la crítica a udisks2 de arriba y SpaceFM) o udiskie.
Los bugs existen y existirán probablemente siempre. Lo que no es de recibo es el
tiempo que transcurre entre que se reportan y se solucionan, existiendo incluso
soluciones. El bug #713877 es del 23 de junio de 2013, y ya venía incluso con la
solución, y sin embargo no se ha cerrado (parcialmente) hasta el 26 de abril de
2014. Los que han abierto el bug contra udisks2 o como en mi caso contra un
componente superior, ni siquiera nos enteramos. La información está dispersa en
múltiples bugs, en múltiples bug trackers, ... No sé qué solucion hay, o si
hay solución, pero en ocasiones el estado de estas cosas es desalentador.
:wq