Tercer reinicio no ordenado de pmx50, 20 de octubre de 2026¶
Inspección sólo lectura, acotada, a las 01:06:17–01:06:26 CEST. Sin cambios de watchdog, recursos, HA, configuración, migraciones ni pruebas de reinicio. La coordinación detectó el evento a las 01:05:30 y realiza por separado la comprobación de independencia de SSH.
Cronología directa¶
Dato de pmx50 (proxmox) |
Valor |
|---|---|
| Boot anterior | <REDACTED> |
| Journal anterior | 00:25:27–00:57:40 CEST |
| Boot actual | <REDACTED> |
Inicio actual, uptime -s |
00:58:06 CEST |
| Primer journal actual | 00:58:08 CEST |
| Uptime a las 01:06:17 | 491,21 segundos |
| Watchdog actual | SP5100 TCO timer, bootstatus 32, status 0x8020, timeout 10 s |
A las 00:58:08, el kernel del boot nuevo registra:
El driver se inicializa a las 00:58:10. El heartbeat de 60 segundos que imprime durante la inicialización no sustituye al timeout efectivo de 10 segundos leído después por sysfs. Sigue registrándose la reserva de crashkernel de 640 MB; esta lectura no verifica captura de un crash.
El journal retenido termina a las 00:57:40, sin secuencia de apagado en el tramo final inspeccionado. La consulta acotada de kernel y prioridades 0–4 entre 00:56:30 y 00:57:41 no aporta entradas. Las últimas líneas no relacionadas con autenticación incluyen el collector SMART existente a las 00:57:30, que registra finalización correcta. Esta proximidad temporal no acredita causalidad; no se ejecutó el collector durante la inspección ni se atribuye el reset a ese servicio. Se omitieron de la salida filtrada las líneas de autenticación y del informe los identificadores de dispositivos. No se consultó SMART adicional.
Correlación desde pmx51¶
Peer proxmox2: boot <REDACTED>, inicio 19 de octubre 21:58:51 CEST, sin nuevo boot respecto de la revisión anterior. Lectura limitada a 00:56:30–00:59:30 de corosync, CRM/LRM y watchdog-mux:
| Hora CEST | Evento retenido en pmx51 |
|---|---|
| 00:57:45 | Link del host 1 caído y sin enlaces activos. |
| 00:57:49 | Token ausente durante 7500 ms. |
| 00:57:51 | Timeout de token de 10000 ms; nueva configuración. |
| 00:58:03 | Membership sólo nodo 2; no se recibe mensaje de salida del nodo 1. |
| 00:58:15 | CRM informa loop took too long (32 seconds) y cambia proxmox de online a unknown. |
| 00:58:21 | Link del host 1 vuelve. |
| 00:58:22 | Membership 1 y 2; sincronización completada. |
| 00:58:25 | CRM devuelve proxmox a online. |
La ventana no contiene una orden explícita de fencing. El retraso de CRM corresponde al peer y no prueba que ordenara o causara el reset. La falta de una orden retenida tampoco descarta actividad no observada.
Guests después del arranque y límites¶
API PVE desde pmx51 a las 01:06:25,706 CEST: 28 guests, los 28 running, con 8 propietarios en proxmox y 20 en proxmox2. Los ocho de pmx50 tienen uptimes de 461–475 segundos, compatibles con arranque posterior al host:
| Guest ID | Tipo | Propietario actual | Uptime API, s |
|---|---|---|---|
| 186 | LXC | proxmox | 469 |
| 208 | QEMU | proxmox | 461 |
| 219 | LXC | proxmox | 475 |
| 251 | LXC | proxmox | 463 |
| 270 | LXC | proxmox | 475 |
| 280 | LXC | proxmox | 466 |
| 281 | LXC | proxmox | 463 |
| 305 | LXC | proxmox | 466 |
Los 20 guests del peer tienen uptimes de 11191–11225 segundos. El ID217 permanece en proxmox2. Esta foto posterior no acredita continuidad de aplicaciones, integridad de datos o ausencia de incidencias durante el intervalo; los uptimes de API tampoco son marcas exactas de arranque del sistema operativo de cada guest.
Se repite evidencia del mecanismo de reset por expiración del watchdog hardware. Estas lecturas no identifican por qué dejó de satisfacerse. No se atribuye a RAM, swap, colectores, SSH, publicaciones de fuente o carga de trabajo sin evidencia adicional. Véanse el segundo evento y los límites de captura/firmware. El publisher sigue deliberadamente OFF; esta revisión no ejecutó backups, export SQL ni tareas pesadas de datos.
Comparación acotada con el colector SMART¶
Consulta de sólo lectura a las 01:08, máximo veinte entradas PID1 por cada boot
de scrutiny-collector.service; JSON del journal procesado sin publicar números
de serie, configuración, URLs ni contenido SMART. No se ejecutó el colector.
| Reset | Último fin satisfactorio del servicio | Distancia hasta el nuevo boot |
|---|---|---|
| 00:03:01 | 19oct23:38:14 | 24min47s |
| 00:25:25 | 20oct00:05:06 | 20min19s |
| 00:58:06 | 20oct00:57:30 | 36s |
El boot largo también conserva completados a las 20:57:14, 21:27:14, 22:08:11, 22:38:13 y 23:08:13; un fallo a las 21:57:42 fue seguido por ejecuciones normales. Hubo otro completado a las 00:27:30 y el nuevo boot registra éxito a las 01:00:07. Timer activo con OnBoot2min/OnUnitActive30min.
La proximidad inmediata no es consistente en los tres incidentes y hay múltiples completados sin reset próximo. No acredita ni descarta causalidad; el éxito de la unidad sólo demuestra salida del proceso, no el resultado físico de los discos. No se deshabilitó ni modificó esta monitorización.
Comprobación posterior¶
A las 01:15:25 CEST, lectura directa de date, uptime, boot_id y
bootstatus: se mantiene <REDACTED>, con 17 minutos
de uptime y bootstatus32. No se observa un cuarto arranque en esa muestra;
no acredita estabilidad futura ni resuelve la causa. Sin cambios de runtime.
A las01:55:04 CEST, pmx50 conserva el mismo boot y56min de uptime
(load0,97/1,02/1,17). API consultada desde pmx51 a01:55:29:28/28running,
26LXC/2QEMU y mismos propietarios8/20. El peer mantiene
Observación 02:05:25 CEST¶
SSH conserva boot_id <REDACTED_UUID>, uptime1h07m
y carga1.87/2.27/1.70. No cuarto arranque observado en esta consulta; no prueba
estabilidad futura ni resuelve la causa del watchdog. Sólo lectura, sin ajustes.