farm: que el loop DIGA que está esperando el lock, en vez de parecer que trabaja
El `echo "ciclo: N recetas en $Q"` sale ANTES de pedir el lock, así que con la campaña corriendo el journal mostraba el anuncio del ciclo y después nada: parece un loop trabajando y es un loop bloqueado. Es la misma clase de problema que el "no encuentro el ejecutable zig" apuntando al directorio equivocado — un log que miente cuesta horas de diagnóstico. `flock -n` primero, y sólo si falla se anuncia la espera y se bloquea. Sin coste cuando el lock está libre, que es el caso normal. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Delta semántico
Ninguna definición cambió: el cambio es de texto, documentación o datos.
1 archivos · +11 −1
diff --git a/scripts/farm/farm-worker-loop.sh b/scripts/farm/farm-worker-loop.sh
index 28ce1fd5..f5c616fa 100755
--- a/scripts/farm/farm-worker-loop.sh
+++ b/scripts/farm/farm-worker-loop.sh
@@ -110,7 +110,17 @@ while :; do
# (LOCK_WAIT) y sale limpia si no entra, en vez de colgarse.
# NO cubre el `-P2` interno: dos recetas de la MISMA cola que compartan dep siguen pudiendo
# pisarse. Ese es el arreglo de fondo, un lock por árbol dentro de `fetch`.
- ( flock 9; JOBS="$JOBS" PROMOTE=0 QUEUE="$Q" scripts/build-farm.sh 2>&1 | tail -50 ) 9>"$LOCK_FARM"
+ # El `flock -n` primero es sólo para poder DECIR que estamos esperando: si el log dijera
+ # "ciclo: N recetas" y después nada, parecería que el loop trabaja cuando en realidad está
+ # bloqueado, y ese malentendido es exactamente el que cuesta horas de diagnóstico.
+ (
+ if ! flock -n 9; then
+ echo "$(date -u +%FT%TZ) esperando el lock de build (campana-deuda lo tiene)…"
+ flock 9
+ echo "$(date -u +%FT%TZ) lock tomado, sigo con $Q"
+ fi
+ JOBS="$JOBS" PROMOTE=0 QUEUE="$Q" scripts/build-farm.sh 2>&1 | tail -50
+ ) 9>"$LOCK_FARM"
done
if [ "$total" -gt 0 ]; then
echo "$(date -u +%FT%TZ) ciclo terminado; store sellado disponible para el hub"