Si tu máquina Linux tarda más de lo esperado en iniciar, no hace falta adivinar qué falla: el propio sistema proporciona herramientas para investigar. systemd-analyze forma parte del conjunto de utilidades del init systemd y ofrece formas claras de medir el tiempo total de arranque, identificar servicios lentos y visualizar dependencias. Con unos comandos sencillos puedes sacar un panorama completo del proceso de inicio y decidir intervenciones seguras sin tocar archivos de sistema de forma imprudente.
Esta guía muestra los pasos prácticos y las precauciones para mejorar el rendimiento del arranque en servidores y escritorios.
Antes de hacer cambios drásticos conviene entender la salida básica. Ejecutando systemd-analyze se obtiene el tiempo dividido entre kernel y userspace, y la marca cuando se alcanza el objetivo gráfico o multiusuario. Esa lectura inicial permite saber si el retraso está en el arranque del propio núcleo, en la inicialización de servicios o en la fase previa al gestor de sesiones.
A partir de ahí se usan opciones más detalladas para localizar los cuellos de botella y diseñar una respuesta que mantenga la estabilidad del sistema.
Cómo inspeccionar tiempos de arranque
La medición primaria con systemd-analyze time separa el tiempo gastado por el kernel y por el userspace, lo que ayuda a priorizar la investigación. Si la mayor parte del tiempo está en userspace, la causa suele ser un servicio o un temporizador que se ejecuta al inicio.
Si el retraso aparece en la parte del kernel, conviene revisar controladores, oportunidades de paralelización y configuración de initramfs. Tener este diagnóstico inicial evita alterar servicios innecesariamente y permite enfocar el uso de comandos como systemd-analyze blame y systemd-analyze critical-chain para obtener detalles precisos.
Herramientas de diagnóstico
Blame: lista de servicios lentos
La opción systemd-analyze blame enumera las unidades por tiempo de inicio, de mayor a menor, y señala rápidamente los objetivos con mejor potencial de mejora.
Servicios como apt-daily.service, snapd.service, docker.service o containerd.service suelen aparecer en servidores y equipos de escritorio cuando realizan tareas pesadas al inicio. Esa lista no es una sentencia: antes de desactivar una unidad hay que entender su función. Por ejemplo, apt-daily.service comprueba actualizaciones y puede posponerse en servidores donde se controlen los upgrades. Usar la salida de blame facilita decidir si deshabilitar, enmascarar o reprogramar un servicio.
Critical-chain y plot: dependencia y visualización
Con systemd-analyze critical-chain se ve la cadena de dependencias que determina el tiempo hasta alcanzar un objetivo como graphical.target o multi-user.target. La salida muestra cuándo cada unidad se activa y cuánto tardó, lo que ayuda a localizar bloqueos en la secuencia. Para una visión gráfica, systemd-analyze plot > boot.svg genera un archivo svg que representa la línea temporal de arranque, útil para explorar solapamientos y picos de actividad. Abrir ese svg en un navegador revela dónde se concentran los inicios y facilita la planificación de retrasos o dependencias alternativas.
Estrategias para acelerar y endurecer servicios
Desactivar, enmascarar y posponer servicios
Acciones rápidas y seguras incluyen systemctl disable o systemctl mask para unidades innecesarias en servidores, como temporizadores de actualización automática o servicios de snapd en entornos que no usan snaps. Para cargas pesadas que no requieren inicio inmediato se puede posponer el arranque con dependencias o añadir After= en un archivo de override mediante systemctl edit. En entornos con red estática conviene evaluar NetworkManager-wait-online.service, y en sistemas sin interfaz gráfica se puede ignorar plymouth. Estas decisiones ofrecen mejoras de tiempo de arranque sin comprometer la funcionalidad esencial.
Hardening y activación por socket
Además del rendimiento, systemd facilita restringir y endurecer servicios. systemd-analyze security devuelve una puntuación de exposición y recomendaciones para aplicar en un drop-in sin modificar la unidad original. Configuraciones como NoNewPrivileges=yes, PrivateTmp=yes y límites de memoria/CPU ayudan a contener procesos. También es posible usar socket activation para que binarios como nginx permanezcan detenidos hasta la primera solicitud, reduciendo huella de memoria. Combinar optimización de arranque y hardening convierte al arranque en un proceso más rápido y seguro.
En resumen, dominar systemd-analyze, systemctl y las técnicas de mascarado, posposición y drop-ins permite reducir tiempos de inicio sin romper servicios. Empieza por medir con time, identificar con blame y trazar con critical-chain y plot, luego aplica cambios incrementales y validados. Mantener registros con journalctl y probar cada cambio en un entorno controlado es la mejor práctica para acelerar arranques sin poner en riesgo la estabilidad.
