El ordenador tarda 15 minutos en arrancar

Objetivo:

Diagnosticar y resolver de forma metódica un problema de rendimiento crítico en el que el equipo o servidor experimenta un tiempo de arranque excesivo (15 minutos), aprendiendo a correlacionar cuellos de botella mediante el análisis de servicios, procesos, estado del disco, registros del sistema y la secuencia de inicialización de systemd. 

Escenario:

  • Herramientas: Terminal Linux, comandos systemd-analyze, systemctl, journalctl, top / htop, y smartctl / iostat.
  • Conceptos analizados: Tiempos de espera (timeouts) de servicios caídos, unidades bloqueadas en el arranque, saturación de E/S de almacenamiento (I/O wait), errores de montaje en /etc/fstab y consumo excesivo de recursos de inicio.
  • Proceso clave: Medición y desglose analítico del tiempo de arranque, identificación de demonios colgados con retardos de timeout, inspección del búfer de errores del kernel y comprobación de la salud física del disco duro.

Escenario Real: Servidor con retardo extremo y bloqueo en la inicialización

Un servidor crítico corporativo tarda exactamente 15 minutos en completar su proceso de arranque tras un reinicio programado. Una vez finalizada la carga, el sistema operativo opera con una lentitud desesperante. Como administrador de sistemas, debes aplicar un proceso de diagnóstico exhaustivo para descubrir qué componente del hardware o qué servicio software está provocando este cuello de botella masivo durante la secuencia de inicio.

Por defecto, los sistemas modernos no muestran los retardos internos en la pantalla de bienvenida. Saber auditar las fases de inicialización mediante las herramientas analíticas de Systemd y el rendimiento del almacenamiento es la única vía profesional para resolver bloqueos de este tipo.

NOTA: Para realizar esta práctica con total seguridad, utilizaremos comandos de consulta e inspección sobre los registros y métricas del sistema, evitando alterar configuraciones críticas antes de identificar la causa raíz.

Instrucciones:

Fase 1: Análisis global del tiempo de arranque (systemd-analyze):

  • Comprobar el tiempo total acumulado por el núcleo y el espacio de usuario en completar el arranque del sistema: systemd-analyze
  • Desglosar y ordenar cronológicamente de mayor a menor el consumo de tiempo de cada servicio individual para detectar cuellos de botella: systemd-analyze blame
  • Analizar el grafo crítico de dependencias para descubrir qué servicio exacto obligó al sistema a esperar durante minutos: systemd-analyze critical-chain

Fase 2: Auditoría de servicios fallidos y unidades bloqueadas por timeout:

  • Listar todas las unidades de systemd que se encuentran en estado de error o que han superado su tiempo máximo de espera: systemctl --failed
  • Comprobar si existen montajes de discos de red (como NFS o CIFS) o particiones secundarias mal configuradas en /etc/fstab que provoquen bloqueos de espera indefinidos al no estar disponibles durante el arranque.
  • Deshabilitar temporalmente aquellos servicios no esenciales que presenten retardos críticos en el inicio: sudo systemctl disable [nombre_servicio]

Fase 3: Inspección de registros del kernel y búfer de inicio (journalctl):

  • Consultar los mensajes de error crítico registrados específicamente durante el arranque actual para identificar advertencias de hardware o fallos de drivers: sudo journalctl -b 0 -p err
  • Inspeccionar el búfer de mensajes del kernel en busca de bloqueos de E/S o problemas de respuesta del controlador de almacenamiento: dmesg -T | grep -iE 'error|timeout|fail|block'

Fase 4: Diagnóstico del rendimiento y salud del almacenamiento (Disco y I/O):

  • Verificar el estado de salud física y los parámetros SMART del disco duro o unidad SSD para descartar fallos mecánicos o de sectores defectuosos: sudo smartctl -H /dev/sda
  • Analizar la carga de E/S y el nivel de espera de disco (iowait) para comprobar si el almacenamiento está saturado: iostat -xz 1 10

Verificación:

  • Comprobar mediante un nuevo reinicio y la ejecución de systemd-analyze que el tiempo total de arranque se ha reducido drásticamente a valores normales (segundos en lugar de 15 minutos).
  • Verificar mediante systemctl --failed que el sistema ya no arrastra unidades colgadas ni servicios en estado de error.

Posibles errores y resolución de problemas:

Si al ejecutar smartctl para comprobar la salud del disco el sistema devuelve un error indicando que command not found, significa que la utilidad de diagnóstico SMART no está instalada en el sistema operativo.

  • Solución: Instala el paquete de utilidades de control de almacenamiento ejecutando en la terminal: sudo apt update && sudo apt install smartmontools -y (o el gestor de paquetes correspondiente a tu distribución).

Alternativa directa: Localización instantánea de servicios lentos

Si necesitas aislar de forma ultra rápida los 5 servicios que más retrasan el arranque del sistema sin volcar listas interminables de dependencias por la pantalla, puedes ejecutar el siguiente comando optimizado:

systemd-analyze blame | head -n 5

Preguntas de reflexión:

  1. ¿Por qué un fallo en el montaje de una unidad de red remota dentro del fichero /etc/fstab puede congelar el arranque de un sistema Linux durante varios minutos?
  2. ¿Qué diferencia técnica existe entre auditar los tiempos muertos con systemd-analyze blame frente a analizar el flujo de dependencias críticas con systemd-analyze critical-chain?
  3. ¿Cómo influye un valor elevado de iowait en el rendimiento general del procesador y en la lentitud extrema de un equipo durante y después del arranque?
  4. ¿Qué relación directa puede existir entre un disco duro con sectores defectuosos (detectados mediante SMART) y un tiempo de arranque excesivamente prolongado?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué un fallo en el montaje de una unidad de red remota dentro del fichero /etc/fstab puede congelar el arranque de un sistema Linux durante varios minutos?

Porque por defecto el sistema operativo intenta montar las particiones y recursos declarados en /etc/fstab de forma síncrona durante las fases iniciales. Si la red remota no está accesible, el servicio de montaje espera de forma indefinida hasta agotar un tiempo de espera (timeout) muy elevado antes de permitir que el arranque continúe, provocando una demora masiva.

2. ¿Qué diferencia técnica existe entre auditar los tiempos muertos con systemd-analyze blame frente a analizar el flujo de dependencias críticas con systemd-analyze critical-chain?

El comando systemd-analyze blame enumera de forma aislada cuánto tiempo total ha consumido cada servicio individual desde el inicio. Por el contrario, systemd-analyze critical-chain muestra el camino crítico de dependencias en cadena; es decir, qué servicios se han tenido que ejecutar obligatoriamente de forma secuencial retrasando el tiempo real del reloj de arranque.

3. ¿Cómo influye un valor elevado de iowait en el rendimiento general del procesador y en la lentitud extrema de un equipo durante y después del arranque?

El indicador iowait representa el porcentaje de tiempo que la CPU permanece inactiva esperando obligatoriamente a que finalicen las operaciones de lectura o escritura en el almacenamiento secundario. Un valor alto indica que el disco es extremadamente lento o está saturado, provocando que la CPU se quede bloqueada sin poder procesar tareas aunque su uso de cálculo puro parezca bajo.

4. ¿Qué relación directa puede existir entre un disco duro con sectores defectuosos (detectados mediante SMART) y un tiempo de arranque excesivamente prolongado?

Cuando un disco duro físico presenta sectores deteriorados o problemas de lectura en los bloques donde se ubican los ficheros del sistema operativo o los registros de inicio, el controlador de almacenamiento y el kernel realizan múltiples reintentos automáticos (retries) y operaciones de recuperación de errores a bajo nivel, ralentizando de forma drástica la velocidad de lectura y congelando la secuencia de arranque.