La utilidad systemd-analyze, integrada en distribuciones Linux que usan el sistema init systemd, permite a los usuarios identificar rápidamente las causas de procesos de arranque lentos. Ejecutando comandos simples, desglosa los tiempos de arranque en componentes del kernel y userspace, y resalta los servicios que causan demoras. Esta herramienta ayuda a los administradores a realizar ajustes dirigidos para mejorar las velocidades de inicio sin adivinanzas.
Los usuarios de Linux que experimentan tiempos de arranque lentos en distribuciones basadas en systemd, como Ubuntu o Fedora, pueden recurrir a la herramienta integrada systemd-analyze para un diagnóstico rápido. Como se describe en guías técnicas, la herramienta analiza la secuencia de inicialización gestionada por systemd, informando sobre las duraciones de etapas como firmware, cargador de arranque, kernel y userspace. Ejecutar el comando básico systemd-analyze proporciona un resumen del tiempo total de arranque. Por ejemplo, un caso muestra el inicio finalizando en 6.669 segundos para el kernel más 30.368 segundos para userspace, totalizando 37.037 segundos, con el objetivo gráfico alcanzado después de 27.479 segundos en userspace. Una versión compacta, systemd-analyze time, ofrece desgloses similares, revelando a menudo el userspace como el principal cuello de botella en sistemas SSD. La opción blame lista las unidades de systemd por tiempo de inicialización, de mayor a menor. Las demoras comunes provienen de servicios como apt-daily.service (57.158 segundos en un caso), que maneja las comprobaciones diarias de actualizaciones en sistemas basados en Debian; snapd.service (17.609 segundos); y docker.service (10.647 segundos). Las guías recomiendan revisar esta lista para identificar servicios desactivables, como posponer entornos de contenedores como Docker si no son necesarios de inmediato, advirtiendo contra la desactivación de tareas esenciales como las actualizaciones automáticas. Para una visión más profunda, systemd-analyze critical-chain rastrea la ruta de dependencias que retrasa el objetivo predeterminado. Una salida podría mostrar graphical.target esperando a multi-user.target, que a su vez depende de docker.service (iniciando en 16.830 segundos y tomando 10.647 segundos). Esto revela cuellos de botella, como servicios de espera de red o montajes mal configurados que causan tiempos de espera de 30-90 segundos. Finalmente, systemd-analyze plot > boot.svg genera una línea de tiempo visual SVG del proceso de arranque, ilustrando dependencias paralelas y seriales. Abrir el archivo en un navegador resalta unidades de inicio tardío, como las que aparecen alrededor de 18 segundos en visuales de muestra. Los administradores reportan ganancias significativas, incluyendo reducciones del 20-40% en el tiempo de userspace en sistemas SSD, aplicando cambios como reprogramar temporizadores o eliminar paquetes innecesarios como cloud-init en configuraciones no en la nube. Estas modificaciones deben documentarse para su reversibilidad, asegurando la fiabilidad del sistema.
