Segundo reinicio no ordenado de pmx50, 20 de octubre de 2026¶
Recogida acotada de solo lectura a las 00:32:08–00:32:30 CEST. No se han cambiado watchdog, HA, recursos, servicios ni parámetros de arranque. La revisión fuente del receptor de copias quedó temporalmente pausada.
Identidad y secuencia observadas¶
| Dato | Valor |
|---|---|
| Nodo afectado | proxmox, pmx50, 192.168.0.XXX |
| Boot anterior | <REDACTED> |
| Intervalo de journal anterior | 00:03:03–00:24:42 CEST |
| Boot actual | <REDACTED> |
Inicio actual según uptime -s |
00:25:25 CEST |
| Primer journal actual | 00:25:27 CEST |
| Peer observado | proxmox2, pmx51, 192.168.0.XXX |
| Boot del peer | <REDACTED>, inicio 19 de octubre 21:58:51 CEST |
El kernel del arranque actual registra literalmente a las 00:25:27:
La lectura sysfs actual da bootstatus=32, status=0x8020, timeout=10 segundos e identidad SP5100 TCO timer. El único descriptor abierto encontrado sobre /dev/watchdog* pertenece a watchdog-mux, PID 1491, FD 3, /dev/watchdog. Esto describe el arranque actual, no demuestra el titular ni el estado del descriptor inmediatamente antes del reinicio. La inicialización del driver imprime heartbeat=60 sec; el timeout efectivo leído posteriormente es 10 segundos.
Final del arranque anterior¶
El tramo final retenido no muestra una secuencia de apagado. Entre 00:23:42 y 00:24:43, las consultas de journal del kernel y prioridades 0–4 no devolvieron entradas. El journal general termina a las 00:24:42.
Se observa logrotate.service iniciado a las 00:24:31 y finalizado con éxito a las 00:24:33, junto con recargas de pveproxy/spiceproxy y reinicio del logger de firewall. Después aparecen varias sesiones SSH breves desde VM208, cerradas entre 00:24:39 y 00:24:42. La proximidad de estas acciones no acredita causalidad; no se atribuye el reset a la rotación ni a las sesiones.
Las consultas del boot anterior a watchdog-mux, pve-ha-lrm, pve-ha-crm y corosync entre 00:24:00 y 00:26:00 no aportaron entradas. Esto es una ausencia de evidencia retenida en esa ventana, no una prueba de ausencia de actividad ni de fencing.
Correlación independiente desde pmx51¶
Consulta limitada a 00:24:15–00:26:00 CEST de las cuatro unidades anteriores:
| Hora CEST | Observación en pmx51 |
|---|---|
| 00:25:04 | KNET declara caído el enlace del host 1 y sin enlaces activos. |
| 00:25:06 | Token no recibido durante 7500 ms. |
| 00:25:09 | Timeout del token de 10000 ms; comienza nueva configuración. |
| 00:25:21 | Membership sólo nodo 2; nodo 1 sale sin recibir mensaje de salida. |
| 00:25:33 | CRM cambia proxmox de online a unknown; LRM informa loop took too long (33 seconds). |
| 00:25:43 | Enlace del host 1 vuelve; membership 1 y 2. |
| 00:25:45 | Sincronización de servicio completada. |
| 00:25:53 | CRM cambia proxmox de unknown a online. |
En pmx50, el arranque nuevo registra inicio de watchdog-mux a las 00:25:29, quorum a las 00:25:45, inicio de LRM a las 00:25:48 y CRM en estado slave a las 00:25:52. El mensaje de Corosync Watchdog not enabled by configuration describe su propio servicio de watchdog; no contradice el descriptor de watchdog-mux observado.
Correlación de Prometheus aportada por la coordinación¶
Root consultó Prometheus real desde CT217 en el rango 00:18–00:33 CEST, con cadencia de 15 segundos. La serie up de pmx50 muestra primera muestra 0 a las 00:25:00.323 y primera muestra 1 posterior a las 00:25:30.323. Son tiempos de muestras de scrape; no delimitan con precisión el inicio o duración de la indisponibilidad del host.
node_boot_time_seconds cambia de 1792447381 a 1792448725 (nuevo inicio 00:25:25 CEST), coherente con la lectura directa. La alerta real ProxmoxBootTimeChanged aparece en estado firing. Root comprobó además los 28 guests ejecutándose y sin cambios de propietario en la API; esta observación posterior no acredita continuidad de los procesos durante el reset.
Recursos del host antes del segundo reset¶
Consulta posterior de métricas ya retenidas en Prometheus, ventana 00:20–00:25, 20 muestras cada 15 segundos; la última muestra disponible es 00:24:45.323. Son métricas del host pmx50, distintas de la presión dentro de VM208.
| Métrica | Ventana observada |
|---|---|
| MemAvailable | Mínimo 14.181.752.832 B; máximo 14.865.842.176 B; final 14.687.731.712 B |
| SwapFree | 6.433.452.032 B, sin cambio |
| OOM kills | 0, sin cambio |
| PSI memoria full acumulado | Sin incremento |
| PSI IO full acumulado | +1,394197 s en 285 s entre muestras extremas |
| Load1 | 0,47–2,02; final 0,67 |
Estas muestras no muestran agotamiento de memoria ni carga sostenida alta del host antes de la pérdida de scrapes. No observan los segundos posteriores al último scrape ni excluyen un bloqueo súbito. No identifican la causa del reset y no justifican modificar RAM, watchdog o firmware.
Conclusión y límites¶
Hay evidencia explícita del mecanismo de reset por expiración del watchdog hardware, repetido respecto del incidente anterior. El peer confirma la pérdida y posterior reincorporación del nodo; la ventana consultada no contiene una orden explícita de fencing. No identifica por qué dejó de satisfacerse el watchdog: bloqueo del sistema, retraso de planificación, decisión de fencing u otras causas siguen sin acreditarse por estas lecturas. El mensaje de retraso de LRM pertenece al peer y no prueba por sí solo que iniciara el reset de pmx50.
No se atribuye el incidente a RAM ni a swap. Las métricas históricas y la cronología de acciones que recoge la coordinación deben cruzarse por separado. El análisis de límites de captura de crash y firmware permanece en el informe anterior. No se ha ejecutado ninguna corrección ni prueba de reinicio.