Algunas herramientas para analizar y gestionar la duración del arranque del sistema en distribuciones GNU/Linux que utilizan Systemd.

Systemd es el gestor de arranque, o administrador del sistema y de servicios para Linux, que actualmente utilizan muchas distribuciones GNU/Linux, como Debian, Ubuntu, openSUSE, Fedora o Arch Linux. La duración de los procesos de arranque del sistema puede variar dependiendo de múltiples factores entre los que se encuentra el hardware (características de los componentes del ordenador como CPU, GPU, tipo de disco local donde se encuentre el sistema, etc), y el software (distribución y versión de esta, escritorio, aplicaciones, etc), e, incluso, en unas mismas condiciones puede haber variaciones, unas veces de muy corta duración y otras un tanto más prolongadas debido a diversos factores.

1. ¿Se demora el arranque de nuestra distribución?

En las distribuciones con fecha concreta de lanzamiento, y particularmente las de pruebas, por errores del sistema se puede demorar el arranque, aunque posteriormente pueden ser subsanados con parches en actualizaciones del sistema. No obstante, una actualización puede también provocar una demora por algún error en los archivos de configuración. También, la instalación de algún software por parte del usuario, o alguna configuración que establezcamos posteriormente, puede conducir a una demora en el arranque. Y … etc.

Ahora bien, todo esto no suele ser un tremendo problema que nos deba preocupar y mantenernos en una alarma continua. En muy contadas ocasiones se me han presentado demoras significativas durante el arranque, como para que tales sucesos llamaran mi atención. En unos casos han sido debidos a errores del sistema y, en otros, a la instalación de software. Y es en base a lo que he indagado en estas situaciones, junto con algunos comentarios de lectores del blog en distintos artículos, lo que me ha conducido a redactar el presente artículo. Como en la mayoría de las ocasiones, muestro simplemente mis anotaciones, más o menos ordenadas, por si a alguien que pase por aquí le es útil.

2. Systemd-analyze

Systemd dispone de una herramienta llamada systemd-analyze, que permite evaluar el proceso de arranque con el fin de mostrar qué unidades están ocasionando una demora en el proceso de arranque. Estas unidades – a las que nos referiremos a lo largo del texto- hacen referencia fundamentalmente a servicios (.service), puntos de montaje (.mount), dispositivos (.device) o sockets (.socket). Una vez obtenida esta información se podría optimizar el sistema para minimizar el tiempo de arranque.

Esta herramienta, que utilizaremos en terminal, dispone de varios comandos que nos informan de la duración de los procesos con más o menos detalle. Veamos:

# systemd-analyze

Nos muestra una salida como esta:

Startup finished in 1.763s (kernel) + 4.812s (initrd) + 49.935s (userspace) = 56.511s

Esta información general que nos muestra este comando, es el tiempo total del último arranque del sistema. Especifica el tiempo empleado en cargar el kernel; la carga del initrd (un sistema de archivos temporal usado por el núcleo Linux durante el inicio del sistema); y el tiempo en el espacio del usuario. En algunas distribuciones, como Debian/Ubuntu y derivadas, initrd no aparece y su asignación de tiempo se carga en kernel.

Esta otra salida de información es la que se obtenía antes de optimizar mínimamente el arranque (ver apartado 4) y que finalmente se tradujo en la mostrada anteriormente:

Startup finished in 1.779s (kernel) + 5.036s (initrd) + 1min 54.778s (userspace) = 2min 1.594s

Y estas otras dos salidas son de otras dos distribuciones que nos pueden servir de referencia en cuanto a la variabilidad:

Startup finished in 5.725s (kernel) + 38.328s (userspace) = 44.054s
Startup finished in 4.507s (kernel) + 19.146s (userspace) = 23.653s

Si el disco local donde están instalados estas distribuciones -que es un disco duro tradicional HDD con unos cuantos años- fuera del tipo SSD los tiempos serían más bajos.

# systemd-analyze blame
Nota: presionar la tecla “q” cuando finalice de listar para salir.

Este comando, que va más lejos, nos detalla el tiempo empleado en cargar cada una de las unidades.

# systemd-analyze blame | head

Este, que puede ser más práctico que el anterior en ocasiones, nos muestra sólo las primeras unidades que más tiempo tardan en cargarse.

# systemd-analyze critical-chain

Muestra una información más gráfica a modo de árbol con la cadena de unidades que tienen los mayores tiempos de carga.

# systemd-analyze plot > something.svg

Crea un gráfico detallado con toda la cadena de ejecución, mostrando el estado de las unidades. El gráfico que genera se ubicará en “nuestro usuario”.

Para más detalles y opciones de systemd-analyze en terminal:

# man systemd-analyze

3 . Obtener información directa durante el arranque del sistema

Durante el arranque del sistema, cuando se muestra Bootsplash, presionamos “Flecha abajo” de las teclas de dirección, entonces se nos mostrarán las líneas de texto del proceso de arranque del sistema. Aquí podemos detectar algún error. La mayoría de las líneas estarán precedidas por “OK” en verde, pero también podría aparecer alguna unidad con “FAILED” que indica que esa unidad no se ha cargado.

En algún momento el proceso se puede detener durante un tiempo más o menos prolongado, presentándose un mensaje que al final incorpora un contador de tiempo; es algo similar a lo siguiente:

A start job is running for …. unidad_problema (X seg /no limit)

En ocasiones el contador de tiempo muestra un límite (X seg / 1 min 30 s). Unos ejemplos,

A start job is running for wicked managed network interfaces (x seg / no limit)
A start job is running for ModemManager.service (x seg / no limit)

Estos mensajes están relacionados con los problemas que hace que se demore el arranque. Consiguientemente, con las unidades que más tiempo consumen, y que identificamos con los distintos comandos de systemd-analyze. No obstante, he observado que algunas veces se muestran durante unos segundos para una unidad concreta pero no siempre; el comportamiento de la unidad debe ser variable.

4. Algunas aplicaciones gráficas

Estas aplicaciones en principio las podemos utilizar para informarnos del estado de las distintas unidades (habilitada, activa, inactiva, etc), pero también podemos ejecutar algunas ordenes (como activar o desactivas la carga de una unidad durante el arranque o su detención y recarga en una sesión, etc), que como veremos se pueden también ejecutar por terminal con systemctl. En cualquier caso, no creo que sea conveniente hacer nada hasta que estemos bien documentados y sepamos a ciencia cierta que es lo que tenemos que hacer, si es qué hay algo que hacer en este sentido.

● Systemadm o “systemd System Manager”. Lo encontraremos en “Sistema” del lanzador de aplicaciones, tras instalar el paquete systemd-ui.

● Systemd-kcm. Es un módulo de “Preferencias del sistema” en el apartado “Administración del sistema” del entorno de escritorio KDE Plasma 5. Hay que instalar el paquete kde-config-systemd.

● Administrador de servicios en el grupo de “Sistema” de YaST, esa tremenda herramienta gráfica que contribuye sobremanera a la singularidad de openSUSE.

5. ¿Qué hay que hacer ante una demora en la cargar de una unidad? O ¿Cómo optimizar el arranque?

Como los motivos pueden ser muy variados las respuestas pueden ser muy diversas, además un mismo problema puede tener varias soluciones. Así que veamos sólo algunas consideraciones para enfrentarnos a cuestiones de este tipo:

-Con la información que hemos podido obtener con las herramientas anteriores buscamos el problema en Internet o consultamos en algún foro, pero es importante que hagamos referencia a la distribución GNU/Linux y a la versión de esta en la que se produce el error; también a las características de nuestro equipo, aunque este dato, en ocasiones, me da la impresión que sólo le es útil para el diagnóstico a usuarios muy expertos o profesionales.

-Puede ser que el sistema operativo sea una versión de pruebas o de un lanzamiento reciente y simplemente se trate de un bug, que se podría solucionar con un parche en una actualización posterior. No trajinamos nada y evitamos algún entuerto.

-La versión de la distribución, aunque es estable, es que simplemente es así de lenta ¿Qué le vamos a hacer?. Puede ser buena idea cambiar de distribución si este factor lo consideramos muy importante.

-En otros casos se puede tratar de un servicio que no nos es necesario. Recientemente deshabilité el servicio ModemManager.service porque no lo necesito y demoraba el arranque significativamente (1 min 8.811 s), influyendo negativamente también sobre otros servicios. Esto nunca me había pasado en versiones anteriores de esta distribución. En otra distribución que utilizo simultáneamente de forma rutinaria, el tiempo en cargar este módulo era de 5.175 segundos, y aquí pude optimizar ligeramente el tiempo de arranque del sistema.

-En alguna ocasión puede que lleguemos a la conclusión de que lo que en realidad está ralentizando la carga de una unidad -o varias-, es algo que hemos instalado. Por ejemplo, instalé un splash screen (o pantalla de bienvenida) no oficial, y la unidad display-manager.service se demoraba un montón. La solución no era, obviamente, deshabilitar este servicio sino desinstalar el splash screen no oficial y dejar el oficial. Es posible que la causa no esté simplemente en ese splash screen sino que el hardware de mi equipo, la distribución, el escritorio, etc, también jueguen su papel; en otro equipo distinto es posible que no se produzca tal demora en el arranque.

-Al instalar algunas aplicaciones -como el antivirus ClamAV y ClamTK o los sensores de temperatura de los discos locales (hddtemp)- se puede configurar la activación de demonios para que se carguen durante el arranque. Obviamente, esto consume tiempo por lo que puede ser de interés chequear esta cuestión por si la duración fuese excesiva, que en principio no lo debe ser.

-La solución puede ser específica y concreta del error que produce la demora, y esté en seguir un procedimiento muy distinto a simplemente deshabilitar una unidad, como por ejemplo la que se describe en:

El arranque de mi distribución GNU/Linux se demora y tengo elsiguiente mensaje: A start job is running for dev-disk-by ……device (1 min 30s) …►

6. Gestionar el estado de las unidades gráficamente y mediante terminal

Si la solución pasa por desactivar una unidad podemos hacerlo gráficamente: En Systemd-kcm botón derecho sobre la unidad y picar “desactivar unidad”; y en “Administrador de servicios” de YaST (openSUSE), picar en “Iniciar/Detener” y “Habilitar/Inhabilitar” para que la unidad quede como “Desactivado” e “Inactivo”.

También podemos utilizar la herramienta para terminal systemctl, pero como superusuario (su) o como usuario con privilegios de root (sudo):

# systemctl disable nombre.servicio 

Un ejemplo concreto:

# systemctl diseable ModemManager.service

Con este comando se desactivan aquellos servicios que se inician de forma automática durante el arranque, pero se podrán iniciar de forma manual en una sesión con el comando:

# systemctl start nombre.servicio

Si queremos nuevamente activar el servicio durante el arranque:

# systemctl eneable nombre.servicio

Si simplemente lo tenemos que detener en una sesión:

# systemctl stop nombre.servicio

Si se quiere evitar que un servicio se pueda iniciar -pero con toda la seguridad de que eso va a ser así- se utiliza el siguiente comando:

# systemctl mask nombre.service

Para una información detallada de systemctl, ya sabes en terminal:

# man systemctl

Nota final: Si se nos presentara una demora durante el arranque y no damos con “la tecla” -entre otras razones porque simplemente somos usuarios de escritorio, y tenemos otros muchos asuntos en los que pensar- y, además, el tiempo no es excesivo (incremento de segundos que no de minutos), también lo podemos dejar estar ¿Qué prisa hay?

Saludos flamencos,

Si te interesa el apasionante mundo de las Aves y Otros Seres Vivos … ►