Arranque adicional de pmx50 a las 13:35 del 20 de octubre de 2026¶
Detectado por lectura nativa a las 14:52:30 CEST, después de los cinco arranques nocturnos ya documentados. /proc/stat registra btime=1792496118, equivalente a 13:35:18 CEST / 11:35:18 UTC. El boot ID actual es <REDACTED_UUID>; el anterior era <REDACTED_UUID>. Esta evidencia corrige la continuidad del arranque que se venía suponiendo, sin trasladar retrospectivamente al nuevo boot las observaciones del anterior.
Cronología acreditada¶
Lectura independiente nativa a las 14:54:03: mismo boot actual, uptime 4725,94 segundos. journalctl --list-boots muestra el boot anterior desde las 02:13:43 hasta las 13:34:46, seguido directamente por el actual desde las 13:35:20. No aparece otro boot entre ambos. Son primeros/últimos registros retenidos, no el instante exacto de interrupción.
| Evidencia | CEST | UTC | Alcance |
|---|---|---|---|
| Último registro local retenido del boot anterior | 13:34:46,538392 | 11:34:46,538392 | Journal, boot 834ae68a…; no equivale a último keepalive |
| Último pulso PRE recibido por pmx51 | 13:34:50 | 11:34:50 | Uptime emisor 40869,71 s; demuestra avance de ese proceso |
| Primeros mensajes de pérdida de enlace en corosync del peer | 13:34:57,463–464 | 11:34:57,463–464 | Observación del receptor, no causa demostrada |
| Nuevo btime nativo | 13:35:18 | 11:35:18 | /proc/stat del boot actual |
| Primer journal del nuevo boot | 13:35:20,427667 | 11:35:20,427667 | Boot cff5c198… |
| Primer pulso POST recibido | 13:35:29 | 11:35:29 | Uptime 11,86 s; separado del segmento PRE |
| Nuevos mensajes de enlace y membresía del peer | 13:35:36–38 | 11:35:36–38 | Reincorporación observada; no prueba de recuperación completa |
La ventana local 13:32–13:36 contiene 2147 registros y 1.022.316 bytes: 39 filas del boot anterior y 2108 del actual. No se encontraron las firmas acotadas de apagado ordenado, OOM o panic/lockup. El último kernel retenido del boot anterior corresponde a las 02:24:55,882878: no hay una traza kernel próxima al corte en esta lectura. La ausencia de firmas no descarta eventos que no llegaron al journal.
Watchdog y receptor: mecanismo frente a causa¶
El arranque actual registra estado hexadecimal 0x02000800 en un mensaje de watchdog y /sys/class/watchdog/watchdog0/bootstatus devuelve 32. Se leyó sysfs, sin abrir /dev/watchdog. La interpretación del driver y su límite causal se aplica también aquí: es evidencia compatible con el mecanismo de reset reportado por el watchdog; no identifica qué dejó de alimentar el dispositivo, el cliente implicado ni una causa de RAM, CPU, Ansible o firmware. No se ha modificado configuración ni instrumentación.
La lectura del peer a las 14:59:03 conserva su boot <REDACTED_UUID>. Su journal acotado tiene 26 filas de corosync/HA/watchdog-mux en la ventana, con cambios de enlace y membresía. El clasificador no encontró firmas de fencing explícito, pérdida de quorum o expiración de cliente; no es una demostración de que esos mecanismos no intervinieran fuera de lo retenido o de las firmas buscadas.
Se leyeron sólo las colas de 8 MiB de /var/log/pulso-nodos.log y /var/log/netconsole.log, después de verificar archivos regulares root, un enlace y descriptor sin seguir symlinks. Las porciones leídas abarcan la ventana según sus prefijos de recepción. Se toleró crecimiento por append, conservando identidad y el límite inicial; no se recorrieron rotaciones ni se persistieron mensajes completos.
El pulso PRE contiene 170 muestras entre 13:32:00 y 13:34:50. Temperatura CPU 47,2–51,0 °C, última 48,6 °C; MemAvailable 11977–12953 MiB, última 12893 MiB; SwapFree 6418 MiB; lag 0,01–0,02 s. El POST contiene 31 muestras desde 13:35:29 hasta 13:36:00. Estos valores no descartan un pico posterior, no representan a todos los procesos y no prueban progreso de HA o watchdog-mux. El pulso PRE avanza unos 3,46 segundos después del último journal local; no permite calcular el último ping del watchdog ni inferir la hora de boot restando uptime de la recepción UDP.
Ansible: correlación previa y avería posterior distinta¶
La unidad ansible-pull.service del boot anterior sólo conserva dos filas en 13:30–13:35, a las 13:34:45,372581 y 13:34:46,538392. No hay TASK, recap ni módulo de rol acreditado en esa ventana. Su proximidad al corte es correlación y no acredita que un rol ejecutara reboot, cambiara HA/watchdog o causara el reset.
Una investigación separada del estado actual encontró pmx con último intento de 14:45:37–44, salida 2. StandardOutput/StandardError apuntan al journal; no se encontró un logfile adicional en la proyección seleccionada de la unidad. El journal de ese intento tiene 31 filas y muestra fallo del módulo Git en fetch, con changed=false, objeto vacío e invalid index-pack. No llegó a TASK/recap del playbook. No se publicaron SHA de objetos, comandos completos, URLs, argumentos, resultados íntegros ni valores secretos. Esto acredita una avería de sincronización del checkout, sin demostrar que el reset la causara ni que ese fallo posterior causara el reset.
pmx2 mostró un intento natural distinto, 14:53:29–14:54:35, resultado success y salida 0. No se ha ejecutado pull, fetch, fsck, reparación ni reintento manual en ningún nodo. El timer observado en pmx seguía active/waiting, Persistent=yes, RandomizedDelay=2 min, Accuracy=30 s y OnBoot=5 min; son metadatos actuales, no prueba de qué cadencia disparó el intento previo al reset.
La fuente Git actual incluye acciones condicionales de reinicio de journald, pulso/logind y generación de GRUB en power_safety; también contiene instalación de paquetes con state: present. Esas definiciones no acreditan que se ejecutaran en el intento anterior. La siguiente acción útil es revisar la integridad del checkout afectado sin borrar ni forzar el estado actual, bajo un plan independiente; no repetir diagnósticos generales ni intervenir en HA/watchdog por esta correlación.
Evidencia y límites operativos¶
Proyecciones privadas, directorio 0700 y archivos 0600 en ~/.local/state/pmx50-new-boot-20261020-x9fcrtsz/:
| Archivo | SHA256 |
|---|---|
| native-boots.json | <REDACTED> |
| native-journal.json | <REDACTED> |
| watchdog-signature.json | <REDACTED> |
| peer-window.json | <REDACTED> |
| ansible-window.json | <REDACTED> |
| ansible-git-final-class.json | <REDACTED> |
Cada consulta de journal tuvo límite de salida de 2 MiB y 10 s; el diagnóstico del fallo Ansible se restringió a 256 KiB y su ventana exacta. Los mensajes completos sólo se procesaron en RAM; los ficheros retenidos contienen fechas, clases y contadores. No hubo escrituras remotas, reinicios, nuevas sondas, estrés, lecturas de productos, cambios de hold ni tareas de Vera/HA. El instalador del publicador quedó pausado y sin ejecutar. Este informe no acredita estabilidad continua posterior ni causa raíz.