pmx50: semántica de watchdog-mux y evidencia pendiente — 20 octubre 2026¶
Primera fase documental sin SSH; ampliación posterior autorizada sólo de lectura de journals acotados, documentada al final. Sin instalaciones ni ajustes. Los dos resets y la cronología se toman de primer incidente y segundo incidente. Acreditan expiración hardware SP5100 a aproximadamente00:03 y00:25:25 CEST; no acreditan la causa de la falta de alimentación.
Dos plazos y tres situaciones diferentes¶
El diseño separa el timeout hardware10s del watchdog virtual por cliente60s. Un desarrollador de Proxmox explica que, si el mux sigue ejecutándose y caduca un cliente, deja de alimentar el dispositivo después de60s; el reset llega aproximadamente entre60–70s desde el último ping. El valor10s no significa que LRM disponga sólo de10s. Explicación oficial.
El código oficial abre /dev/watchdog, solicita10s y lo mantiene abierto incluso sin clientes. Por tanto, encontrar un único FD de watchdog-mux es esperado; no identifica cliente ni estado anterior al reset. Si el propio mux deja de ejecutarse/alimentar el dispositivo, el plazo hardware puede vencer sin pasar por la caducidad60s del cliente. Si un cliente sigue conectado pero no actualiza, el mux avisa tras50s y deja de alimentar tras60s. Si desconecta sin cierre mágico, deja de alimentar sin esperar esos60s. Con cierre mágico lo retira limpiamente. La caducidad no se revierte después para recuperar el watchdog. watchdog-mux.c, revisión fijada.
La autoexclusión HA puede ser deliberada por pérdida de lock/quorum o petición de fencing; también puede resultar de un proceso que deja de progresar. SP5100 registra el mecanismo hardware común a esas situaciones. No permite elegir entre decisión HA, retraso de userspace, bloqueo del kernel o problema hardware. La documentación describe la relación entre locks, watchdog y recuperación. Documentación oficial HA.
LRM/CRM y el warning del peer¶
LRM actualiza su watchdog cuando renueva el lock de agente. Una petición de fencing conduce a liberar ese lock y estado lost_agent_lock; existe un mensaje específico sobre la necesidad de fencing. La renovación fallida también lleva a ese estado, sin demostrar una petición explícita. CRM usa protección ligada al lock de manager. LRM.pm, CRM.pm.
loop took too long (33 seconds) se imprime al terminar una iteración si su duración supera30s. No es una orden de fencing, ni identifica cuánto tiempo transcurrió desde el último ping. En este caso pertenece a pmx51: no demuestra que watchdog-mux de pmx50 quedara33s sin ejecutar ni que pmx51 ordenase su reset. Env/PVE2.pm, hooks y watchdog.
Qué buscar sin repetir consultas ya hechas¶
Los logs de las cuatro unidades en00:24–00:26 ya se consultaron sin mensajes locales relevantes. Root añadió a00:36 una lectura por identificador watchdog-mux del boot anterior (-b -1 -n35): sólo startup00:03:05, carga sp5100_tco y driverSP5100versión0; sin avisos ni registros de clientes retenidos. Repetir esas consultas aporta poco. Esa ausencia no demuestra que nunca hubiera un cliente o caducidad: puede faltar persistencia del journal. Root resolvió también el registro del boot previo al primer reset: journalctl -b -2 -t watchdog-mux -n50 devolvió sólo seis líneas retenidas: startup20:55:13; clientePID2107 añadido21:12:55; desconexión limpia dePID2107 y todos los clientes cerrados21:26:15; clientePID1919 añadido21:58:33. No hay expiración retenida antes del reset00:03. En esa primera lectura no se había identificado PID1919 ni se infería su daemon, continuidad hasta el reset o ausencia de otros clientes no registrados; la correlación posterior al final resuelve sólo su identidad y rol inicial. Esto aporta evidencia de conexión al mux, no de la causa del reset. Las dos lecturas propuestas del registro mux quedan resueltas; no se recomienda repetirlas.
La propuesta documental de correlacionar PID1919 y acotar la ventana previa al primer reset quedó autorizada y resuelta posteriormente, con resultados al final. No garantiza que se haya conservado el último evento y no autoriza cambios de HA.
Firmas del mux que conviene buscar, con o sin PID según versión: aviso de caducidad próxima, caducidad que deshabilita updates, desconexión sin cierre mágico, salida con conexiones activas, fallo de keepalive; distinguirlas de desconexión limpia. Para atribuir fencing explícito buscar además la petición/estado del LRM y transición del CRM o estado fence, no sólo caída de membership. Un PID registrado puede asociarse al arranque de su daemon; el FD único del hardware no lo permite.
Ausencia de mensajes no excluye esa secuencia: puede faltar planificación o persistencia del journal. Upstream incorporó sincronización del journal alrededor de expiraciones para mejorar esta captura, sin garantizarla frente a un bloqueo. Serie oficial de cambios.
Versión instalada aportada por Root a00:36: pve-ha-manager5.2.5. No hay tag5.2.5 listado; se ha localizado y fijado el commit oficial bump5.2.5, de23jul2026,21:15:10UTC, y comprobado su debian/changelog. Sus watchdog-mux.c, LRM.pm y CRM.pm son idénticos por SHA256 al HEAD consultado36e82fa; los cambios de Env/PVE2.pm hasta HEAD sólo afectan cómputo de memoria de huéspedes, no hooks ni watchdog. Por tanto, las semánticas descritas se han cotejado con la fuente5.2.5 y no se deducen sólo del HEAD. No se ha verificado hash del binario instalado ni parche local. SHA256 watchdog-mux.c5.2.5: <REDACTED>.
No se propone desarmar HA, tocar timeout, reiniciar mux ni probar fencing durante el incidente.
Correlación acotada resuelta a00:36:46CEST¶
Lectura autorizada sólo de journals LRM/CRM/corosync y PID concreto, sin cambios. Boot actual revalidado una vez: <REDACTED>. El boot previo al primer reset es <REDACTED>, retenido20:55:11–00:02:14. El abreviado -b3b5820ab fue rechazado por journalctl antes de leer; las consultas efectivas utilizaron el ID completo.
| Hora CEST19oct | Registro de ese boot |
|---|---|
| 21:58:33 | pve-ha-crm[1919] adquiere ha_manager_lock, activa watchdog y pasa slave => master. |
| 21:58:33 | watchdog-mux[1495] añade clientePID1919. |
| 21:58:36 | Corosync registra salida del nodo2 por sysadmin; membership sólo nodo1. |
| 21:58:43 | CRM[1919] cambia nodo proxmox2 de online a unknown. |
| 21:59:07 | Nodo2 se reincorpora; membership1+2 y sincronización completa. |
La coincidencia de boot, PID y timestamp identifica ahora al cliente añadido como pve-ha-crm, que asumió rol master en ese instante. Esto resuelve la identidad antes pendiente; no acredita que conservara ese rol, conexión o capacidad de alimentar el watchdog inmediatamente antes de00:03. La salida histórica del peer no demuestra causalidad sobre un reset ocurrido más de dos horas después.
Consulta delimitada23:59:30–00:03:10 a pve-ha-lrm, pve-ha-crm y corosync, con tope120entradas: sin entradas retenidas. No aporta petición de fencing, pérdida de lock, error de keepalive ni cambio de rol en ese intervalo. No convierte su ausencia en prueba de que no ocurrieran. Se mantienen las hipótesis abiertas y la distinción entre mecanismo de reset y causa. Esta lectura queda resuelta; no se propone repetir ni ampliar logs privados generales.