PBS sync-check: fuente recuperada y selección fiable — 19 octubre 2026¶
Preparación y despliegue autorizado 23:38–23:49 CEST por agente, sin commit ni
push. Fuentes propias en scripts/pbs-sync-check/, este informe y únicamente
la hora descriptiva de la alerta existente. No se
lanzaron jobs PBS, backups, restores, cambios de storage, timers ni pings de
éxito. El checker normal no se ejecutó contra Pushgateway real.
Procedencia y observación¶
Owner resuelto por /cluster/resources: CT186 pbs running en proxmox
(pmx50). Fuente viva root:root0755 /usr/local/bin/pbs-sync-check.sh, importada
exacta como scripts/pbs-sync-check/original-20261019.sh. SHA256 comprobado:
<REDACTED>.
El servicio usa ese script y timer diario07:00, Persistent=true. Contador
/var/lib/pbs-sync-check-fails observado0. POST existente a
http://192.168.0.XXX:9092/metrics/job/pbs_sync_check; no se modificó. Regla
versionada conserva umbral>=2, aunque su descripción aún dice06:25. Por autorización posterior se cambió únicamente esa hora descriptiva a07:00
en fuente; no expresión, umbral, canal ni configuración viva de alertas.
La CLI manager instalada admite limit1–1000 pero no offset. Se consultó la
API usage y se verificó con GET que proxmox-backup-debug api get
/nodes/localhost/tasks soporta typefilter, start, limit, running y until.
Worker exacto observado local-self:main:archive::main-to-archive.
Último sync completado observado: inicio1792382400, fin1792384184, statusOK
(19oct06:00→06:29:44 CEST). Estos datos no demuestran restauración.
Corrección candidata¶
Se conserva launcher .sh para mantener ExecStart y se incorpora helper
Python estándar sin dependencias adicionales. API filtrada por syncjob,
paginación100 filas, máximo20 páginas, deadline total60s y comando<=10s.
La lectura exige llegar a EOF: límite agotado, página repetida, fallo API,
JSON inválido o incoherencia de esquema se distinguen de un sync fallido.
Selección por último endtime de tarea COMPLETADA del worker exacto, no por substring ni por ventana de20 tareas globales. Sólo statusOK y endtime válido reciente permiten éxito. Running/None nunca prueban fin; un fallo completado más nuevo invalida el OK antiguo. Frescura de26h se mide desde fin.
El contador existente se mantiene: incrementa ante chequeo no saludable o indeterminado, y se resetea sólo después de evaluación buena y HTTP correcto. Nuevas métricas separan colección, resultado y último fin. Así los errores de colección activan el criterio existente tras repetirse sin afirmar que PBS falló. No se añadieron alertas ni canales nuevos. La ausencia de entrega HTTP no garantiza aviso remoto: queda salida no cero y contador local, explícitos.
HTTP POST conserva método/job/URL. curl usa fail HTTP, connect3s, max8s y subproceso10s; no redirige errores ni hace retries. Salidas:0 éxito completo, 2 sync ausente/fallido/obsoleto,3 colección,4 error local/HTTP. Counter inválido no se convierte a0; persistencia atómica conserva archivo ante fallos.
Pruebas y límites¶
17 tests únicos pasan, con tareas sintéticas, ejecutables locales simulados
y archivos temporales. Cubren running sin éxito, completed previo mientras
running, fallo posterior a OK, orden por completion, edad desde fin, identidad
exacta, candidato más allá de20 tareas, paginación completa/agotada/repetida,
JSON/schema/API/timeout erróneos, contador/reset/persistencia y HTTP4xx/timeout.
El CLI --inspect se ejecutó contra API falsa y curl falso que falla si se
invoca: no hizo push ni escribió contador.
Además se ejecutó en CT186 únicamente modo --inspect via stdin Python,
sin instalar archivos. Resultado23:46:02 CEST: collection_ok=true, sync_ok=true,
latest_endtime1792384184 y edad62178s. Ese modo no lee/escribe contador ni toca
Pushgateway. Python compile, shell syntax y diffcheck correctos.
El coordinador revisó el código y autorizó el despliegue acotado descrito abajo. Una prueba de HTTP real alteraría métricas y no forma parte de la validación. No se realizó rollback ni se inició el servicio.
Documentación primaria consultada:
CLI oficial PBS y
API oficial, además del
schema api usage de la versión realmente instalada.
Despliegue autorizado y recuperación¶
El coordinador autorizó explícitamente instalar sólo helper y shim, preservar timer/unit/contador/canal y verificar únicamente --inspect. A23:47:53CEST se comprobó de nuevo CT186 en proxmox, servicio inactive/dead con MainPID0, sin procesos checker ni locks PBS previos; timer active con próximo evento20oct 07:00CEST. No hubo parada, reinicio de unidad, start manual ni POST.
Rollback privado /root/rollbacks/pbs-sync-check-20261019T214753Z, directorio
0700 y archivos0600: script original, counter, unidades y manifest. Se instaló
helper primero y shim después mediante rename atómico; comprobación adicional
de servicio inactivo antes del rename. Un fallo de validación habría restaurado
shim y helper previos; no fue necesario.
Hashes instalados:
/usr/local/bin/pbs-sync-check.sh0755:<REDACTED>./usr/local/lib/pbs-sync-check/check.py0644:<REDACTED>.
Counter original0 y las dos unidades permanecen byte a byte iguales. Hashes verificados antes/después: counter9a271f2a…86aa, servicebfb6bb27…f635, timerf27f0484…8a42. --inspect instalado devolvió collection_ok=true, sync_ok=true, último fin1792384184 y edad62289s; no modificó counter ni envió HTTP. Esto no demuestra entrega de métricas de la próxima ejecución natural.
Para rollback restaurar el script original desde ese directorio a su ruta original con modo0755; helper puede quedar sin uso. Preservar contador actual y no sustituirlo por el snapshot histórico. No es necesario tocar unidades ni timer. El rollback recupera también las debilidades originales del checker.
Límite explícito:20 páginas de100 filas filtradas, con deadline60s. Si el historial crece o la API repite páginas, el checker da error de colección; no acepta historia incompleta como éxito. El conjunto observado hoy cabe en una página. La descripción fuente de alerta se reconcilió06:25→07:00, sin expresión ni despliegue de reglas.