Hay que ver qué manía tan cansina tienen los desarrolladores de ciertos programas o aplicaciones en GNU/Linux de estropear lo que bien funciona. Es una cosa que me irrita sobremanera. Por lo general, cuando sucede algo así tiendo a saltar de distribución en busca de aquella en la que el error no se produzca y quedarme agazapado a su sombra, esperando el siguiente problema que dispare un nuevo cambio. Pero las cosas han mejorado para mí y hace ya bastante tiempo que salir de Chakra no me comporta más que quebraderos de cabeza e incomodidad. Esto lo tengo más que visto y comprobado porque sigo con mis permutas compulsivas de cuando en cuando, aunque cada vez son más esporádicas y de menor duración. Cambiar por cambiar, gracias a la inestimable ayuda de Clonezilla, para rápidamente regresar al hogar. Y en una de éstas, NetworkManager me ha dejado tirado, infortunio que provoca el artículo de hoy que es mitad relato, mitad petición de ayuda.

La situación inicial

En un alarde de originalidad, resulta que vamos a empezar por el principio. Mi partición de Chakra seguía rodando, como buena distribución “semirolling” que es. Muy buena, ya lo sabéis, por eso es mi favorita. Llegado el momento, una actualización del paquete NetworkManager, encargado de la gestión de conexiones tanto cableadas como inalámbricas, produjo un comportamiento errático que derivaba en la imposibilidad de encontrar las redes disponibles para que el equipo se conecte a ellas. Fui capaz de solventarlo y di cuenta de la solución en un artículo publicado en Colaboratorio. Una vez aplicado el remedio en mi archivo de configuración, NetworkManager continuó funcionando bien durante los días sucesivos.

El desencadenante… maldito distro hopping

Cada vez que se me cruza el condenado cable que desata las ganas de probar una nueva distribución GNU/Linux se termina liando de alguna manera, en especial si la locura es completa, de tal modo que me lleve a sobrescribir la partición de Chakra en el disco SSD. Como me conozco mejor que si me hubiese parido, siempre tengo una imagen funcionante de Chakra en mi disco de respaldo. A decir verdad, ni me acuerdo de qué distro quería probar en mi disco principal, lo que sí que recuerdo es que la cata duró tan poco como de costumbre y en un par de horas ya estaba deseando de volver a Chakra.

Así que, armado por enésima vez con mi pendrive de Clonezilla, me dispuse, contento y feliz, a reinstaurar Chakra a su lugar habitual. Con la mala fortuna, por falta de previsión, que la última imagen que grabé con Clonezilla resultó estar corrupta. No será que en la genial utilidad no te insisten en la necesidad de comprobar la imagen grabada… pues nada, error de principiante. Esto es de primero de Distro hopping, amigos, recordad: hay que comprobar las copias de seguridad antes de darlas por buenas.

El caprichoso error

Que no cunda el pánico… precisamente acaba de salir la nueva iso de Chakra Goedel, la cual revisé para Colaboratorio y todo funcionaba bien. Maldiciendo el tener que volver a configurar un sistema desde cero, por mis gilipolleces habituales y locuras sin solución, me zambullí en la tarea. En fin, lo de siempre: instalar con Calamares, reiniciar, instalar los controladores propietarios de la tarjeta gráfica NVIDIA… y llegó el turno del adaptador inalámbrico.

Tras compilar los controladores, aplicar el pequeño truco y reiniciar… nada de nada. No había redes inalámbricas disponibles. El asunto era peliagudo, porque unos días atrás, insisto en que todo funcionaba tanto en la antigua instalación de Chakra como en la nueva que hice para la revisión. ¿Qué podría estar pasando entonces?

Después de bucear bastante por Internet no encontré nada claro sobre qué provocaba este comportamiento. Errores parecidos al mío en distintas distribuciones, casi siempre sin otra solución que cambiar el gestor por otro, como Wicd. Esto ya lo intenté, con el inconveniente de que Wicd tarda bastante en lograr una conexión, de manera que los servicios que dependen de ésta para funcionar comienzan tarde y mal, como es el caso del cliente de ownCloud. La única diferencia notable entre la instalación que hice de Chakra para la revisión y la actual estriba en que una se hizo en un disco duro mecánico y la otra en un disco SSD. Por lo que, si pensamos un poco, los tiros pueden ir por ahí: el inicio es tan rápido en el caso del disco de estado sólido, que algo se solapa con NetworkManager e impide su correcto desempeño.

Resumiendo: la culpa es de systemd. ¿Otra vez? Sí, otra vez. Por iniciar los servicios en paralelo en vez de en modo secuencial.

Soluciones: ¿alguien me ayuda?

Que no se me enfaden los defensores de systemd todavía, que estaba bromeando. Un poco, al menos. La culpa parece ser, en realidad, de NetworkManager, aunque me resulta más complicado depurar el error desde que todos los servicios se levantan en paralelo. Entiendo que a los gurús de esto les parecerá muy sencillo y concluirán que el culpable soy yo, por torpe y/o vago, y no les voy a quitar la razón. Ambos defectos los tengo, al menos en lo que a la Informática respecta. No doy más de mí, qué le voy a hacer. Lo que sí fui capaz de descubrir es que basta un reinicio del servicio de red para que todo vuelva a la normalidad. Es decir, un simple y llano:

sudo systemctl restart NetworkManager

consigue devolver a mi conexión inalámbrica a la vida plena. Con su máxima velocidad, además.

Teniendo en cuenta lo anterior, en el capítulo de posibles arreglos he intentado varias cosas, con éxito tendente a cero. A saber:

Cambiar de NetworkManager a Wicd. Lo explicaba más arriba: lento como él solo a la hora de conectar, hace que no se inicien bien programas como Ktorrent o el cliente de ownCloud. Descartado, pues.

Crear un servicio de systemd nuevo que reinicie la red. Aquí, mis conocimientos casi nulos me han hecho patinar, ya que no fui capaz de que dicho servicio funcionase. Aparece como activo al consultarlo, pero no hace lo que le pido.

Modificar el inicio de los servicios de red con el comando sleep. Debe ser una burrada, casi seguro, pero en cualquier caso nunca me funcionó el colocar un “sleep 10 &&” antes, dentro de la línea de ejecución de NetworkManager en el archivo NetworkManager.service. La instrucción es absolutamente ignorada.

Ejecutar un script al inicio de sesión que reinicie el servicio. Éste funciona, aunque con la tremenda pega de que precisa que introduzcamos la contraseña del administrador. De momento es con la solución con la que me he tenido que quedar, al fallarme la siguiente:

Crear una tarea (con crontab) que se ejecute al iniciar la sesión y reinicie NetworkManager. La primera vez que lo intenté y comprobé que funcionaba, casi doy saltos de alegría. Pero mi gozo cayó en un pozo al segundo y sucesivos reinicios… pues ya no iba. Era la solución idónea, ya que al crear la tarea con “sudo crontab -e” no se me pedía contraseña para su ejecución. Pero, como digo, solamente fue efectivo la primera vez, pese a indicar la etiqueta @reboot en la correspondiente línea de la tarea. Y tampoco alcanzo a entender el porqué.

Por tanto, me he de conformar con la cuarta de las supuestas soluciones, que me lanza un feo cuadro de diálogo (el script llama a kdesu) recién inicio la sesión que, para colmo, me obliga a introducir la contraseña dos veces para que me haga caso. Ni idea de por qué ocurre esto, la verdad. Como veis, una solución sí que es, aunque muy poco elegante. De ahí que acuda a vuestra sapiencia, queridos amigos:

¿Cómo solucionaríais la necesidad de reiniciar NetworkManager en cada inicio del equipo?

Espero vuestras respuestas como agua de Mayo. Si mejoran mi incompetente solución, serán más que bienvenidas. Y si no, bueno, al menos hemos echado el rato escribiendo y leyendo este artículo. Lo mismo hasta aprendemos algo, sobre todo yo. A buen seguro hay cosas peores.

Salud

La imagen de portada es obra de Rawpixel.com y aparece por cortesía de Shutterstock.