Nuevo arranque de pmx50 a las 15:55 del 20 de octubre de 2026¶
Confirmación nativa¶
La lectura de las 15:56:35,271966 CEST confirma otro arranque de pmx50:
/proc/stat registra btime=1792504504, equivalente a 15:55:04 CEST /
13:55:04 UTC, boot ID <REDACTED_UUID> y uptime
91,24 segundos. Es distinto del arranque de las 15:11:50,
boot decded74….
Es el octavo arranque registrado en esta secuencia: cinco nocturnos y los de
13:35, 15:11 y 15:55. La lectura posterior de las 15:57:41,512193 CEST
confirma la firma de expiración del watchdog hardware en el kernel actual,
SP5100, estado 0x02000800 y watchdog0/bootstatus=32. Esto acredita el mecanismo
reportado; no identifica la causa de perder los keepalives ni el proceso,
cliente o CPU implicado. No se atribuye la causa a Ansible, Git ni a las lecturas.
Journal retenido y unidad Ansible¶
| Evidencia | CEST | UTC | Alcance |
|---|---|---|---|
Último journal PRE, boot decded74… |
15:54:27,810080 | 13:54:27,810080 | Límite de registros retenidos, no último keepalive |
| Btime actual | 15:55:04 | 13:55:04 | Lectura nativa de /proc/stat |
Primer journal POST, boot 248d8d61… |
15:55:06,246425 | 13:55:06,246425 | Boot ID comprobado |
Los últimos40 segundos del journal retenido PRE, 15:53:47,810080–15:54:27,810080, contienen35 filas sin truncado señalado. La proyección cuenta cero registros de prioridad≤3 y cero errores de la lista seleccionada. Ese resultado se limita a las filas conservadas y al filtro: no descarta fallos globales, pérdida de logs ni actividad posterior al último registro. La evidencia del receptor sigue pendiente; no se infiere una secuencia completa a partir del silencio local.
A las15:57:41, ansible-pull.service aparece inactive/dead, Result=success,
ExecMainStatus=0, con InvocationID y timestamps de inicio/fin vacíos. No acredita
una ejecución en el boot actual. El timer sigue active/waiting, sin modificación,
con próximo vencimiento estimado alrededor de las16:01:38,53 CEST. LastTrigger
15:50 es histórico y no demuestra ejecución posterior al reset. No se forzó pull,
start ni reintento.
Evidencia anterior conservada¶
El primer pull natural posterior a la reparación de la caché terminó correctamente a las 15:50–15:51, rc0, 71 ok / 0 changed / 0 failed, con caché en a98a9ad y status limpio en alcance normal. Ese resultado sigue siendo válido para el boot anterior; no acredita continuidad después de las 15:55 ni recuperación de invitados o aplicaciones tras este nuevo arranque.
El endurecimiento core.fsync=all / core.fsyncMethod=fsync seguía sólo en
planificación: no se aplicó. El preflight se detuvo con boot_changed antes
de leer la configuración. No se atribuye eficacia ni fallo a una configuración
que no se instaló.
Evidencia y límites¶
Proyección privada ~/.local/state/git-workingtree-restore-20261020-m9hyfrod/newboot-quick.json,
SHA256 <REDACTED>.
Su fecha nativa es 13:56:35,273014892 UTC y la proyección está fechada
13:56:35,271966 UTC. Se conservan ambos relojes de la misma observación.
La redacción usa únicamente la evidencia retenida. Las lecturas de observación no forzaron reparación, pull, job, sondeo, reinicio, configuración de fsync ni modificación de watchdog/HA; el ciclo natural posterior se registra abajo. La causa y el impacto posterior siguen pendientes; no se declara estabilidad.
La proyección forense separada newboot-forensics.json, en el mismo directorio
privado, tiene SHA256
<REDACTED>.
Conserva sólo metadatos y clasificaciones; no guarda mensajes crudos. La lectura
no abrió /dev/watchdog ni leyó o escribió configuración. Los
límites del driver y de la captura
siguen siendo aplicables: mecanismo reportado no equivale a causa raíz.
Continuidad nativa del peer: 15:58:02 CEST¶
La muestra independiente de pmx51 mantiene boot ID
<REDACTED_UUID>, btime1792439931 y uptime64750,44 s.
Es sólo una instantánea de continuidad de ese peer; no incluye una consulta de
pulsos ni correlación causal del reset de pmx50. Proyección privada
newboot-peer-quick.json, SHA256
<REDACTED>,
en el mismo directorio de evidencia.
Primer pull natural posterior: 16:01:41–16:02:28 CEST¶
El timer inició naturalmente ansible-pull.service a las 16:01:41 CEST.
La observación de las16:01:44 lo encontró activating/start, boot 248d8d61…,
InvocationID <REDACTED>. Se siguió esa misma ejecución,
sin forzar start, fetch, pull ni reintento.
A las 16:02:31,168669 CEST, el mismo boot y la misma InvocationID mostraban inactive/dead, Result=success, ExecMainStatus=0 y fin 16:02:28 CEST. Los354 registros de esa invocación no señalan truncado; contienen un recap de 71 ok / 0 changed / 0 failed / 0 unreachable / 17 skipped, sin errores de las clases seleccionadas. Git, Ansible y cmdlines ilegibles contaban cero antes de leer la caché y seguían ausentes al terminar la observación.
HEAD y origin/main coincidían en
<REDACTED>; git status --porcelain=v1 -z
--untracked-files=normal, sin optional locks ni fsmonitor, devolvió rc0 con cero
registros tracked y untracked. El timer seguía activo. Esta lectura acredita el
resultado de ese ciclo y el estado de la caché en ese instante; no prueba salud
de aplicaciones, todos los descendientes untracked, recuperación completa de
invitados ni estabilidad posterior del host. El mecanismo de reset reportado
no tiene causa raíz resuelta y fsync continúa sin aplicar.
Proyección privada0600 natural-1555-140231.json, en el mismo directorio de
evidencia, SHA256
<REDACTED>.
No se conservaron mensajes crudos del journal ni se modificó configuración.
Loki: observación histórica acotada a las 17:56 CEST¶
El inventario de septiembre todavía situaba Loki en VM208; no se usó como propietario actual. El perfil observado de Observa y ADR27 apuntaban a CT217. La API revalidó CT217 running en proxmox2 a las 17:56:22.376281 CEST. Docker, inspeccionado sólo con campos seleccionados, confirmó Loki ya en marcha, no pausado y con el puerto 3101 publicado. No se arrancó el servicio ni se leyó su configuración o entorno.
Una sola consulta local a Loki terminó HTTP 200 a las 17:56:23.763684 CEST.
Selector exacto: host="proxmox-50",job="systemd-journal"; intervalo
13:53:30–13:55:10 UTC / 15:53:30–15:55:10 CEST. El filtro seleccionó kernel,
watchdog, lockup, nvme, fencing, OOM o panic, sin distinguir mayúsculas. Límite 100,
respuesta máxima 2 MiB, límite de 8 s y redirects desactivados; sin consulta de labels,
otros clientes, journal general, configuración ni nuevos colectores.
La respuesta de 17.202 bytes contiene 92 coincidencias, menos que el límite
solicitado. Todas sus fechas Loki caen entre 13:55:06.246451 y 13:55:09.761803
UTC, después del btime nativo 13:55:04 del arranque 248d8d61….
| Categoría de texto | Coincidencias | Con timestamp anterior al btime | Con timestamp igual o posterior |
|---|---|---|---|
| kernel | 55 | 0 | 55 |
| watchdog | 14 | 0 | 14 |
| nvme | 25 | 0 | 25 |
| lockup / fencing / OOM / panic | 0 cada una | 0 | 0 |
Las categorías pueden solaparse. No hay cobertura PRE acreditada: cero coincidencias anteriores en este selector/filtro no prueba ausencia de errores, retención completa ni entrega de todos los logs. El significado y origen exactos del timestamp Loki no se verificaron independientemente; no se convierten las fechas devueltas en prueba autónoma de cuándo se generó cada mensaje. Tampoco se atribuye una causa al conteo de nvme/watchdog ni se declara el host limpio.
Las líneas originales sólo se procesaron en RAM. Se conservaron categorías,
hashes de líneas y timestamps, sin mensajes ni labels adicionales, en proyección
privada 0600 ~/.local/state/loki-reset-window-20261020-npnjnik7/projection.json,
SHA256 <REDACTED>.
El resumen segmentado contra el btime conocido tiene SHA256
<REDACTED>.
La consulta no repitió lecturas de hosts, no generó jobs ni modificó servicios.
Continuidad nativa a las 17:58 CEST¶
La lectura ya conservada de las 17:58:32.386589 CEST confirma el mismo boot
<REDACTED_UUID> y uptime 7408,36 segundos. Acredita
continuidad de ese arranque hasta la muestra; no resuelve la causa de los resets
anteriores ni garantiza estabilidad posterior.
ansible-pull.service registró inicio natural a las 17:54:45 y fin a las
17:55:31 CEST, InvocationID <REDACTED>. En la
observación estaba inactive/dead, MainPID=0, Result=success y ExecMainStatus=0.
Esto acredita el resultado de la unidad para esa invocación. No se leyó recap,
Git, configuración ni aplicaciones, por lo que no se deducen tareas ejecutadas,
cambios, hashes actuales de la caché ni salud del homelab a partir del rc0.
No se inició, reinició o repitió ningún job.
Proyección privada 0600
~/.local/state/pmx50-native-status-20261020-6la32rc8/projection.json, SHA256
<REDACTED>.
Este apartado se redactó desde ese archivo, sin nueva consulta remota.
La aplicación posterior de fsync y sus límites
se conserva como fase independiente: no convierte los resultados anteriores ni
esta lectura de unidad en prueba de causa raíz o de integridad de aplicaciones.
Pulso remoto del octavo evento: lectura 18:17 CEST¶
Una lectura del receptor proxmox2 a las 18:17:36,957984 CEST revalidó pulso-rx y netconsole-rx active/running con ejecutable y destinos previstos. Sólo abrió los dos logs existentes: pulso completo28.211.422bytes y un tail de 33.554.432bytes del journal remoto, desde offset5.886.397. Ambos conservaron inode y tamaño, sin append ni fragmento final; se descartó el fragmento inicial del tail. La selección fue 15:53:30–15:55:30 CEST, emisor .50; no se conservaron líneas crudas, ni se cambiaron servicios o watchdog. Presupuesto32MiB por archivo, 15s por lectura y filas16KiB; cinco comprobaciones sintéticas previas cubrieron segmentación, ventana, origen, tail parcial y rechazo de symlink.
| Segmento del pulso | Recepción CEST | Filas | Uptime emisor |
|---|---|---|---|
| PRE | 15:53:30–15:54:37 | 67 | 2500,77→2567,24s |
| POST | 15:55:15–15:55:30 | 16 | 11,68→26,78s |
La caída de uptime mantiene ambos segmentos separados. El último PRE se recibe aproximadamente9,19s después del journal local retenido15:54:27,810080. Amplía la evidencia de progreso del proceso emisor más allá del corte del journal; no demuestra progreso del mux/HA, éxito del ioctl keepalive, instante del cuelgue ni que journald o disco fallaran. El formato UDP carece de boot_id y fecha de emisión; hora de recepción del peer no equivale a hora exacta de ejecución y puede sufrir pérdida, retraso, reordenación o desfase de reloj.
En las67 PRE, Tctl47,2–51,5°C (última51,2), MemAvailable13.519–14.243MiB (última13.519), PSI memoria full avg10=0 y PSI IO full avg10=0–2,57% (última0,02%). Lag impreso0,01s y NVMe state live en todas; esos valores no certifican salud del dispositivo ni excluyen cambios posteriores. No se mezclan los máximos POST con PRE. Las100 filas del flujo pulso incluyen17 KMSG en la ventana total; no se les atribuye un boot específico. El journal remoto aporta 119 filas de la ventana, sin boot acreditado. Ninguno de los dos flujos coincide con las firmas seleccionadas de hardware, lockup, NVMe-timeout, IO, OOM, expiración de cliente, salto de reloj o aviso térmico; no excluye otras señales ni errores perdidos/no registrados. No se midió el último latido del watchdog.
Proyección privada0600
~/.local/state/watchdog-e8-pulse-20261020-61zap1yo/projection.json, SHA256
<REDACTED>.
Lector privado SHA256
<REDACTED>.
No se abrieron rotaciones, datastore/NAS, /dev/watchdog ni nuevas sondas;
la causa del octavo reset sigue pendiente.