pmx50: cuarto y quinto arranques tras reset, 20 de octubre de 2026¶
Confirmados dos nuevos boots, con primer journal a las 02:11:16 y 02:13:43 CEST. Ambos registran expiración del watchdog hardware como motivo del reset anterior. La detección inicial a las 02:14 parecía un cuarto evento; el boot intermedio retenido demuestra que el actual es el quinto de la secuencia. Se conserva el nombre de archivo solicitado para enlazar el incidente inicial.
Inspección directa de pmx50 sólo lectura a 02:15:28–02:15:53 CEST: dos consultas SSH acotadas,106 entradas de journal proyectadas en total, sin credenciales ni configuraciones completas. Sin reinicios, cambios, tuning, stress, cargas, operaciones de copia, migraciones o pruebas sobre watchdog. No se solapó la comprobación del peer/PBS que realiza el coordinador.
Cronología del journal retenido¶
| Boot | Primera entrada retenida CEST | Última entrada retenida en la primera consulta | Identidad |
|---|---|---|---|
| Segundo | 00:25:27 | 00:57:40 | <REDACTED> |
| Tercero | 00:58:08 | 02:10:43 | <REDACTED> |
| Cuarto, intermedio | 02:11:16 | 02:12:42 | <REDACTED> |
| Quinto, actual | 02:13:43 | 02:15:28 | <REDACTED> |
Los límites del journal no equivalen al instante exacto de pérdida de servicio,
reset físico ni comienzo del firmware. Para el boot actual, /proc/stat da
btime 02:13:41 CEST; a las 02:15:28 el uptime era 107,55 s.
La consulta anterior del coordinador a las 02:05:25 conservaba el boot db3a… con 1 h 07 min de uptime. Eso acredita esa observación, no estabilidad posterior.
Mecanismo que registra el kernel¶
| Boot nuevo | Hora precisa CEST del registro | Mensaje |
|---|---|---|
| Intermedio 1c46153c… | 02:11:16.602295 | Previous system reset reason [0x02000800]: hardware watchdog timer expired |
| Actual 834ae68a… | 02:13:43.046069 | Previous system reset reason [0x02000800]: hardware watchdog timer expired |
Son dos registros independientes del kernel, además del inventario de boots. El mensaje del boot intermedio informa del reset que terminó el boot db3a…; el del boot actual informa del reset que terminó el intermedio 1c46153c…. No son dos mensajes repetidos del mismo arranque.
Sysfs del watchdog actual, leído sin abrir /dev/watchdog:
| Campo | Valor |
|---|---|
| identity | SP5100 TCO timer |
| bootstatus | 32 |
| status | 0x8020 |
| timeout | 10 s |
| timeleft en la muestra | 9 s |
No se armó, alimentó, detuvo ni reconfiguró el watchdog durante la inspección. Las entradas «NMI watchdog: Enabled» observadas son inicialización; por sí solas no acreditan un hard lockup ni identifican quién dejó de alimentar el temporizador.
Kernel, mux y HA retenidos¶
Del boot db3a… se leyeron las últimas 60 entradas kernel y las últimas 70 de watchdog-mux/CRM/LRM; tras filtrar autenticación resultaron 72 entradas. El último kernel retenido en esa selección es 01:00:29.234110 CEST, montaje de loop0 después de recovery EXT4. No aparecen mensajes kernel cercanos al corte en esa selección: no permite atribuir ni descartar una causa.
Los dos boots nuevos presentan esta inicialización:
| Evento | Boot intermedio CEST | Boot actual CEST |
|---|---|---|
| watchdog-mux iniciado | 02:11:19.006774 | 02:13:45.445016 |
| módulo solicitado | sp5100_tco | sp5100_tco |
| driver SP5100 identificado | 02:11:19.024287 | 02:13:45.462218 |
| LRM startup→wait_for_agent_lock | 02:11:39.079291 | 02:13:59.321822 |
| CRM wait_for_quorum→slave | 02:11:42.249442 | 02:14:03.673613 |
La búsqueda seleccionada de mensajes de shutdown/reboot ordenado en ambos boots no devolvió coincidencias (journalctl rc 1). Es ausencia en esa consulta, no prueba de que ninguna orden o actividad no retenida existiera. Estos mensajes de arranque no demuestran una decisión de fencing ni su autor.
El coordinador recibió del agente del peer dos intervalos de pérdida/rejoin: 02:10:52.955–02:11:36.608 y 02:13:19.770–02:13:56.685 CEST. Se incluyen como correlación aportada por esa inspección independiente, no como lectura propia del peer ni como causa del reset.
Contexto y límites de atribución¶
El coordinador declara que no solicitó reinicios. En la ventana aproximada 02:13–02:14 ejecutaba pruebas sintéticas del backend de copias en VM208 como UID 1000, con fuente/tests temporales, sin NAS ni exportaciones; la sesión 10501 perdió SSH con 255 y no dejó resultado de esa ejecución. Se registra este contexto, sin atribuir causalidad a las pruebas, señales, Python, RAM, swap, SSH, publicaciones de fuente, colectores o carga. Tampoco se certifica que esas pruebas terminaran o pasaran en VM208.
El mecanismo observado sigue siendo expiración del watchdog hardware. Falta identificar por qué dejó de satisfacerse: el reset reason no discrimina bloqueo de plataforma/kernel, pérdida de servicio del mux o una política/acción no observada. No se modificó nada para intentar discriminarlo en caliente.
Esta inspección no acredita recuperación de aplicaciones, almacenamiento PBS, quorum estable, continuidad de guests ni integridad de datos. El coordinador investiga esas superficies por separado; los arranques repetidos pueden dejar ventanas de guard/servicios todavía pendientes. No se forzó su activación.
Contexto previo: tercer evento, análisis del mecanismo y límites y watchdog-mux.
Observación adicional02:18:31CEST¶
Root conserva boot
Observación02:39:04CEST¶
LecturaSSH conserva boot