tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1457Shell 147Markdown 90Rust 853012 Definiciones

Etapa G: watchdog no purga caches Go con CUALQUIER hammer build en vuelo (no solo vendor)

vault (go-15) falló en 'go mod vendor' con '~/.cache/go-build/...: no such file': durante el compile
de telegraf el disco cruzó DISK_HIGH, el watchdog corrió 'go clean -cache', y el vendor de vault (que
usa esa cache) arrancó en la ventana siguiente sin ficheros. El guard anterior solo miraba 'go mod
vendor' activo en ese instante; ahora difiere la purga si hay cualquier 'hammer build' en vuelo.

c270edade714c0d96d019ae18ceb46938e8966ae · por sergio · (hace 3 meses) · padre b3be6c8e3 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +10 −9

diff --git a/scripts/farm/farm-worker-loop.sh b/scripts/farm/farm-worker-loop.sh
index f04d5a16..88bfc5c3 100755
--- a/scripts/farm/farm-worker-loop.sh
+++ b/scripts/farm/farm-worker-loop.sh
@@ -42,15 +42,16 @@ DISK_HIGH="${DISK_HIGH:-82}"
     done
     use=$(df --output=pcent "$HAMMER_DIR" 2>/dev/null | tr -dc '0-9')
     if [ -n "$use" ] && [ "$use" -ge "$DISK_HIGH" ]; then
-      # OJO: `go clean -modcache` borra ~/go/pkg/mod ENTERO. Si lo corre mientras un `go mod vendor`
-      # del fetch está bajando módulos, le arranca el cache bajo los pies (`.partial: no such file`)
-      # y ESE vendor falla — y con tandas pesadas (k8s/azure SDK, varios GB en paralelo) son MUCHOS a
-      # la vez ⇒ el lote no converge. La purga de work/sources de arriba ya liberó lo grueso (segura:
-      # saltea bind-montadas). Sólo purgo el modcache si NO hay vendor de host activo; si lo hay,
-      # difiero al próximo tick (el sandbox `go install` usa GOPATH=/tmp + -mod=vendor ⇒ no toca el
-      # modcache del host, así que purgar durante un build sandbox sigue siendo seguro).
-      if pgrep -f 'go mod vendor' >/dev/null 2>&1; then
-        echo "$(date -u +%FT%TZ) watchdog: disco ${use}% ≥ ${DISK_HIGH}% pero hay vendor activo ⇒ difiero purga modcache"
+      # OJO: `go clean -modcache`/`-cache` borran ~/go/pkg/mod y ~/.cache/go-build ENTEROS. Ambos los
+      # usa `go mod vendor` (modcache p/ módulos, go-build p/ verificar el grafo). Si la purga corre
+      # mientras un vendor está activo —o en la VENTANA justo antes de que arranque (otra receta de la
+      # cola en serie)— le arranca el cache bajo los pies (`.partial`/`go-build/...: no such file`) y
+      # ESE vendor falla. La purga de work/sources de arriba ya liberó lo grueso (segura: saltea las
+      # protegidas). Por eso NO purgo las caches Go si hay CUALQUIER `hammer build` en vuelo (no solo
+      # un `go mod vendor` visible en este instante): difiero al próximo tick / al gap idle entre
+      # ciclos. El sandbox `go install` usa GOCACHE=/src + -mod=vendor ⇒ no toca estas caches del host.
+      if pgrep -f 'go mod vendor' >/dev/null 2>&1 || pgrep -f 'release/hammer.* build ' >/dev/null 2>&1; then
+        echo "$(date -u +%FT%TZ) watchdog: disco ${use}% ≥ ${DISK_HIGH}% pero hay build en vuelo ⇒ difiero purga caches Go"
       else
         echo "$(date -u +%FT%TZ) watchdog: disco ${use}% ≥ ${DISK_HIGH}% ⇒ purgo caches Go"
         go clean -modcache 2>/dev/null; go clean -cache 2>/dev/null