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>
This commit is contained in:
2026-07-22 17:21:24 -04:00
co-authored by Claude Opus 4.8
parent 75c33fffe5
commit 142c417d36
+11 -1
View File
@@ -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"