Perfilado del arranque con systemd-analyze en Linux

Si alguna vez has pensado que tu Linux tarda «media vida» en arrancar, o simplemente te pica la curiosidad por saber qué pasa desde que pulsas el botón de encendido hasta que ves tu escritorio, systemd-analyze es la herramienta perfecta para cotillear el arranque de tu sistema. No hace falta ser administrador de sistemas profesional para sacarle partido: con unos cuantos comandos y algo de sentido común puedes entender qué está pasando y, si procede, recortar bastantes segundos al inicio.

En muchos foros y comunidades la gente comparte sus tiempos de arranque como si fueran marcas deportivas, pero más allá del pique sano, medir y entender el proceso de arranque con systemd-analyze es útil para detectar fallos, servicios mal configurados y cuellos de botella. Vamos a ver con calma qué ofrece esta herramienta, cómo interpretar sus resultados y qué cambios tienen sentido para optimizar el arranque sin romper nada importante.

Qué es systemd-analyze y por qué te interesa

systemd-analyze es una utilidad incluida en systemd que sirve para analizar el rendimiento del arranque en sistemas GNU/Linux. La usan distribuciones como Debian, Ubuntu, Fedora, openSUSE, Arch, Manjaro y un largo etcétera, siempre que systemd sea el sistema de inicio.

Con esta herramienta puedes ver tanto una visión global del tiempo de arranque como un desglose muy fino por servicios, dispositivos, sockets y puntos de montaje. Además, permite generar gráficos en formato SVG, ver cadenas críticas de dependencias y obtener datos en otros formatos como JSON o tablas.

Aunque systemd-analyze tiene bastantes opciones, para la mayoría de usuarios son clave unos pocos comandos: time, blame, critical-chain y plot. A partir de ahí ya puedes decidir qué servicios revisar, qué unidades desactivar y qué problemas investigar con más calma.

Repaso rápido del proceso de arranque en un PC Linux

Antes de ponernos a mirar números conviene tener una idea general de las fases del arranque de un ordenador hasta que entra en juego systemd. Esto ayuda mucho a interpretar qué parte del tiempo corresponde al kernel, al initrd o al espacio de usuario que te mostrará systemd-analyze.

Lo primero es el encendido físico: la fuente convierte la corriente alterna en corriente continua adecuada y la placa base reparte voltajes y amperajes entre CPU, RAM, discos, etc. Después entra en juego el famoso firmware, ya sea la BIOS clásica o la UEFI moderna, que vive en una ROM de la placa.

En esta fase de firmware se ejecuta el POST (Power On Self Test), que comprueba memoria, teclado, controladoras, discos y otros dispositivos básicos. Además, ahí se decide el orden de arranque: disco, USB, DVD, red, etc. La configuración «personalizable» se guarda en una pequeña memoria CMOS alimentada por la pila de botón de la placa.

Una vez detectado el dispositivo de arranque, el firmware busca el sector de arranque (MBR o partición EFI) y cede el control al gestor de arranque, que en Linux suele ser GRUB. GRUB carga su configuración (normalmente desde /boot/grub/grub.cfg), muestra el menú (tiempo de espera del menú de arranque) y, cuando eliges sistema y kernel, arranca la siguiente fase.

En ese momento el gestor de arranque carga la imagen del kernel (vmlinuz) y el entorno inicial de arranque, el initramfs, que contiene un «mini-Linux» con lo necesario para detectar discos, módulos y sistema de ficheros raíz. Esa imagen se carga en RAM, monta la raíz definitiva y finalmente ejecuta el proceso init con PID 1.

Hoy día, en la mayoría de distribuciones, ese PID 1 lo ocupa systemd, que se encarga de arrancar servicios, montar sistemas de ficheros, preparar el entorno de usuario y, en último término, lanzar el Display Manager y el escritorio. Es precisamente esta parte, desde que arranca systemd hasta que el sistema está «usable», la que podemos medir con bastante detalle gracias a systemd-analyze.

systemd-analyze time: el tiempo total de arranque

El comando más sencillo y el que suele usarse primero es simplemente:

Ejecuta: systemd-analyze

También puedes usar:

Ejemplo de salida:
Startup finished in 0.912s (kernel) + 0.731s (initrd) + 1.485s (userspace) = 3.129s

Con este resumen, ves directamente cuánto tarda el kernel, cuánto el initrd y cuánto la parte de espacio de usuario gestionada por systemd. En algunas distros (por ejemplo, ciertas Debian/Ubuntu) no aparece initrd separado y su tiempo se suma al kernel.

Este dato general sirve para tener una referencia y para comparar después de hacer cambios. Es bastante común ver sistemas con discos HDD antiguos que se mueven entre 20 y 60 segundos, y sistemas con SSD modernos que rondan los 3-10 segundos, siempre dependiendo de cuántos servicios se carguen.

systemd-analyze blame: quién está retrasando el arranque

Cuando queremos ir al detalle, el siguiente paso lógico es:

Comando: systemd-analyze blame

Con este comando, systemd-analyze muestra una lista de todas las unidades (servicios, montajes, dispositivos, sockets) ordenadas de mayor a menor tiempo de inicialización. Algo como:

5.678s NetworkManager-wait-online.service
3.210s dev-sda1.device
2.345s snapd.service
...

Esta lista es oro para detectar qué está «robando» segundos. Ahora bien, hay que tener cuidado al interpretar el resultado, porque un servicio puede aparecer como lento simplemente porque depende de otro que tarda en estar listo. No siempre el culpable es el que más segundos tiene delante.

Filtrado rápido: Si solo quieres ver los peores, puedes combinarlo con herramientas de filtrado, por ejemplo:

Ejemplo: systemd-analyze blame | head

o en algunas guías se ve escrito inline como «systemd-analyze blame | head -n 10». En cualquier caso, lo habitual es revisar los primeros elementos y preguntarte si realmente necesitas que estén activos o si hay alternativas menos pesadas.

systemd-analyze critical-chain: la cadena crítica del arranque

Otra vista muy interesante es la cadena crítica, que se obtiene con:

Comando: systemd-analyze critical-chain

La salida se presenta como un árbol en el que se ve qué unidades forman el camino más lento hasta el objetivo principal (por defecto el target gráfico o multi-user), mostrando para cada una cuánto tiempo tarda y en qué momento arranca. Por ejemplo:

graphical.target @12.345s
└─multi-user.target @12.345s
└─NetworkManager-wait-online.service @7.000s +5.345s
└─NetworkManager.service @2.000s +1.234s
...

En este tipo de salida, el tiempo que aparece después de «@» indica cuándo se ha alcanzado la unidad, y el que va después de «+» es la duración de su arranque. De nuevo, hay que recordar que por las dependencias y la ejecución en paralelo algunas cifras pueden resultar algo engañosas a primera vista.

Además, existe la opción de llamar a critical-chain indicando una unidad concreta, por ejemplo:

systemd-analyze critical-chain NetworkManager.service

Con esto, obtienes la cadena crítica relacionada con esa unidad concreta, útil cuando estás investigando retrasos de un servicio específico.

systemd-analyze plot: gráfico SVG del arranque

Si prefieres algo más visual, puedes generar un gráfico SVG con:

Ejemplo: systemd-analyze plot > boot_analysis.svg

o nombres similares como imagen.svg, arranque.svg o 0-graficocarga.svg. El fichero SVG generado contiene un gráfico con barras horizontales que representa el tiempo que tarda en iniciarse cada unidad, mostrando también solapamientos y dependencias.

Este gráfico puedes abrirlo con un editor de gráficos vectoriales como Inkscape, con GIMP o simplemente con un navegador web moderno. Es especialmente útil para entender de un vistazo qué parte del arranque está más saturada y dónde podría haber margen para ejecutar cosas en paralelo.

Listar servicios habilitados y otras herramientas relacionadas

Además de systemd-analyze, es habitual complementar el análisis usando systemctl para listar las unidades habilitadas y su estado. Por ejemplo:

Ejemplo: systemctl list-unit-files --state=enabled

Ejemplo: systemctl list-unit-files --type=service | grep enabled

De este modo, puedes localizar servicios que no utilizas (por ejemplo ModemManager, Bluetooth si no lo usas, servicios de correo como Postfix, etc.) y plantearte deshabilitarlos.

Comandos habituales:

• Deshabilitar un servicio para que no arranque con el sistema:
  systemctl disable nombre.service
• Volver a habilitarlo en el arranque:
  systemctl enable nombre.service
• Detenerlo en la sesión actual:
  systemctl stop nombre.service
• Arrancarlo manualmente:
  systemctl start nombre.service
• Enmascararlo para impedir que se inicie de ninguna forma:
  systemctl mask nombre.service

En entornos gráficos también hay herramientas como systemadm (systemd System Manager, del paquete systemd-ui), el módulo systemd-kcm para KDE Plasma o el administrador de servicios de YaST en openSUSE. Permiten ver el estado de las unidades y activar o desactivar servicios sin tocar la consola.

Ver mensajes y errores durante el arranque

Más allá de systemd-analyze, es útil conocer que durante el arranque puedes esconder el «splash» gráfico y ver los mensajes en texto pulsando la tecla de flecha abajo. Ahí suelen aparecer líneas con «OK» en verde y, si algo va mal, mensajes «FAILED» o avisos con contadores de tiempo.

Mensajes típicos:

Ejemplo:
A start job is running for wicked managed network interfaces (x s / no limit)
A start job is running for ModemManager.service (x s / 1min 30s)

indican que systemd está esperando a que una unidad termine de arrancar o alcance un estado determinado, lo que puede causar demoras considerables. Lo normal es luego buscar el nombre de esa unidad con systemd-analyze y systemctl para ver qué está pasando.

Consulta: Una vez ya ha arrancado el sistema, puedes revisar el registro de la última sesión con:

Ejemplo: journalctl -b

y así ver errores, avisos o tiempos anómalos relacionados con servicios concretos.

Ejemplos reales de optimización de arranque

En la práctica, hay usuarios que han pasado de tiempos de arranque cercanos al minuto o incluso más de 40 segundos a cifras muy razonables tras unos cuantos ajustes. En equipos con HDD se ha visto bajada de 40+ segundos a unos 18 simplemente deshabilitando servicios innecesarios y ajustando la gestión de red.

Acciones que han ayudado: Algunos ejemplos reales de acciones que han ayudado a mejorar marcas como «Arranque finalizado en 880ms (kernel) + 750ms (initrd) + 1.148s (espacio de usuario) = 2.780s» son:

• Desactivar NetworkManager-wait-online.service cuando no se necesitan servicios que dependan de la red desde el minuto cero, evitando que el sistema espere a que haya conectividad.
• Cambiar el gestor de red de Wicked a NetworkManager en openSUSE para que parte del trabajo de red se realice más tarde, ya en el escritorio.
• Deshabilitar servicios que no tienen sentido en ese equipo, como btrfsmaintenance si no se usa Btrfs, ModemManager si no hay módem o Postfix si no se envía correo desde root.
• En algunos casos concretos, ajustar el planificador de E/S del disco (mq-deadline, noop/none para NVMe, etc.) y revisar opciones de SSD.

También influyen detalles de configuración como:

• Usar la opción de compresión «cat» en /etc/mkinitcpio.conf (en distribuciones tipo Arch/Manjaro) para crear un initramfs más ligero o más rápido de descomprimir según el hardware.
• Reemplazar el hook udev por systemd en mkinitcpio para que la fase de initrd sea más eficiente con las capacidades de systemd.
• Ajustar parámetros del kernel como libahci.ignore_sss=1 en GRUB para ciertos controladores SATA, siempre que sea recomendable para tu hardware.

En algunos equipos modernos se ha llegado a bajar de 7-8 segundos de arranque iniciales hasta rondar los 3 segundos, sumando pequeños ajustes: deshabilitar servicios, optimizar initramfs y refinar opciones de almacenamiento. Eso sí, nunca conviene copiar configuraciones de otro usuario sin entenderlas, porque lo que a uno le va de lujo a otro le puede romper medio sistema.

Consejos para decidir qué tocar y qué no

Con toda la información que proporcionan systemd-analyze y systemctl, lo normal es que llegues a detectar unidades que parecen provocar demoras. Antes de empezar a deshabilitar cosas como si no hubiera un mañana, conviene buscar información específica sobre el servicio, tu distribución y tu versión concreta.

Pautas: Algunas pautas sensatas son:

• Comprobar si la versión de la distribución está en fase de pruebas o es muy reciente; a veces el problema es simplemente un bug que se corregirá en actualizaciones posteriores.
• Valorar si la lentitud es «normal» en esa distro y en ese hardware; puede que cierto escritorio o cierto conjunto de servicios sea intrínsecamente más pesado.
• Identificar servicios claramente prescindibles en tu caso de uso: ModemManager, demonios de correo, servicios de impresora cuando no tienes impresora, demonios de monitorización que no usas, etc.
• Revisar si algún software extra que hayas instalado arrastra su propio servicio de inicio (p. ej. ClamAV, ClamTK, hddtemp, pantallas de bienvenida personalizadas) y si te compensa que arranque desde el principio.
• Cuando veas demoras asociadas a unidades de disco (mensajes del tipo «A start job is running for dev-disk-by…»), revisar la configuración de fstab o montajes automáticos, porque a veces el problema es un dispositivo que ya no existe o una ruta mal puesta.

En muchos casos la solución no es deshabilitar el servicio, sino corregir la causa subyacente (por ejemplo, una pantalla de bienvenida no oficial que ralentiza el display-manager, o una conexión de red mal configurada que hace que el gestor espere eternamente).

Impacto de servicios de red y VPN en el arranque

En entornos donde el equipo tiene que salir a Internet o a una red privada antes de estar «listo» (ofimática remota, servidores, equipos corporativos), servicios de red y VPN pueden jugar un papel importante en el tiempo de arranque.

Con systemd-analyze blame se ve con claridad si, por ejemplo, NetworkManager-wait-online.service, servicios de VPN como OpenVPN, WireGuard u OpenConnect están introduciendo retrasos significativos. Algunas recomendaciones prácticas son:

• Evitar configuraciones que bloqueen el arranque esperando contraseñas interactivas, por ejemplo, certificados de OpenVPN con passphrase sin ningún agente de claves que los gestione.
• Asegurarte de que los servicios de VPN dependan de network-online-target pero no bloqueen innecesariamente otros servicios que no requieren conectividad inmediata.
• En el caso de WireGuard, mantener las unidades wg-quick@ bien configuradas y sin scripts PostUp/PreDown excesivamente complejos que ralenticen el inicio.
• Para OpenConnect, usar unidades Type=simple bien definidas, evitando cadenas de scripts innecesarios que puedan aumentar el tiempo de arranque.

Todo esto se puede medir fácilmente volviendo a ejecutar systemd-analyze time y blame después de cada cambio, de manera que veas si realmente has ganado algo o solo has movido el problema de sitio.

Aplicaciones gráficas y otras ayudas

Alternativas gráficas: Si no te apetece pelearte siempre con la terminal, hay varias interfaces gráficas que se apoyan en systemd y pueden ayudarte a gestionar el arranque y el estado de las unidades sin escribir tantos comandos.

• Systemadm (systemd System Manager): se instala con el paquete systemd-ui en muchas distros y aparece en el menú como una herramienta de administración del sistema. Permite ver unidades, su estado y activarlas o desactivarlas.
• systemd-kcm: módulo de configuración para KDE Plasma 5 (paquete kde-config-systemd). Se integra en «Preferencias del sistema» > «Administración del sistema» y muestra unidades, tiempos y estados.
• Administrador de servicios de YaST en openSUSE: una interfaz muy potente para ver servicios, habilitarlos, deshabilitarlos y ajustar su comportamiento en el arranque.

Estas herramientas son útiles para usuarios de escritorio que simplemente quieren comprobar qué se está iniciando y desactivar algo puntual sin entrar tanto en el detalle de los archivos .service. Para cambios más finos (por ejemplo, tocar directivas como After=, Wants= o TimeoutStartSec=) sigue siendo recomendable editar o sobreescribir las unidades vía /etc/systemd/system.