Watchdog-mux y HA: qué distingue el corte deliberado de un bloqueo¶
Análisis offline, basado en evidencia ya guardada y fuente oficial fijada. Sin SSH nuevo, instrumentación, ajustes ni pruebas de fencing. Complementa los informes del mux y de captura/firmware; no vuelve a proponer las lecturas de journal ya resueltas allí.
La cronología actual no demuestra que HA ordenara dejar de alimentar el watchdog, ni demuestra una congelación de CPU. Confirma cinco resets en la secuencia, con mecanismo hardware watchdog en los nuevos boots. Para distinguir las rutas falta la cadena local cliente→mux→keepalive anterior al reset.
Tiempos que realmente tenemos¶
Del cuarto/quinto evento:
| Observación guardada, CEST | Lo que mide |
|---|---|
| Boot intermedio 1c4615…, primer journal 02:11:16 | Primer registro retenido del cuarto arranque |
| Mux iniciado 02:11:19; LRM wait_for_agent_lock 02:11:39; CRM local slave 02:11:42 | Inicialización y estados locales en esos instantes |
| Peer vuelve a considerar online al nodo alrededor de 02:11:42 | Disponibilidad según el peer; no ping al mux |
| Último journal retenido del intermedio 02:12:42 | Límite de persistencia observado; no último keepalive |
| Peer pierde enlace 02:13:19.770 | Detección de pérdida de red; no instante exacto del cuelgue/reset |
| Boot actual 834…, btime 02:13:41; primer kernel 02:13:43.046069 | Inicio OS estimado y primer registro posterior al quinto reset |
| Rejoin 02:13:56.685 y online alrededor de 02:13:58 | Recuperación de comunicación/estado del peer |
El intervalo aproximado de 61 s entre último journal y nuevo kernel no es una medición del timeout virtual de 60 s. Incluye posibles datos no persistidos, tiempo hasta reset y firmware/POST. Los 23,276 s entre caída de enlace y primer kernel tampoco miden directamente el timeout hardware de 10 s. La distancia entre boots no es la edad de ningún cliente. Ninguno de estos relojes se sustituye por otro.
Semántica cotejada, no inferida de los intervalos¶
Fuente 5.2.5: commit oficial
<REDACTED>.
La versión instalada 5.2.5 fue aportada por el coordinador; no se ha demostrado
igualdad binaria ni ausencia de parches locales.
El cliente conectado vence con edad >60 s, avisa con >50 s; el mux entonces inhibe futuros keepalives. Una desconexión sin cierre mágico tiene otra ruta inmediata. Un cierre mágico y quedar sin clientes permiten continuar alimentando el dispositivo: cero clientes no es por sí mismo un motivo de reset.
La decisión del mux no identifica por qué faltó un cliente. En particular, LRM actualiza su protección al renovar el lock; tanto una petición de fencing como una renovación fallida pueden llevar a lost_agent_lock. La petición explícita se distingue por su mensaje y estado de fencing. Un cliente bloqueado puede producir la misma expiración que la retirada de latidos por política.
En CRM, abrir protección requiere obtener el lock de manager; arrancar como slave no lo acredita. LRM recién iniciado en wait_for_agent_lock tampoco acredita una protección abierta. Los estados guardados no demuestran que siguieran iguales hasta el reset, ni que no hubiera otro cliente. Online en el peer no equivale a master local ni a renovación de un lock protegido.
La retirada voluntaria y limpia de protección HA usa el cierre mágico del entorno PVE. No debe confundirse con abandonar un cliente armado para provocar self-fencing.
Hipótesis falsables y firmas que las separan¶
| Ruta propuesta | Evidencia local que la apoyaría | Qué no basta / cómo se pondría a prueba su coherencia |
|---|---|---|
| Mux deja de alimentar por caducidad de un cliente | PID del cliente asociado al daemon y al mismo boot, último ping, aviso y corte por expiración; ausencia de keepalives posteriores del mismo proceso | Un PID histórico, online del peer o un hueco de 60 s no bastan. Con registro completo que demuestre cero clientes armados durante toda la ventana, esta ruta queda excluida. |
| Self-fencing explícitamente decidido por HA | Petición local de fencing, transición del LRM y correlación del cliente concreto con el corte | Expirar un cliente sólo demuestra la decisión inmediata del mux, no una intención de HA ni la causa raíz. lost_agent_lock sin petición puede ser una renovación fallida. |
| Cliente muere/desconecta sin cierre mágico | EOF/HUP de ese socket y mensaje de desconexión insegura, seguido de corte; proceso/boot identificados | No necesita esperar 60 s. Un cierre mágico limpio de ese cliente contradice atribuirle esa misma desconexión insegura. |
| Mux no recibe CPU o queda bloqueado; también cabe bloqueo global | Último keepalive exitoso, pérdida de progreso local y trazas de planificación/bloqueo que incluyan al mux | Ausencia de journal no demuestra ausencia de ejecución. Heartbeats locales independientes que siguen progresando contradicen un bloqueo global, pero no descartan que sólo el mux esté bloqueado. |
| El mux ejecuta pero falla el keepalive o no llega a su rama | Traza de ioctl/errno o secuencia de eventos que muestra actividad sin keepalive | Un proceso vivo, FD abierto o clientes con pings no demuestran que el hardware recibiera una actualización correcta. |
Un corte deliberado del mux y un bloqueo de CPU no son hipótesis mutuamente excluyentes: un cliente puede atascarse, el mux seguir vivo y aplicar su medida de seguridad. Para atribuir causa hay que situar el primer fallo, no sólo el último mecanismo que termina reiniciando el nodo.
Dos cautelas adicionales del código¶
La actualización hardware se emite en la rama de timeout de epoll, no en todas las iteraciones del bucle. Por inspección del control de flujo, una secuencia de eventos sin hueco suficiente podría impedir llegar a esa rama aun con proceso vivo. No hay evidencia de esa secuencia aquí, ni se afirma que los clientes HA normales la produzcan. Es una alternativa comprobable a la falsa dicotomía «corte por cliente o CPU congelada»; no una causa nueva acreditada.
La edad de cliente usa reloj de pared time(NULL), mientras el temporizador hardware sigue su propio reloj. Un salto de hora puede alterar la edad lógica. El análisis de reloj ya guardado no encontró firmas seleccionadas en los tres boots que examinó, pero no cubrió los dos últimos. No se extrapola esa ausencia a toda la noche.
Próxima evidencia propuesta, sin desplegarla¶
Primero correlacionar sólo capturas ya existentes por boot/PID y tiempo monotónico: cliente añadido/último ping/cierre, cambio de lock o petición de fencing, decisión del mux e ioctl hardware exitoso/fallido, con un pulso local independiente. Distinguir logs emitidos, recibidos y persistidos. Si faltan estas señales, su captura acotada sería una propuesta posterior para revisión, con coste y privacidad definidos; no se ha instalado ni ejecutado ahora.
No se propone desarmar HA, cambiar 10/60 s, reiniciar mux, abrir el watchdog, forzar panic/fencing, generar carga o flashear firmware. No existe base probatoria para seleccionar una de esas acciones como solución a partir de este timing.
Snapshot de sockets, 02:24:20CEST¶
Lectura posterior selectiva por Root, sin abrir /dev/watchdog ni conectarse al socket: mismo boot834ae68a…, muxPID1506. TablaFD:1/2 comparten socket10901 (stdout/stderr),3→/dev/watchdog,4→socket15725,5eventpoll,6signalfd. ss-xapnH filtrado por mux/path muestra socket15725 LISTEN /run/watchdog-mux.sock y socket10901 ESTAB de stdout/stderr; no se observaron descriptores de clientes aceptados ni otros sockets del mux. No se truncaron filas. Son dos lecturas cercanas, no una captura atómica ni evidencia de toda la ventana previa al reset.
La consulta02:23:43 conservaba mux/CRM/LRMactivos (PID1506/1928/2022); el tag mux del boot sólo retenía sus dos mensajes de carga/driver de02:13:45. Esta muestra acredita ausencia observable de clientes en ese intervalo actual, no ausencia histórica ni causa de los cinco resets. Es coherente con el diseño que mantiene hardware armado y alimentado sin clientes; no se desarmó HA ni se alteró su watchdog. Tampoco prueba que el mux vaya a seguir progresando.