Linux: Tu servidor se reinicia al azar — La pista de registros que estás ignorando

Qué significa realmente “reinicio aleatorio” (y por qué rara vez es aleatorio)

Decir que un host Linux “se reinició al azar” es contar una historia. Tu trabajo es convertirla en una línea temporal con causa. La mayoría de los reinicios entran en unos cuantos grupos:

• Reinicio ordenado: alguien o algo ejecutó reboot, shutdown o inició un flujo de actualización del kernel.
• Reinicio por fallo: kernel panic, BUG, bloqueo o watchdog; a veces con kdump, a veces sin él.
• Evento de energía: fallo de PSU, disparo de PDU, reinicio de BMC/firmware, reinicio del hipervisor o una “manipulación remota” bien intencionada.
• Acción del controlador de gestión: ciclo de energía por IPMI, política de iDRAC/iLO o remediación automatizada.
• Evento de virtualización: host reiniciado, VM reiniciada, migración en vivo fallida o cadena de snapshots descontrolada.

El error principal: tratar el “reinicio” como un único evento. Son dos eventos: el final de un arranque (el fallo) y el inicio del siguiente (la recuperación). Linux registra ambos, pero no en el mismo sitio ni con la misma honestidad.

Una cita para tener en el escritorio: «idea parafraseada» — W. Edwards Deming: sin medición, estás mayormente adivinando. En los reinicios, la “medición” son tus registros, los registros de firmware y los volcados de crash. Si no los tienes, estás adivinando.

Guía rápida de diagnóstico (primero/segundo/tercero)

Primero: establece el tipo de reinicio en 5 minutos

1. ¿Fue ordenado? Revisa el journal de systemd para una secuencia de apagado y las líneas de razón de “reboot”.
2. ¿Fue un fallo? Busca panic/oops/watchdog y si los registros se interrumpen abruptamente.
3. ¿Fue por energía? Compara los registros del SO con los registros SEL del BMC y los eventos del hipervisor. La ausencia de logs de apagado del SO a menudo significa que el SO no tuvo voto.

Segundo: decide qué rastro es el autorizado

• Servidor físico: BMC SEL + registros del kernel + MCE son los más fiables.
• VM: eventos del hipervisor + journal del invitado + errores del disco virtual.
• Instancia en la nube: historial de reinicios del proveedor + registros de consola serial + journal del invitado.

Tercero: aisla el dominio del fallo

• Cómputo: MCE, bloqueos, estrangulamiento térmico, microcode, watchdog.
• Memoria: tormentas de ECC corregidas, fallos de DIMM, memoria “poison”, rarezas NUMA.
• Almacenamiento: reinicio del controlador NVMe, resets de enlace SATA, abortos de ext4/xfs, flapping de multipath, timeouts de firmware.
• Red: resets de firmware de NIC que pueden bloquear el kernel en drivers, especialmente bajo carga.
• Energía: PSU, PDU, UPS, mantenimiento del centro de datos, cable suelto (sí, todavía).

Regla rápida: si el journal termina a mitad de frase, sospecha pérdida de energía o reset duro. Si contiene una secuencia de apagado limpia, sospecha humanos, automatización o un panic con política de reinicio.

Broma #1: Un “reinicio aleatorio” es como un truco de mago—la distracción funciona hasta que revisas la otra mano (IPMI SEL).

Mapa de fuentes de registros: quién sabe qué, y cuándo

1) systemd-journald: la narrativa, con notas al pie

En la mayoría de las distribuciones modernas, journald es tu línea temporal principal. Etiqueta entradas por boot ID, puede mostrar el arranque anterior y a menudo captura mensajes del kernel también. Pero no es magia: si la máquina pierde energía, el journal puede no vaciarse. Esa ausencia es, en sí, evidencia.

2) Kernel ring buffer (dmesg): el audio de la escena del crimen

dmesg muestra el ring buffer del kernel. Es útil para problemas de drivers, resets de enlace de almacenamiento y trazas de panic. Pero después de un reinicio, dmesg muestra este arranque a menos que uses registros del kernel respaldados por el journal del arranque anterior.

3) /var/log/wtmp (last) y /var/log/btmp: el libro de visitas

last puede decirte cuándo se realizó un boot y quién inició sesión. Es tosco, pero rápido, y sobrevive a mucho caos. Si wtmp falta, rota mal o está corrupto, eso es otra pista.

4) BMC / IPMI SEL: el diario del hardware

Los controladores de gestión de servidores mantienen un System Event Log (SEL): ciclos de energía, watchdog, eventos térmicos, irregularidades de voltaje. Este es el registro que el SO no puede falsificar. Si SEL dice “Power Unit lost AC”, deja de discutir con él.

5) Crash dumps (kdump): la autopsia

Si tienes kdump configurado, un fallo del kernel puede dejar un vmcore. Eso no es solo agradable: es la diferencia entre “quizá un driver” y “aquí está el stack y los locks exactos”.

6) Registros de la capa de almacenamiento: donde los reinicios se hacen pasar por problemas de aplicación

Los errores de almacenamiento a menudo preceden a reinicios de una forma que la gente pasa por alto. Resets de NVMe, timeouts SCSI, abortos de journaling ext4 y fallos de firmware del controlador pueden bloquear el sistema hasta que el watchdog lo reinicie. Si tus logs contienen largos bloqueos de I/O antes del reinicio, tu reinicio probablemente fue una historia de almacenamiento disfrazada de kernel.

Tareas prácticas: comandos, salidas, decisiones (12+)

A continuación hay tareas prácticas que puedes ejecutar en un sistema real. Para cada una: qué ejecutar, qué significa la salida y qué decisión tomar a partir de ella. Ejecútalas aproximadamente en este orden cuando estés bajo presión.

Task 1: Confirmar tiempos de reinicio y recuento aproximado

cr0x@server:~$ uptime
 10:18:02 up 1 day,  2:41,  2 users,  load average: 0.54, 0.62, 0.70

Significado: Esto solo te indica el último tiempo de arranque. No el porqué.

Decisión: Si uptime es inesperadamente bajo, necesitas los registros del arranque previo (-b -1) inmediatamente.

Task 2: Usar wtmp para ver reinicios y apagados

cr0x@server:~$ last -x | head -n 12
reboot   system boot  6.8.0-41-generic Mon Feb  3 07:36   still running
shutdown system down  6.8.0-41-generic Mon Feb  3 07:35 - 07:36  (00:01)
reboot   system boot  6.8.0-41-generic Sun Feb  2 22:11 - 07:35  (09:24)
crash    system down  6.8.0-41-generic Sun Feb  2 22:10 - 22:11  (00:01)

Significado: “shutdown” indica un apagado ordenado registrado por init/systemd. “crash” puede mostrar una parada no limpia.

Decisión: Si no hay un “shutdown” antes de un “reboot”, sospecha pérdida de energía, botón de reset, ciclo de energía por BMC o colgado duro.

Task 3: Buscar pistas de la razón del reinicio en el journal del arranque anterior

cr0x@server:~$ journalctl -b -1 -p warning --no-pager | tail -n 30
Feb 02 22:09:44 server kernel: nvme nvme0: I/O 987 QID 5 timeout, aborting
Feb 02 22:09:45 server kernel: nvme nvme0: Abort status: 0x371
Feb 02 22:09:49 server kernel: INFO: task kworker/u64:2 blocked for more than 120 seconds.
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: Kernel panic - not syncing: softlockup: hung tasks

Significado: Clásico: timeouts de almacenamiento → tareas del kernel bloqueadas → watchdog lockup → panic.

Decisión: Deja de perseguir “panic de kernel aleatorio”. Trata la ruta de almacenamiento/NVMe como sospechosa primaria.

Task 4: Comprobar si el journal es persistente (crítico para post-mortems)

cr0x@server:~$ grep -R "^[# ]*Storage=" /etc/systemd/journald.conf
#Storage=auto

Significado: auto usa almacenamiento persistente si /var/log/journal existe; de lo contrario, es volátil.

Decisión: Si no tienes /var/log/journal, créalo y reinicia journald. Sin persistencia, los fallos parecen “misteriosos” porque tiraste el pasado.

Task 5: Listar arranques y alinear la línea temporal

cr0x@server:~$ journalctl --list-boots | head
-2 2c6c0a2a0b1f4cc2b4e0a3f57a8d8f55 Sun 2026-02-02 12:01:17 UTC—Sun 2026-02-02 22:11:01 UTC
-1 91f5d1f5e72a4a00b2b0c2b3f9edaa4c Sun 2026-02-02 22:11:10 UTC—Mon 2026-02-03 07:36:01 UTC
 0 7bb2c1fdc77a4c1e9c3ce2c1b6a11e0b Mon 2026-02-03 07:36:10 UTC—Mon 2026-02-03 10:18:20 UTC

Significado: Los Boot IDs te permiten pivotar con precisión y comparar “fin del boot -1” con “inicio del boot 0”.

Decisión: Identifica el arranque que terminó mal e inspecciona los últimos 5 minutos de ese boot y los primeros 2 minutos del siguiente.

Task 6: Extraer los últimos minutos del arranque previo (donde está el cadáver)

cr0x@server:~$ journalctl -b -1 --since "10 min before shutdown" --no-pager | tail -n 80
Feb 02 22:09:41 server systemd[1]: Started Daily apt download activities.
Feb 02 22:09:44 server kernel: nvme nvme0: I/O 987 QID 5 timeout, aborting
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: Kernel panic - not syncing: softlockup: hung tasks
Feb 02 22:10:13 server kernel: Rebooting in 5 seconds..

Significado: Si ves “Rebooting in 5 seconds,” el kernel eligió reiniciar (comportamiento por panic). Si el registro se corta abruptamente, no fue así.

Decisión: El panic implica una vía de fallo; inicia comprobaciones de kdump y triage de drivers/firmware.

Task 7: Buscar solicitudes explícitas de apagado/reinicio (humanos y automatización)

cr0x@server:~$ journalctl -b -1 -u systemd-logind --no-pager | grep -E "Power key|reboot|shutdown" | tail -n 20
Feb 02 22:07:03 server systemd-logind[933]: Power key pressed short.
Feb 02 22:07:03 server systemd-logind[933]: System is rebooting.

Significado: Alguien presionó el botón de encendido (o el chasis/BMC envió el evento).

Decisión: Correlaciona con registros de acceso físico, sesiones BMC y SEL. No acuses al kernel de lo que hizo una mano.

Task 8: Comprobar resets por watchdog (hardware o software)

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -i watchdog | tail -n 30
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: NMI watchdog: Watchdog detected hard LOCKUP on cpu 7

Significado: Los mensajes de watchdog indican estancamientos prolongados de CPU. A menudo causados por deadlocks de drivers, tormentas de interrupciones o bloqueos de I/O que impiden que los hilos del kernel progresen.

Decisión: Si el watchdog está involucrado, busca el estancamiento ascendente (timeouts de almacenamiento, resets de NIC, bugs conocidos del kernel) en lugar de tratar el watchdog como la causa.

Task 9: Comprobar Machine Check Exceptions (MCE) y señales ECC de memoria

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -iE "mce|machine check|hardware error" | tail -n 40
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 8: b200000000070005
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: PROCESSOR 2:a20f12 TIME 1706911701 SOCKET 0 APIC 0 microcode 0x2f

Significado: Los errores de hardware pueden ser corregidos (sin reinicio) o fatales (panic/reset). Errores corregidos repetidos siguen siendo accionables; son la “luz de revisión”.

Decisión: Si hay MCE cerca del reinicio, involucra al proveedor/soporte de hardware y comprueba la salud de DIMM/CPU/VRM. No “parchee” la física.

Task 10: En servidores físicos, leer IPMI SEL para eventos de energía y térmicos

cr0x@server:~$ ipmitool sel list | tail -n 12
2a0 | 02/02/2026 | 22:09:58 | Power Unit #0x01 | Power lost | Asserted
2a1 | 02/02/2026 | 22:10:02 | Power Unit #0x01 | Power restored | Asserted
2a2 | 02/02/2026 | 22:10:05 | System Event | System Boot Initiated | Asserted

Significado: SEL confirma un evento de AC/energía. Los logs del SO pueden parecer un fallo porque terminaron abruptamente, pero la causa real fue “no había electricidad”.

Decisión: Escala a facilities/cadena de energía (PDU/UPS), comprueba PSUs redundantes e inspecciona los logs de cambios del datacenter. Depurar el kernel es perder tiempo aquí.

Task 11: Ver si kdump capturó un vmcore

cr0x@server:~$ ls -lh /var/crash
total 2.1G
drwxr-xr-x 2 root root 4.0K Feb  2 22:10 127.0.1.1-2026-02-02-22:10:14
-rw------- 1 root root 2.1G Feb  2 22:12 vmcore
-rw-r--r-- 1 root root  18K Feb  2 22:12 vmcore-dmesg.txt

Significado: Tienes un volcado de crash. Esto es oro: puedes identificar el hilo que falló, locks y módulos implicados.

Decisión: Presérvalo (cópialo fuera del host) y luego analízalo con herramientas crash (o entrégalo al soporte del kernel). No reinicies cinco veces más y sobrescribas la evidencia.

Task 12: Detectar OOM killer y eventos de presión de memoria

cr0x@server:~$ journalctl -b -1 -k --no-pager | grep -iE "oom-killer|Out of memory|Killed process" | tail -n 30
Feb 02 21:58:34 server kernel: Out of memory: Killed process 24891 (java) total-vm:18742000kB, anon-rss:14230000kB
Feb 02 21:58:34 server kernel: oom_reaper: reaped process 24891 (java), now anon-rss:0kB, file-rss:0kB

Significado: OOM killer por sí solo no es un reinicio, pero puede desencadenar resets de watchdog si mueren daemons críticos o si el sistema entra en thrashing.

Decisión: Si OOM precede al reinicio, corrige límites de memoria, cgroups, ajustes de overcommit y estrategia de swap. También verifica si un watchdog externo reinició tras la muerte de un servicio.

Task 13: Comprobar errores de sistema de archivos que pueden forzar remount-ro o bloqueos

cr0x@server:~$ journalctl -b -1 -k --no-pager | grep -iE "EXT4-fs error|XFS.*corruption|Buffer I/O error|blk_update_request" | tail -n 40
Feb 02 22:09:31 server kernel: blk_update_request: I/O error, dev nvme0n1, sector 2039488 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Feb 02 22:09:33 server kernel: EXT4-fs error (device nvme0n1p2): ext4_find_entry:1539: inode #2: comm systemd: reading directory lblock 0
Feb 02 22:09:33 server kernel: EXT4-fs (nvme0n1p2): Remounting filesystem read-only

Significado: Errores de almacenamiento subieron a errores de sistema de archivos. Remontar en solo-lectura puede causar fallos de servicios, luego watchdog u orquestación pueden reiniciar.

Decisión: Trátalo como incidente de fiabilidad de almacenamiento. Ejecuta SMART/NVMe health, revisa firmware del controlador y programa fsck donde corresponda.

Task 14: Comprobar salud NVMe y registro de errores (precursor común de reinicios)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | sed -n '1,25p'
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 47 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 4%
media_errors                        : 12
num_err_log_entries                 : 98
warning_temp_time                   : 0
critical_comp_time                  : 0

Significado: Media errors y un número creciente de err_log_entries se correlacionan fuertemente con timeouts y resets de controlador.

Decisión: Si media_errors y err_log_entries son no triviales y están aumentando, planifica reemplazo del disco y verifica compatibilidad de firmware. No esperes a que “empeore”. Empeorará.

Task 15: Comprobar resets de enlace SATA/SAS (si no es NVMe)

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -iE "link is slow to respond|hard resetting link|SATA link down" | tail -n 50
Feb 02 22:08:58 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Feb 02 22:08:59 server kernel: ata3: hard resetting link
Feb 02 22:09:05 server kernel: ata3: link is slow to respond, please be patient (ready=0)

Significado: El enlace de almacenamiento es inestable. Eso puede congelar I/O y desencadenar bloqueos en cascada.

Decisión: Inspecciona cableado/backplane/firmware del HBA. No es una situación de “reinstalar el SO”.

Task 16: Comprobar si el tiempo saltó o hubo problemas RTC (puede romper el razonamiento temporal)

cr0x@server:~$ journalctl -b -1 --no-pager | grep -iE "Time has been changed|System clock time|rtc" | tail -n 20
Feb 02 22:11:12 server systemd-timesyncd[612]: System clock time unset or jumped backwards, restoring from recorded timestamp: 2026-02-02 22:11:11 UTC

Significado: Saltos de tiempo pueden hacer que los reinicios parezcan ocurrir antes/después, arruinando la correlación con BMC o logs del hipervisor.

Decisión: Arregla la sincronización de tiempo (NTP/chrony), revisa la batería RTC/firmware y ten cautela al alinear eventos entre sistemas.

Task 17: Confirmar paquetes/kernel instalados alrededor de la ventana de reinicio

cr0x@server:~$ journalctl -b -1 --no-pager | grep -iE "apt|dnf|yum|transaction|linux-image|kernel" | tail -n 30
Feb 02 22:05:02 server unattended-upgrades[21122]: Installing: linux-image-6.8.0-41-generic
Feb 02 22:05:48 server unattended-upgrades[21122]: Packages that will be upgraded: linux-image-generic

Significado: Una actualización del kernel puede disparar flujos de reinicio (directa o vía orquestación), o introducir una regresión.

Decisión: Si el reinicio se alinea con actualizaciones, valida políticas de reinicio y considera fijar/retroceder versiones del kernel en un subconjunto canario si ves crashes nuevos.

Tres historias corporativas desde las trincheras de reinicios

Mini-historia 1: El incidente provocado por una suposición equivocada

Tenían un clúster de servidores físicos de base de datos. Un nuevo ingeniero on-call vio “Kernel panic” en los logs del arranque previo e hizo lo que mucha gente hace bajo estrés: culpó al kernel y empezó a planear un rollback de actualizaciones.

Era una narrativa confiada. Demasiado confiada. El journal terminó abruptamente unos segundos después de la línea de panic, y no hubo una secuencia de apagado limpia. Suponían que eso significaba que el panic era la causa y el reinicio el efecto.

Alguien finalmente ejecutó ipmitool sel list. El SEL mostró pérdida y restauración de energía—dos veces—en el mismo minuto. ¿La línea de kernel panic? Era de una prueba anterior donde se había habilitado panic-on-oops temporalmente y nunca se revirtió. El “reinicio aleatorio” fue un evento de energía. La línea de panic era ruido de fondo que casualmente quedó cerca en el tiempo.

La causa raíz real estaba aguas arriba: un relé defectuoso en una salida de PDU. La configuración de PSU redundantes del servidor era correcta, pero ambas PSU estaban conectadas al mismo bank de PDU “por ahora” durante un mantenimiento meses antes. Nadie actualizó la documentación. Todos cambiaron de opinión.

Arreglar la PDU y redistribuir las fuentes de energía detuvo los reinicios de inmediato. Hacer rollback del kernel habría sido teatro—reconfortante, visible y equivocado.

Mini-historia 2: La optimización que salió mal

Un equipo persiguió la latencia. Afinaron para rendimiento: ajustes agresivos de C-state de CPU en BIOS, deshabilitaron funciones de ahorro de energía y subieron coalescencia de interrupciones en NICs. Los benchmarks mejoraron, los gráficos se vieron mejor y el cambio fue aprobado porque “solo era tuning de rendimiento”.

Dos semanas después, empezaron reinicios esporádicos. No tan frecuentes como para ser obvios. Suficientes para destruir la confianza. La sospecha inicial recayó en la aplicación, como siempre. Luego en el kernel. Luego en el almacenamiento. Luego en la red. La habitual carrera de culpas.

El problema real: la afinación aumentó la sensibilidad a un bug de firmware en la ruta de watchdog/gestión térmica de la plataforma. Bajo patrones de carga específicos, el BMC interpretaba mal el sondeo retrasado de sensores como un cuelgue y emitía un reset. Los logs del SO parecían limpios—no hubo apagado—porque el SO nunca recibió el aviso. El SEL mostraba resets por watchdog, pero nadie estaba recopilando SEL centralmente.

Revirtieron la afinación de BIOS y actualizaron el firmware del BMC. Los reinicios se detuvieron. El rendimiento bajó un poco. La estabilidad volvió dramáticamente. La lección no fue “nunca optimizar”. Fue “trata firmware y gestión de energía como dependencias de producción, no como un lugar para hacer cosplay de ingeniero de hardware”.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización tenía un hábito que parecía dolorosamente aburrido: almacenamiento persistente de journald, kdump habilitado en todos los nodos bare-metal y un job nocturno que raspaba el SEL de IPMI a un sistema central. Nada heroico. “Lo haremos después del próximo sprint” no existía. Ya estaba hecho.

Cuando una flota empezó a reiniciarse bajo carga pico, la primera llamada de incidente fue tranquila. Ejecutaron journalctl -b -1 en unos cuantos nodos y vieron patrones consistentes de timeout NVMe. Luego comprobaron SEL: sin eventos de energía. Luego revisaron volcados de crash: un subconjunto tenía vmcores con stacks apuntando a la ruta de recuperación del driver NVMe.

Eso acotó el blast radius a “firmware/driver de almacenamiento bajo carga”. Coordinaron una actualización de firmware escalonada y redujeron temporalmente la profundidad de cola en nodos afectados. Sin adivinaciones. Sin conocimiento tribal. Solo evidencia.

El resultado no fue una disponibilidad mágica. Fue un incidente contenido: menos reinicios sorpresa, una escalada clara al proveedor y una traza documental que justificó la ventana de mantenimiento. Las prácticas aburridas no previenen todo fallo. Previenen el segundo fallo: no entender qué pasó.

Broma #2: Si no guardas logs de forma persistente, tu servidor se reiniciará con la confianza de un gato tirando un vaso de la mesa—sin remordimientos, sin explicación.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “No hay registros que muestren el reinicio”

Causa raíz: Journal volátil (sin almacenamiento persistente) o pérdida de energía/reset duro que impidió el vaciado de logs.

Solución: Habilita journald persistente (/var/log/journal), incrementa la frecuencia de flush del journal si procede y recopila SEL del BMC/logs del hipervisor para cubrir casos de energía/reset.

2) Síntoma: “Siempre se reinicia con carga de I/O”

Causa raíz: Timeouts de almacenamiento (resets de controlador NVMe, problemas de firmware HBA, inestabilidad de multipath) que causan tareas bloqueadas y watchdog/panic.

Solución: Inspecciona logs del kernel por timeouts, revisa SMART/NVMe error logs, valida versiones de firmware, reduce profundidad de cola como mitigación y programa reemplazo de hardware cuando los contadores de error suban.

3) Síntoma: “Kernel panic en logs, así que es definitivamente un bug del kernel”

Causa raíz: Causalidad incorrecta. El panic puede ser secundario a errores de hardware o reset forzado; a veces panic-on-oops está activado, convirtiendo fallos menores de drivers en reinicios.

Solución: Confirma con SEL y MCE; revisa /proc/sys/kernel/panic y ajustes panic-on-oops; captura vmcore y analiza stacks.

4) Síntoma: “Los reinicios ocurren después de actualizaciones pero no inmediatamente”

Causa raíz: Regresión de kernel/driver que solo se dispara con una carga específica; o automatización que reinicia según un cron tras parchear.

Solución: Correlaciona timestamps de actualización con boot IDs; revisa logs de orquestación; haz rollback del kernel en un subconjunto canario y compara estabilidad.

5) Síntoma: “La VM se reinicia pero los logs del invitado están limpios”

Causa raíz: Reset del hipervisor, crash del host o acción de power-cycle en la VM. El invitado nunca vio un apagado.

Solución: Usa logs de eventos del hipervisor y audit logs del plano de gestión; trátalo como incidente de infraestructura, no del SO invitado.

6) Síntoma: “Sistema de archivos remontado en solo-lectura antes del reinicio”

Causa raíz: Errores de dispositivo de bloque subyacente; el sistema de archivos se protegió, los servicios fallaron y luego watchdog u orquestación reiniciaron para “sanear”.

Solución: Diagnostica la capa de bloque (SMART/NVMe, cableado, controlador), ejecuta comprobaciones del sistema de archivos en mantenimiento y arregla el problema de fiabilidad de almacenamiento primero.

7) Síntoma: “Nada obvio, pero SEL muestra resets por watchdog”

Causa raíz: Watchdog hardware activado por colgado del sistema, a menudo por deadlock de driver, tormenta de interrupciones o problemas de firmware.

Solución: Actualiza BIOS/BMC/microcode; revisa versiones de kernel por bugs de lockup conocidos; habilita kdump; considera ajustar NMI watchdog solo después de entender la causa raíz.

8) Síntoma: “Aparecen OOM kills antes del reinicio”

Causa raíz: Agotamiento de memoria que desencadena fallos en cascada; un watchdog externo u orquestación reinicia el nodo tras la caída de servicios.

Solución: Implementa límites de memoria (cgroups), dimensiona correctamente instancias, agrega swap con cuidado y ajusta OOM scoring para servicios críticos.

Listas de verificación / plan paso a paso

Paso a paso: investigación de un solo host (30–60 minutos)

1. Confirma recuento y tiempos de arranque: last -x, journalctl --list-boots.
2. Inspecciona el final del arranque previo: journalctl -b -1 con -p warning primero, luego contexto completo.
3. Clasifica el reinicio: ordenado vs abrupto (presencia de secuencia de apagado, o corte de logs).
4. Revisa el kernel por panic/oops/watchdog: grep de “panic”, “oops”, “watchdog”, “blocked for more than”.
5. Revisa señales de hardware: líneas MCE; si es físico, eventos SEL para energía/térmico/watchdog.
6. Revisa almacenamiento: timeouts, resets, errores de sistema de archivos, datos SMART/NVMe.
7. Revisa presión de memoria: líneas OOM killer; actividad de swap si está registrada.
8. Revisa cambios: actualizaciones, ejecuciones de config management, cambios de firmware, tareas programadas alrededor del evento.
9. Decide acción siguiente: mitigar (reducir carga, sacar nodo de servicio), preservar evidencia (vmcore/logs), escalar (hardware/proveedor).

Lista para flota: cuando muchos nodos se reinician (y todos gritan)

• Elige tres nodos: uno que se reinició, uno que no, uno borderline. Compara logs lado a lado.
• Busca firmas comunes: mismos mensajes de driver, mismo modelo de almacenamiento, mismo firmware, mismo rack, mismo build de kernel.
• Divide por dominio de fallo: si es solo un rack, sospecha energía/red; si es solo un modelo de almacenamiento, sospecha firmware; si es solo un kernel, sospecha regresión.
• Detén la hemorragia: drena nodos, reduce profundidad de cola, desactiva flags problemáticos, pausa reinicios automatizados.
• Preserva evidencia centralmente: copia segmentos de /var/log/journal, volcados SEL, vmcores. Los incidentes son temporales; la evidencia es opcional salvo que la hagas obligatoria.

Lista de configuración: qué configurar antes de que ocurra el reinicio

• Journal persistente en todos los nodos; dimensionarlo adecuadamente.
• Envío centralizado de logs (y verificarlo consultando logs del último boot).
• kdump habilitado donde sea factible, y monitorización de creación de vmcore.
• Raspado de SEL para bare metal; almacenar fuera del host.
• Registro de cambios: actualizaciones del kernel, firmware, acciones de orquestación y eventos de auditoría “quién lo reinició”.

Hechos interesantes y contexto histórico (porque la historia se repite)

• Hecho 1: wtmp es una tradición Unix de décadas; es tosca, pero sigue siendo una de las formas más rápidas de detectar patrones de reinicio.
• Hecho 2: El ring buffer del kernel fue históricamente volátil; el journal de systemd facilitó enormemente la recuperación de mensajes del kernel entre arranques en muchas distros.
• Hecho 3: Las Machine Check Exceptions (MCE) son un mecanismo a nivel de CPU; Linux solo las reporta. Si MCE dice “hardware error”, no está siendo metafórico.
• Hecho 4: Los watchdogs existen porque no se puede confiar en que los sistemas colgados se recuperen por sí mismos. Son herramientas contundentes: útiles, pero ocultan causas raíz al reiniciar la máquina.
• Hecho 5: El comportamiento temprano de panic en Linux solía ser “halt and wait”. Los entornos de producción modernos suelen reiniciar tras panic para restaurar servicio rápidamente—a veces demasiado rápido para capturar evidencia.
• Hecho 6: Los registros SEL basados en IPMI viven fuera del SO. Por eso son tan valiosos cuando el SO no se apagó limpiamente.
• Hecho 7: Los timeouts de almacenamiento han mejorado, pero las pilas NVMe modernas aún pueden bloquearse con ciertas combinaciones firmware/driver, especialmente cuando la recuperación de errores colisiona con colas pesadas.
• Hecho 8: Los errores ECC “corregidos” no son inofensivos. Una tormenta de errores corregidos puede preceder fallos no corregibles y reinicios, y también puede degradar el rendimiento.
• Hecho 9: Los journals y logs no garantizan vaciado ante pérdida de energía; por eso el logging confiable usa persistencia más envío fuera del host.

Preguntas frecuentes

1) ¿Cómo distingo pérdida de energía de un crash del kernel?

La pérdida de energía/reset duro suele mostrar un final abrupto de los logs sin secuencia de apagado. Confirma con IPMI SEL (físico) o eventos del hipervisor (VM). El crash del kernel suele dejar líneas de panic/oops/watchdog y a veces un vmcore por kdump.

2) ¿Cuál es el comando más útil para el “arranque previo”?

journalctl -b -1. Úsalo con -p warning para reducir ruido y con --since para centrarte en los minutos finales.

3) ¿Por qué veo “Kernel panic” pero la razón del reinicio sigue sin estar clara?

Porque el panic puede ser un síntoma, no una causa. Necesitas contexto aguas arriba: timeouts de almacenamiento, errores MCE de hardware, bloqueos o señales de reset externas. También comprueba si panic-on-oops estaba habilitado.

4) ¿Los reinicios aleatorios suelen venir de software o hardware?

En la práctica: una mezcla, pero hardware/energía/firmware están subdiagnosticados porque la gente solo mira logs del SO. Si los logs del SO faltan o se cortan, asume que el SO no estaba en control.

5) Mi VM “se reinicia” pero no hay apagado en los logs del invitado. ¿Por qué?

El hipervisor puede resetear la VM como si desenchufaras el cable. Los logs del invitado no mostrarán un apagado ordenado. Necesitas eventos del host y logs de auditoría del plano de gestión.

6) ¿Vale la pena habilitar kdump pese a reservar memoria?

Para sistemas donde los crashes del kernel importan, sí. La memoria reservada es una prima de seguro. Sin vmcore, a menudo te quedas con evidencia circunstancial y culpas entre proveedores.

7) ¿Cómo se relacionan los resets por watchdog con problemas de almacenamiento?

Los bloqueos de I/O pueden impedir que los hilos del kernel avancen lo suficiente para que el watchdog decida que el sistema está colgado. El watchdog es el mensajero; los timeouts de almacenamiento pueden ser el mensaje.

8) ¿Puede la corrupción de sistema de archivos causar reinicios?

Los sistemas de archivos suelen intentar proteger datos remontando en solo-lectura o apagando componentes. El reinicio suele venir después: servicios fallan, la orquestación reinicia el nodo o el kernel hace panic por errores de bloque subyacente.

9) ¿Por qué faltan mis logs justo antes del reinicio?

O usas un journal volátil, el disco dejó de estar disponible o el sistema perdió energía. Los logs faltantes son un dato: trátalos como “probable reset abrupto” hasta demostrar lo contrario.

Conclusión: siguientes pasos que puedes hacer hoy

Si tus servidores “se reinician al azar”, no estás tratando con aleatoriedad. Estás tratando con evidencia faltante, atención mal dirigida o ambas cosas. Arregla la evidencia primero.

1. Haz journald persistente y verifica que puedas consultar journalctl -b -1 tras un reinicio.
2. Habilita kdump donde sea práctico y alerta sobre la creación de vmcore.
3. Recopila SEL del BMC fuera del host para bare metal; es tu detector de mentiras para eventos de energía/reset.
4. Estandariza un runbook de triage de reinicios: journal del arranque previo, SEL/hipervisor, MCE, errores de almacenamiento—siempre en ese orden.
5. Cuando encuentres la causa, cambia algo duradero: actualizaciones de firmware, correcciones en el feed de energía, política de reemplazo de almacenamiento o estrategia de versiones del kernel. No solo un postmortem en Slack y una promesa.

El objetivo no es convertirte en detective de reinicios por hobby. El objetivo es hacer que el próximo “se reinició” se convierta en una respuesta de dos capturas de pantalla y una solicitud de corrección que realmente permanezca.