Etapa G: watchdog protege árboles con 'hammer build' en vuelo (fase host vendor/resolve)
go-13 (dnscontrol/lazysql, árboles de deps Go enormes) destapó otra race del watchdog: durante el fetch/'go mod vendor'/resolve_phases (host-side, antes del bwrap) el árbol no está bind-montado ⇒ el watchdog lo borraba a mitad del vendor → go.mod desaparecía → 'receta sin compile, heurística no encontró build system'. Ahora además protege work/sources/<name>-* si <name> tiene un proceso 'hammer build' activo (cubre toda la vida del build, no solo la fase sandbox).
Delta semántico
Ninguna definición cambió: el cambio es de texto, documentación o datos.
1 archivos · +8 −0
diff --git a/scripts/farm/farm-worker-loop.sh b/scripts/farm/farm-worker-loop.sh
index 07c317ab..f04d5a16 100755
--- a/scripts/farm/farm-worker-loop.sh
+++ b/scripts/farm/farm-worker-loop.sh
@@ -26,10 +26,18 @@ DISK_HIGH="${DISK_HIGH:-82}"
(
while :; do
sleep 180
+ # Protección 1: árboles que un bwrap activo bind-monta (fase compile dentro del sandbox).
active=$(pgrep -af bwrap 2>/dev/null | grep -oE 'work/sources/[^ ]+' | sort -u)
+ # Protección 2: árboles cuya receta tiene un `hammer build` EN VUELO. Durante el fetch/`go mod
+ # vendor`/resolve_phases (host-side, ANTES de que arranque el bwrap) el árbol no está bind-montado
+ # ⇒ la protección 1 no lo cubre. Una tanda Go con árbol de deps enorme (dnscontrol/lazysql) tarda
+ # minutos vendoreando; sin esto, el watchdog le borra el go.mod a mitad → "no build system".
+ building=$(pgrep -af 'release/hammer' 2>/dev/null | grep -oE '[^ ]+\.toml' | sed 's#.*/##;s#\.toml$##' | sort -u)
for d in work/sources/*/; do
[ -d "$d" ] || continue; dd=${d%/}
printf '%s\n' "$active" | grep -qxF "$dd" && continue
+ nm=$(basename "$dd"); nm=${nm%-*} # work/sources/<name>-<sha40> → <name> (el sha no trae '-')
+ printf '%s\n' "$building" | grep -qxF "$nm" && continue
rm -rf "$dd"
done
use=$(df --output=pcent "$HAMMER_DIR" 2>/dev/null | tr -dc '0-9')