pmx50: reinicios de watchdog desde el 20 de octubre, 18:45 CEST

Último reinicio confirmado: 21oct, 13:59:17 CEST, boot 74ed704b…. Kernel: expiración de watchdog hardware, estado 0x02000800; sysfs bootstatus32. Pulso conserva progreso de mux/LRM/CRM hasta13:58:45, sin demostrar keepalives ni causa del hueco final. Infraestructura recuperada a las14:20–14:21:28/28 invitados y14/14 HA activos. Véase la evidencia y límites de este evento.

Nuevo arranque del 21oct, 11:56:40 CEST: boot 558fbd3c…, observado por primera vez a las12:04:12. La lectura nativa de las12:12 confirma expiración del watchdog hardware y bootstatus32; la causa de perder keepalives continúa abierta. Las observaciones de c4c64375… son históricas.

Actualización21oct09:58CEST: el journal retenido acredita cinco boots posteriores al evento10, todos con el literal de expiración del watchdog en su kernel. El boot actual es c4c64375…, btime06:25:34CEST. La causa de perder keepalives continúa sin demostrarse. Véase la cronología adicional al final.

Evento 10, 23:24:41 CEST: otro boot de pmx50, 10196fa7…, con firma SP5100/watchdog. VM208 completó su arranque automático y estaba running a las 23:25:55. El apéndice del nuevo evento conserva sus fechas y límites; el evento 9 y las lecturas anteriores siguen siendo históricos.

Confirmación y alcance

La observación nativa de las 18:50:04 CEST / 16:50:04 UTC confirma btime=1792514705: arranque de pmx50 a las 18:45:05 CEST / 16:45:05 UTC, boot ID <REDACTED_UUID>, uptime299,09 s. Es distinto del boot anterior de las15:55, 248d8d61…. Es el noveno arranque registrado en esta secuencia: cinco nocturnos y los de13:35,15:11,15:55 y18:45.

En la misma proyección, VM208 tiene boot <REDACTED_UUID>, btime1792514750, 18:45:50 CEST / 16:45:50 UTC, uptime253,44 s. Pmx51 conserva boot <REDACTED_UUID>, btime1792439931 y uptime75072,26 s. Esto acredita esos arranques y continuidad observada del peer; no demuestra recuperación funcional de invitados o aplicaciones.

A las 18:51:29,406442 CEST, el kernel actual registra SP5100 y expiración del watchdog hardware, estado 0x02000800 y watchdog0/bootstatus=32. Es el mecanismo reportado, no la causa de perder keepalives. Siguen aplicándose los límites del driver y de captura. No se atribuye la causa a Ansible, Git, temperatura ni a las lecturas realizadas. El primer registro del journal POST no se consultó en esta fase.

Journal local y recepción del pulso

Evidencia	CEST	UTC	Límite
Último journal local PRE, boot 248d8d61…	18:44:33,386226	16:44:33,386226	Último registro retenido, no último keepalive
Último pulso PRE recibido en pmx51	18:44:40	16:44:40	Reloj del receptor, uptime reportado10175,97 s
Btime nativo pmx50	18:45:05	16:45:05	Identidad de boot confirmada
Primer pulso POST recibido	18:45:16	16:45:16	Uptime reportado11,57 s
Btime nativo VM208	18:45:50	16:45:50	Arranque observado, sin prueba de apps

Los últimos40 s del journal local PRE (18:43:53,386226–18:44:33,386226) contienen 6 filas, sin truncado señalado, cero registros de prioridad≤3 y cero categorías de error seleccionadas. No descarta fallos globales, pérdidas de logs ni actividad posterior al último registro.

La evidencia retenida en pmx51 cubre la ventana recibida18:43:30–18:45:30. Se leyeron colas acotadas de8MiB por archivo, no todos los logs o rotaciones; identidades y tamaños permanecieron estables durante esa lectura. Separando segmentos por caída de uptime, hay 70 pulsos PRE hasta18:44:40 y 15 POST desde18:45:16. Esa segmentación no sustituye un boot UUID; la confirmación nativa anterior aporta el contexto. Los36 s entre recepciones no son una medición de duración del bloqueo.

En el segmento PRE, las seis series PSI avg10 seleccionadas (CPU/memoria/I/O, some/full) tienen máximo0; temperatura CPU47,2–50,1 °C, última47,4 °C; MemAvailable mínimo13537MiB, último13555MiB; NVMe reporta live en70 pulsos. No hay mediciones térmicas/PSI durante el hueco: estos valores no excluyen un fallo posterior ni identifican la causa. Cero firmas de error de la lista permitida en la captura no equivale a ausencia global de errores. Las172 filas de journal-stream combinan PRE y POST y no redefinen el último journal local.

Primer ciclo natural Ansible observado después

A las18:51:29 la unidad estaba activating/start. Se siguió la misma invocación <REDACTED>, iniciada naturalmente 18:51:10 CEST. La lectura terminal de las 18:52:51,297171 CEST conserva boot 82d105f6…, MainPID0, inactive/dead, Result=success, ExecMainStatus0 y fin 18:51:58 CEST. No se forzó start, pull, fetch ni reintento.

La observación de las 18:54:47,209913 CEST registra354 filas de esa invocación, sin truncado señalado, y recap 71 ok / 0 changed / 0 unreachable / 0 failed / 17 skipped. HEAD <REDACTED>; status rc0, cero entradas en alcance normal con untracked. La comprobación de conectividad Git devuelve rc0, cero categorías missing/broken/empty/fatal, 18183 bytes stdout y cero stderr. No es una verificación completa de blobs, árbol de trabajo, filesystem o hardware.

Las lecturas efectivas mantienen core.fsync=all y core.fsyncMethod=fsync. El reset ocurrió después de su instalación: esas opciones no evitan reinicios ni identifican su causa; este resultado tampoco prueba eficacia causal sobre la durabilidad de toda la caché. El ciclo correcto sólo acredita esa ejecución, no estabilidad posterior ni salud de aplicaciones.

Estado de cambios y evidencias

Los nuevos cambios runtime quedaron detenidos al confirmar el arranque. La protección FIFO del publicador está publicada sólo en fuente mediante PR78, merge 161766a; no se instaló esa revisión. En esa fase, el lector de logs acotado seguía como candidato de fuente; no se usó para generar retrospectivamente esta captura. Su integración posterior se registra abajo por separado. No se lanzaron jobs, recuperación NFS, quiesce ni modificaciones de estado como parte de la documentación. La causa del watchdog y la continuidad futura siguen pendientes.

Proyecciones privadas, sin mensajes crudos ni valores secretos, directorios0700 con archivos0600:

Archivo privado	SHA256
~/.local/state/watchdog-event9-20261020-n3l2coss/quick.json	<REDACTED>
Mismo directorio, forensics.json	<REDACTED>
Mismo directorio, ansible-observation.json	<REDACTED>
Mismo directorio, cache-and-recap.json	<REDACTED>
~/.local/state/watchdog-e9-pulse-20261020-q2q59cb3/projection.json	<REDACTED>
Mismo directorio, summary.json	<REDACTED>

Recuperación observada sólo metadatos: 18:59–19:00 CEST

Una lectura de la API cluster PVE a las 18:59:32,871951 CEST devuelve 28/28 invitados running,26LXC y2VM; ocho en pmx50 y20 en pmx51. No hay IDs añadidos/ausentes ni cambios de propietario, tipo o estado respecto de15:06. Se confirmó VM208 running en pmx50 antes de leer sus metadatos Docker.

La lectura efectiva Docker a las 19:00:57,389012 CEST confirma boot de VM208 79b3e12e… y 90 contenedores, mismos IDs/nombres/proyectos/estados que15:10: 47running,42exited y uno created. Cero paused, restarting y OOMKilled registrados. Entre los running,23 healthy y24 sin healthcheck configurado, cero unhealthy. Las22 marcas unhealthy de contenedores exited son estado retenido, no nuevas incidencias ni prueba actual de salud de aplicaciones. Tres exited conservan RestartCount1; ese contador no demuestra causa ni continuidad.

Hay16 parados con protección positiva de nombres/grupos lazy observados; los27 restantes incluyen copias migradas/legacy y otros sin clasificación positiva suficiente. No se deduce que deban arrancar ni que todos estén dormidos por decisión de Sablier. No se consultó su API ni se revalidó Caddy activo. El hash completo de RunWisp sigue <REDACTED>, uid/gid1000, modo0600 e inode3426519. El hold no se modificó.

Un primer intento Docker terminó en ValueError del lector, sin inventario válido: no se interpretó como una avería de Docker/productos. El acceso a Health opcional se corrigió en el lector privado mediante index; fixtures locales aceptaron Health null y rechazaron claves requeridas ausentes. Hubo un solo pase efectivo correcto después. La compatibilidad del formato quedó acreditada por ese pase, no por simular Go templates en Python.

Estos son estados seleccionados del hipervisor/motor, no login, funcionamiento, integridad de datos, NFS recuperado ni restauración completa. No hubo GET de productos, healthchecks forzados, probes, herramientas HA, acceso NAS, colectores, jobs, arranques o cambios de estado. Esquema actualizado.

Evidencia privada seleccionada en ~/.local/state/event9-recovery-metadata-20261020-ujlhftpn/ (0700, archivos0600):

Archivo	SHA256
pve.json	<REDACTED>
comparison-pve.json	<REDACTED>
docker.json, intento inválido	<REDACTED>
docker-corrected.json, pase efectivo	<REDACTED>
comparison-docker.json	<REDACTED>

Mejoras en fuente posteriores al reset: 18:48–19:05 CEST

El lector manual antes-del-cuelgue se integró mediante PR79, merge <REDACTED> a las18:58:47 CEST. Ahora hace una sola pasada por archivo, con límites de64MiB,500000 filas, 64KiB/fila,128 huecos, N entre1 y200 y deadline cooperativo compartido de10 s. Acota buffers antes de almacenarlos; rechaza enlaces/FIFO y marca cobertura incompleta o desconocida cuando corresponde. No garantiza timeout duro ante I/O bloqueada. Los doce casos pasan en Linux Python3.10/3.12: CI posterior y lint/fixtures Ansible.

La tarea de copia sólo corresponde al receptor pmx51. Publicar este cambio no ejecuta el lector ni reinicia un daemon. A las18:59:24, pmx51 conservaba boot 86184726…, pull natural18:57:44–18:58:47 correcto y archivo antiguo: SHA256 <REDACTED>. La revisión nueva tiene SHA256 <REDACTED>; convergencia ordinaria pendiente de observar, sin forzar pull o ejecución. Proyección privada watchdog-event9-20261020-n3l2coss/peer-helper-baseline.json, SHA256 <REDACTED>.

La corrección FIFO del publicador de originales, PR78, conserva56 pruebas correctas y CI posterior verde. Su fuente nueva SHA256 <REDACTED> añade apertura no bloqueante antes de comprobar el tipo de archivo. Evita bloquear al abrir un FIFO sin escritor; no es una garantía de timeout duro en archivos regulares/NFS. No se observó un FIFO real ni se atribuye a este bug el fallo de publicación. La instalación en VM208 sigue detenida tras E9; la última instalación acreditada es la v2 anterior, y no se ejecutó como prueba.

La lectura SMBIOS de pmx50 a las19:00:32 conserva el mismo boot y reporta dos módulos de16GB DDR5,4800MT/s,1,1V. Son datos declarados por firmware, no inspección física ni prueba de integridad de RAM. No se retuvieron números de serie o parte. Proyección privada watchdog-event9-20261020-n3l2coss/memory-dmi.json, SHA256 <REDACTED>.

Orden de publicación documental corregido: 19:12 CEST

PR80, merge <REDACTED>, evita que dos ejecuciones propias publiquen en orden inverso. Sólo los jobs de main comparten un grupo fijo, sin cancelar una subida en curso; tras adquirir turno hacen checkout explícito de main y registran el HEAD realmente construido. Un rerun antiguo construye contenido actual. El filtro del job deja fuera manuales de otras ramas antes de competir por el grupo. No se asume FIFO ni se compara procedencia con el SHA antiguo del evento. El diseño y sus límites se explican también en docs/README.md del repositorio.

Las pruebas locales Git/Bash reprodujeron el orden inverso anterior y la construcción vigente con reruns; una segunda revisión cotejó estructura YAML, permisos, pins, redacción y argumentos de publicación. No son un ensayo del scheduler GitHub. El recibo privado final docs-latest-review-20261020-jct62r5l/final-790-receipt.json, SHA256 <REDACTED>, distingue las pruebas históricas del hash final del workflow.

Antes del merge se canceló la ejecución antigua39463483752 en cola y sin pasos iniciados; su estado terminal cancelled también fue verificado. No se canceló una subida externa. La nueva ejecución39464018058 terminó correctamente, incluida la publicación. El paso de procedencia registró HEAD construido <REDACTED>. Quedan fuera de garantía uploads externos, cancelaciones manuales y fallos de red/proveedor; no hay transacción con Cloudflare ni cambio del sitio LAN o de servicios del homelab.

Convergencia natural del lector observada: 19:15 CEST

La única lectura posterior, 19:15:15,123803 CEST, confirma que pmx51 conserva boot <REDACTED_UUID>. El archivo instalado /usr/local/bin/antes-del-cuelgue ya tiene SHA256 <REDACTED>, exacto a la fuente revisada: regular, nlink1, root:root,0755,9028 bytes. La lectura usó apertura no-follow/no-block y cotejo de identidad antes/después; no ejecutó ese archivo ni consultó logs de productos.

El ciclo ordinario19:13:44–19:14:45 CEST, invocación <REDACTED>, terminó inactive/dead,MainPID0, Resultsuccess/ExecMainStatus0. Timer activo esperando; no se forzó start/pull ni se lanzó reinicio, job o instalación manual. Esto acredita archivo y ciclo observado, no que el lector se haya ejecutado sobre logs reales ni estabilidad futura. La muestra18:59 con archivo antiguo conserva su validez histórica.

Proyección privada0700/0600 en ~/.local/state/peer-helper-convergence-20261020-2gp48wf3/projection.json, SHA256 <REDACTED>. Lector revisado SHA256 <REDACTED>. La instalación FIFO de VM208 permanece detenida; la causa de resets y demás pendientes operativos no quedan resueltos por esta convergencia.

Lectura selectiva retrospectiva de mux/HA: 19:26 CEST

Una única lectura a las 19:26:40 CEST conservó boot actual 82d105f6… antes y después. Buscó sólo el boot PRE <REDACTED>, ventana 18:43:30–18:45:05 CEST /16:43:30–16:45:05 UTC, con filtros OR por unidad/identificador de watchdog-mux, LRM, CRM y corosync. Cada cláusula incluye el mismo boot PRE; no se consultaron dispositivos, sockets o procesos protegidos ni se ejecutó instrumentación.

El proceso journalctl terminó rc0 y devolvió cero filas seleccionadas. La proyección completó sus comprobaciones sin alcanzar los límites de64KiB, 121 filas o deadline cooperativo6s. La cobertura de retención permanece unknown: cero filas no demuestra ausencia histórica de mensajes, clientes, fencing, errores de keepalive o pérdida de quorum. No se recuperó la cadena cliente→mux→hardware y no se atribuye causa. No se repetirá el barrido vacío como si aportara continuidad; el diagnóstico físico y la captura faltante siguen pendientes. El pulso Python tampoco acredita ioctlkeepalive del mux.

Las firmas de mux se cotejaron con la fuente oficial fijada c73364c, sin afirmar identidad binaria del host. Catorce fixtures locales verifican filtros, ausencia de mensajes crudos, parcialidad, límites, timeout y boot. No se reinició o reconfiguró HA/mux/pulso; no se forzó sync de journal.

Evidencia privada ~/.local/state/watchdog-e9-selected-reader-20261020/: lector SHA256 <REDACTED>; projection.json SHA256 <REDACTED>. Sólo conserva agregados y metadatos; los mensajes no se guardaron.

Evento 10

20 de octubre de 2026, 23:24:41 CEST / 21:24:41 UTC. Btime nativo 1792531481 y nuevo boot del padre <REDACTED_UUID>, conservado antes/después de las lecturas seleccionadas. Sustituye al epoch 82d105f6… observado en el evento 9; las guardas de ese epoch anterior no se relajan para nuevas mutaciones.

A las 23:26:43.731429 CEST el kernel actual devolvió dos registros seleccionados, sin truncado señalado: SP5100, firma literal hardware watchdog timer expired, reset 0x02000800 y /sys/class/watchdog/watchdog0/bootstatus=32. Acreditan el mecanismo reportado por el watchdog; no identifican la causa de perder los keepalives. No se atribuye a instalación, Git, temperatura, carga o hardware concreto, ni se presenta como reinicio ordenado.

El último registro retenido del journal previo tiene boot <REDACTED> y timestamp 1792531444690204 µs: 23:24:04.690204 CEST / 21:24:04.690204 UTC. Sólo se devolvieron identidad y timestamp, no su mensaje. Los 36,309796 s hasta btime no miden duración del cuelgue: pueden incluir registros no persistidos, reset y arranque. Esta lectura tampoco acredita ausencia de una secuencia ordenada en todo el journal anterior.

Arranque automático de VM208

La muestra PVE de 23:25:55.618518 CEST / 21:25:55.618518 UTC observó uptime del padre 74,59 s y VM208 running, qmpstatus=running, uptime 41 s y sin lock. No había tareas seleccionadas startall/qmstart208 activas en la consulta acotada. En las últimas 20 tareas archivadas constaban:

Tarea	Inicio CEST	Fin CEST	Resultado
startall	23:25:01	23:25:20	OK
qmstart, VM208	23:25:16	23:25:20	WARNINGS: 1

Handles exactos conservados en el recibo privado: startall UPID:proxmox:000007F7:00000820:6AD7DC2D:startall::root@pam: y qmstart208 UPID:proxmox:00001356:00000E07:6AD7DC3C:qmstart:208:root@pam:. Son terminales; no hay un handle vivo de esas tareas que esperar. El contenido del warning no se consultó y no se deduce su causa del estado final.

Metadata seleccionada: VM208 onboot=1, startup=order=6, sin lock y sin recurso HA vm:208. La observación inicial de VM208 stopped es compatible con la ventana de arranque automático; no acredita un fallo permanente ni requiere atribuirle una parada manual. No se inició, reinició o migró ningún invitado como parte del diagnóstico. Running no demuestra recuperación funcional de Docker ni de sus aplicaciones.

El coordinador registró un postcheck independiente a las 23:26:57 CEST: nuevo boot del huésped 11f4…, fuente PR87 persistida y controles conservados. El alcance y los recibos de esa operación permanecen en el canónico de copias originales; no se convierten aquí en inventario nuevo ni prueba end-to-end del homelab.

Recibos seleccionados y límites

Directorio privado ~/.local/state/watchdog-event10-20261020-fgc56zy_/, modo 0700; archivos modo 0600. Son resúmenes seleccionados registrados a partir de los resultados nativos de herramientas, no logs brutos ni una segunda lectura para documentar. No incluyen mensajes de journal, config completa, secretos ni apertura de /dev/watchdog.

Archivo	SHA256
startup.json	<REDACTED>
startup-policy.json	<REDACTED>
reset.json	<REDACTED>
receipt.json	<REDACTED>

Sólo se consultaron uptime/boot, estado y políticas seleccionadas de VM208, tareas de inicio, pertenencia HA, firmas del kernel actual y metadata del último registro retenido anterior. Sin cambios de runtime, arranques manuales, NAS, pruebas de carga ni inventario general. La causa del reset y la estabilidad futura continúan sin acreditar.

Pulso del receptor tras el evento 10, lectura de 23:29:06 CEST

Una única lectura pasiva del receptor pmx2, boot 86184726… conservado antes y después, limita ambos archivos existentes a sus últimos 8 MiB y la ventana 23:23:30–23:25:30. Los slices cubren esa ventana, con inode estable, sin filas truncadas ni prefijos desconocidos. Se separan 46 pulsos PRE y 39 POST por la caída del uptime; el pulso no contiene UUID y no sustituye el btime nativo.

Último PRE a 23:24:15, uptime16750,53s: Tctl49,1°C (rango47,6–50,2), memoria disponible13780MiB (mínimo13668), PSI CPU some avg10 último0 y máximo0,18; PSI memoria/IO some/full0, NVMe live en46/46 muestras y paquete11,9W (rango10,3–14,4). No muestran presión sostenida en esas últimas muestras, pero no excluyen un cambio posterior o congelación parcial. Primer POST a 23:24:53, uptime11,45s: estima boot23:24:41,55 en reloj del receptor.

Las firmas seleccionadas de watchdog/mux expiry, lockup, OOM, NVMe IO y térmicas no aparecen en la ventana leída de journal_stream/netconsole. Ese resultado no acredita ausencia global de errores ni keepalive: el lector no extrae último journal PRE ni campos efectivos para la cadena cliente→mux→hardware. El pulso posterior al último journal retenido tampoco demuestra que el mux progresara. Sin nuevas sondas, instrumentación, acceso al NAS ni cambios de servicios. Proyección privada ~/.local/state/watchdog-e10-pulse-y8_rz5pf/projection.json, SHA256 <REDACTED>; sólo agregados y metadatos, sin logs brutos guardados.

Advertencia de la tarea de arranque VM208

La lectura acotada del log terminal a23:31:34 CEST recuperó una línea marcada WARN entre14 filas: EFI disk without 'ms-cert=2023k' option. El filtro no conservó la continuación sin prefijo WARN; no se completa ni se interpreta aquí como mensaje íntegro. Es metadata de certificados EFI, sin demostrar estado Secure Boot/enrollment ni causa del reset del host. El arranque había terminado y VM208 estaba running. No se modificó EFI, disco ni configuración. Recibo seleccionado qmstart-warning.json en el directorio privado del evento10, SHA256 <REDACTED>.

Observación posterior — 21 octubre, 09:40 CEST

Una guarda de propietario/boot previa a preparar los helpers de Pillow en CT281 rechazó el boot esperado10196 antes de acceder al guest. Una lectura nueva y acotada identifica hostname proxmox, boot <REDACTED_UUID>, btime21oct06:25:34CEST y uptime11712.84s al observar09:40:46CEST. Los recursos208,280 y281 figuran running en proxmox. El kernel del boot actual contiene el literal «hardware watchdog timer expired» y watchdog0/bootstatus32. Esto acredita otra expiración; no identifica la causa de la pérdida de keepalive ni enumera posibles reinicios entre la observación del evento10 y este boot. No se asigna un número consecutivo sin esa cronología.

No se cambiaron watchdog, firmware, BIOS, GRUB, RAM, discos ni orden de arranque. La intervención de Pillow no llegó a parar ni modificar la API. Recibo privado ~/.local/state/wp-pillow-selective-plan-iy3th4es/parent-change-readback.json. La lectura posterior09:41 acredita WP activo PID834, inicio06:26:11, NRestarts0; su alcance es proceso/metadatos, no salud E2E.

Cinco boots adicionales retenidos — lectura 21 octubre, 09:57–09:58 CEST

journalctl --list-boots devuelve98 boots retenidos. El UUID del evento10 aparece con índice-5 y el boot actual con0: hay cinco boots posteriores identificados individualmente. Se leyeron después sólo las líneas del kernel que coinciden con watchdog, máximo16 por boot. Los cinco contienen el literal hardware watchdog timer expired. Se acredita el mecanismo reportado en esos arranques; no que todas las pérdidas de keepalive tengan una misma causa.

Boot UUID retenido	Primera entrada de journal, CEST	Última entrada en esa lectura, CEST	Literal de expiración
<REDACTED>	21oct02:45:42	21oct03:50:46	Sí
<REDACTED>	21oct03:51:34	21oct04:57:19	Sí
<REDACTED>	21oct04:57:55	21oct05:43:31	Sí
<REDACTED>	21oct05:44:03	21oct06:25:01	Sí
<REDACTED>	21oct06:25:36	21oct09:57:38	Sí

Estas horas son extremos del journal retenido, no btime/shutdown nativos ni duración de un cuelgue. La salida nativa de list-boots emitió CEST pese a la opción--utc; se conserva esa zona literal. El primer recibo usaba un nombre de campo terminado en_utc incorrecto: se preserva y se añade projection-v2 con el nombre corregido, sin convertir las horas como si fueran UTC. La hora UTC de observación sí procede del reloj de la consulta.

Directorio privado: ~/.local/state/watchdog-retained-boots-20261021-qg368x3p/. kernel-five-boots.json SHA256 <REDACTED>. Guarda de hostname/boot actual antes y después de cada lectura. No se alteraron servicios, watchdog, firmware, BIOS, GRUB, RAM ni invitados. Falta reconstruir la cadena de keepalive y los últimos registros anteriores a cada transición; esta lectura no demuestra calor, carga, fsync, NFS ni fallo físico como causa.

Correlación anterior al último reset — lectura 21 octubre, 10:12–10:14 CEST

Se consultó el boot anterior <REDACTED>, ventana 06:23:00–06:25:36 CEST, mediante epochs explícitos: identificador watchdog-mux, máximo60 entradas, y unidades pve-ha-lrm/pve-ha-crm/corosync, máximo120. Ambos selectores devolvieron cero entradas, sin alcanzar límites. La consulta del mux para todo ese boot conserva sólo dos líneas de arranque, PID1486, carga de sp5100_tco y driver SP5100. No conserva conexión, caducidad ni desconexión de clientes. La ventana de arranque de HA05:43:58–05:47:05 contiene nueve entradas: CRM1901 pasa startup→wait_for_quorum→slave; LRM2003 pasa a wait_for_agent_lock. No se identifica un cliente armado ni una orden de fencing para este reset; la ausencia de registros no excluye eventos sin persistir. Estas consultas quedan resueltas y no se propone repetirlas para el mismo boot/ventana.

El peer pmx51 conserva boot86184726 antes y después. Se leyeron una sola vez los últimos8MiB de cada receptor existente, filtrando únicamente pmx50 y la ventana21oct06:23:30–06:26:30CEST. Receptores verificados por unidad/ejecutable/ destino; logs regulares root/nlink1 con mismo inode y tamaño no decreciente. Los fragmentos cubren la ventana requerida. Las96 muestras PRE llegan hasta 06:25:06, uptime2465.35s; las46 POST empiezan06:25:45, uptime11.62s.

Métrica	Antes: máximo / último	Después: máximo
Tctl	49,9 / 48,4 °C	56,1 °C
PSI CPU some avg10	0,18 / 0,01	27,45
PSI memoria some/full avg10	0 / 0	0,18
PSI E/S some avg10	0 / 0	7,69
PSI E/S full avg10	0 / 0	4,93

MemAvailable PRE mínimo13705MiB, último13839MiB; NVMe live96/96 muestras PRE. No hay presión sostenida seleccionada antes del corte. Los máximos de presión POST pertenecen al arranque siguiente y no se usan como explicación del reset previo. Las firmas seleccionadas de error hardware, lockup, OOM, NVMe/E/S, caducidad del mux y aviso térmico no aparecen en estas ventanas recibidas; no es prueba de ausencia global. El intervalo entre última muestra recibida y btime del host no es duración de cuelgue ni edad del último keepalive.

Evidencia privada ~/.local/state/watchdog-pre0625-ulrsh6lu/: projection.json SHA <REDACTED>, mux-startup.json SHA <REDACTED>, peer-projection.json SHA <REDACTED>. Sin escrituras ni aperturas de watchdog, cambios de HA, sondas NAS, nuevas capturas persistentes o reinicios manuales de observadores.

Corrección acotada del diagnóstico de memoria de pulso

La fuente desplegada antes de esta corrección coincidía por SHA con Git: <REDACTED>. La llamada original ignoraba el retorno de mlockall y sólo capturaba OSError. La API devuelve0 en éxito y-1 con errno en error; el retorno debe comprobarse. Véanse mlockall(2) y ctypes, retorno y errno.

El cambio comprueba ese retorno, declara el prototipo C y añade al paquete PULSO-INICIO mlockall=ok|failed|unavailable y mlock_errno=N. Éxito informa errno0, sin reutilizar un errno anterior. Si falla, el emisor continúa como antes y hace visible que no se consiguió el bloqueo; no cambia los flags3, el intervalo1s, el límite UDP ni las rutas de reenvío. Los comentarios dejan de presentar la expiración hardware como prueba de congelación global o garantizar que UDP/última muestra reconstruyan el instante del reset.

La observación anterior del proceso PID1424 mostraba LimitMEMLOCK=infinity y VmLck94552kB, NRestarts0 desde06:25:38. Sí hay memoria bloqueada observada en este proceso: el defecto de reporte no demuestra que mlockall fallara en este boot ni causara ningún reset. Cuatro fixtures aislados comprueban retorno0 con errno viejo, retorno-1/EPERM/ENOMEM sin excepción, biblioteca no disponible y paquete inicial ante fallo. No llaman al mlock real, red, kernel ni hilos. El workflow existente de capacidad/recuperación incluye estas pruebas en3.10/3.12.

La PR95 se integró a10:24:02CEST, main <REDACTED>. Todas sus comprobaciones pasaron; los checks posteriores a main también: capacidad y recuperación, Ansible-lint y documentación. El publicador identifica a23d589 como revisión construida; el build local estricto también pasó. Recibo privado source-merged.json/source-publication.json.

El playbook existente reinicia sólo pulso-tx si cambia su archivo en un ciclo normal. No se forzó Ansible-pull ni se ejecutó el rol completo como prueba. La observación posterior confirma despliegue ordinario a las 10:32:39 CEST: fuente SHA <REDACTED>, PID560740, NRestarts0 y VmLck94468kB, con parent boot c4c64375… estable. El receptor existente en pmx51, boot 86184726… comprobado antes/después, conserva el paquete real:

2026-10-21 10:32:39 192.168.0.XXX proxmox PULSO-INICIO pid=560740 mlockall=ok mlock_errno=0

La observación temporal terminó tras 17 lecturas acotadas. El primer lector del marcador terminó en AssertionError y se conserva; una lectura posterior validada encontró el paquete sin enviar UDP sintético. El cambio queda cerrado en fuente y runtime; no demuestra causa resuelta de los reinicios ni mide los keepalives del watchdog hardware.

Recibos privados en ~/.local/state/watchdog-pre0625-ulrsh6lu/: observer-stream.ndjson SHA <REDACTED>, runtime-marker-diagnostic.json SHA <REDACTED>, y cierre runtime-closed.json. El nombre de este directorio corresponde a la investigación original; cada recibo conserva su propia hora y alcance.

Nuevo arranque: 21 de octubre, 11:56:40 CEST

Una guarda de observación de originales detectó a las12:04:12 CEST que el boot de pmx50 había cambiado a <REDACTED_UUID>. Abortó antes de entrar en VM208; su estado running no se presentó como continuidad de trabajo. La entrega del frontend WP-Pulse no había comenzado y no se ejecutó después con las guardas antiguas.

La lectura nativa de las12:12:16 CEST conserva el mismo boot antes/después: btime1792576600, 11:56:40 CEST / 09:56:40 UTC. El kernel registra a las 11:56:42,660289 CEST el literal:

x86/amd: Previous system reset reason [0x02000800]: hardware watchdog timer expired

watchdog0 informa bootstatus32, identidad SP5100 TCO timer, timeout10 y estado active. Son lecturas de metadatos: no se abrió el dispositivo ni se modificó HA/watchdog. Acreditan el mecanismo reportado; no identifican cliente, bloqueo ni causa de la pérdida de keepalives. La corrección anterior del reporte de mlock de pulso no puede presentarse como solución a estos resets.

Recibo privado ~/.local/state/pmx-transition-20261021-rcie04n7/current-native.json, SHA256 <REDACTED>.

Ventana previa de este evento, sin repetir las ventanas anteriores

La lectura acotada de las 12:12:49 conserva el último registro retenido del boot c4c64375… a las 11:56:10,062616 CEST. Los selectores de HA y kernel para 11:51:40–11:56:40 devolvieron cero filas; esto describe los selectores y la retención, sin demostrar ausencia global de fallo. El primer lector falló por la sintaxis guionada del UUID; se conserva como fallo de lectura y se corrigió sólo la sintaxis del mismo boot.

En el peer, con boot 86184726… estable, las colas existentes de hasta 8 MiB por receptor contienen 273 muestras PRE, 11:51:40–11:56:14, y 108 POST desde 11:56:53. La separación de recepción de 39 s no mide duración de congelación ni identifica el último keepalive hardware. PRE: Tctl 46,9–53,6 °C, último 47,5; MemAvailable mínimo 12.767 MiB y último 13.753; PSI CPU some avg10 máximo 0,18, memoria some/full 0, E/S some/full máximo 0,18. NVMe live en las 273 muestras. No se acredita presión seleccionada sostenida antes del corte; el incremento POST pertenece al arranque siguiente. No aparecen las firmas de error seleccionadas en esas ventanas; la cadena cliente→mux→hardware continúa sin observación suficiente para identificar causa.

Mismo directorio privado: previous-selected-v2.json, SHA256 <REDACTED>, y peer-transition.json, SHA256 <REDACTED>.