Automatismos y errores ocultos — 19 octubre 2026

Lectura viva23:04–23:09CEST. No se han disparado jobs, limpiadores, actualizaciones, pulls Docker, DELETE SQL ni timers. Única preparación local: hacer visibles errores de la tarea AudioMuse en la fuente Ansible; pendiente de despliegue.

AudioMuse: dependencia migrada y error oculto

RunWisp2080.14.0 está healthy, scheduling_active=true, config_stale=false,19tareas, NRestarts0. Consulta realizada con sus rutas reales RUNWISP_CONFIG y RUNWISP_DATA; usar el directorio por defecto .runwisp devuelve falsamente daemon ausente.

audiomuse_dedup_cleanup falló19oct05:17 exit1 en72ms;17/18oct había terminado0. Fuente viva /home/monxas/scripts/audiomuse_dedup_cleanup.sh; no se localizó una copia mantenida en homelab-infra. La declaración de tarea sí está en ansible/host_vars/media-208.yml y coincide con el TOML vivo.

El primer comando hace docker exec navidrome sqlite3 … en VM208. Inspect demuestra que ese contenedor existe pero está exited; el Navidrome de CT218 está running. set -euo pipefail aborta ahí antes de copiar IDs o borrar filas. No se ejecutó el script para reproducir porque su fase posterior modifica BD.

La tarea redirige stdout/stderr a /dev/null; RunWisp conserva exit1 pero pierde el diagnóstico. Preparado cambio local: quitar únicamente esa redirección. YAML validado y comando, horario05:17 y lógica de borrado conservados. No se desplegó ni recargó RunWisp. No se ha trasladado el DELETE a otra fuente.

Actualización posterior del coordinador: retiró la redirección en el TOML vivo y recargó sin reinicio ni ejecución del job. RunWisp confirmó solo el cambio de comando de esa tarea; healthy y config_stale=false. También corrigió el role para proporcionar RUNWISP_CONFIG/RUNWISP_DATA: --socket por sí solo devolvía éxito con «No daemon is running» en el directorio por defecto. Ese resultado ahora se considera fallo. Fuente YAML y playbook syntax-check correctos; no se ejecutó el role completo. Detalle/rollback en coordinación.

Antes de reparar el flujo hay que resolver el contrato Navidrome218→AudioMuse208: origen autoritativo, biblioteca/provider y formato de IDs, rechazar fuente vacía, conteo razonable y límite de borrados, transacción y modo de estimación previo. La lógica actual compara todos los provider_track_id con una lista y DELETE global de no coincidentes; redirigirla sin esos controles puede convertir una lista equivocada/vacía en borrado masivo de mappings. La biblioteca no se borra por ese SQL, pero perder los mappings perjudicaría sus asociaciones.

Actualización automática: fallos de registro visibles

homelab-ctl-2 falló17,18y19oct04:00 exit1. El último duró194,98s. Log19oct: pull de Sonarr/Radarr agotó espera de cabeceras en lscr.io; Bazarr/Prowlarr devolvieron toomanyrequests. No demuestra un fallo de las aplicaciones. homelab-ctl watch23:05 terminó0; Sonarr/Radarr/Bazarr/Prowlarr están healthy. Update/watch son funciones distintas con lock compartido, no tareas duplicadas.

Fuente local cmd_update hace pulls seriales, timeout300s por servicio, sin reintento específico para429/timeout. Remediación siguiente acotada: backoff limitado y jitter para esos errores, respetar Retry-After cuando sea interpretable, mantener errores definitivos y límites del job. No cambiar imagen/tag ni recrear contenedores como prueba de diagnóstico. No se tocó homelab-ctl.py; hay cambios locales ajenos que deben preservarse.

pg_dumps terminó0 los tres días17–19oct; último19oct01:30,33,78s. El script fuente publica atómicamente tras CRC, preserva la salida previa ante fallos y evita retención si falla alguna BD. No hay evidencia nueva que requiera rerun. service_contracts conserva último exit1 de22:23, anterior a la corrección documentada de contratos; no se presenta como regresión actual. originals_backup no tiene aún ejecución RunWisp: fue registrada hoy y la primera copia se lanzó manualmente; el observador independiente demuestra que sigue viva.

PBS sync-check: recuperado, con fragilidad en su criterio

CT186 no tiene unidades failed ni errores recientes de2h. pbs-sync-check 07:00 los días17,18y19 terminó0, fails_consecutivos0. Hubo JSONDecodeError en 17oct00:26 durante un arranque previo; las ejecuciones posteriores lo superan. GET de salud del Pushgateway por208:9092 devuelve200; el salto está operativo. No se ha hecho POST ni cambiado métricas en esta auditoría.

Fuente viva /usr/local/bin/pbs-sync-check.sh; no se localizó versión mantenida en scripts/ansible. Obtiene solo20tareas y busca main-to-archive en ellas: actividad reciente abundante puede expulsar el sync bueno de la ventana y crear falso fallo. También admite statusNone como éxito: un sync activo todavía no ha demostrado terminar. La corrección siguiente debería consultar estado del job/última tarea completada o paginar suficientemente, exigir statusOK y endtime, separar fallo de colección de fallo de sync y poner timeout/fallo HTTP explícito al POST. Mantener el timer07:00, contador y canal existentes. La anotación de alerta fuente aún dice06:25, dato documental a reconciliar.

GitOps y límites

Ansible-pull.timer estaba activo en ambos hosts y el servicio real ansible-pull.service se encontraba activating desde23:05:13, durante la coordinación del padre. No se toma Result=success con ExecMainExitTimestamp vacío como una ejecución terminada y no se ha lanzado otro pull concurrente. La evidencia previa ya acreditaba persistencia; confirmar su cierre en el coordinador después de las mutaciones pendientes.

VM208 root crontab vacío y RunWisp como propietario de19tareas; los timers systemd de salud siguen siendo fuentes separadas. La revisión no certifica todos los crons de cada invitado ni propone unificar calendarios por estética.