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 Definitions

⎇ 1b436a717f596fef7c813f3112aff05ce1dcf856 scripts/farm/farm-worker-loop.sh Shell · 121 lines · 8.1 KB History raw

farm: lock compartido entre campana-deuda y el worker-loop 1b436a717 · sergio ·

1#!/usr/bin/env bash
2# farm-worker-loop.sh — loop AUTÓNOMO del worker. Construye la cola recipes/incoming/ en
3# bucle (PROMOTE=0: sólo sella al store local, NO promueve, NO firma, NO toca gitea), con
4# watchdog de disco integrado. El hub (laptop) le mete recetas nuevas vía farm-sync.sh y le
5# baja el store sellado; este loop sólo muele lo que haya, 24/7, sin esperar a nadie.
6#
7# Idempotente: cada ciclo re-escanea incoming/; lo ya-sellado sale por cache-hit (instantáneo),
8# sólo construye lo nuevo. Cuando la cola está toda construida, duerme IDLE_SLEEP y reintenta.
9#
10# Lo lanza systemd (hammer-farm.service). Manual:  JOBS=2 ./scripts/farm/farm-worker-loop.sh
11set -uo pipefail
12HAMMER_DIR="${HAMMER_DIR:-/opt/hammer}"
13cd "$HAMMER_DIR"
14. "$HOME/.cargo/env" 2>/dev/null || true
15JOBS="${JOBS:-$(nproc)}"
16IDLE_SLEEP="${IDLE_SLEEP:-300}"
17# Fichero de lock compartido con campana-deuda.sh (mismo path en los dos, o no hay exclusión).
18LOCK_FARM="${LOCK_FARM:-$HAMMER_DIR/work/.farm-build.lock}"
19mkdir -p "$HAMMER_DIR/work"
20
21# --- watchdog de disco: cada 3 min borra work/sources/* que ningún bwrap activo bind-monta
22# (seguro: sellada=store CAS, en-cola=se re-extrae sola). Evita que el vendoring llene el disco.
23# Además, si el disco supera DISK_HIGH%, purga los CACHES Go (GOMODCACHE ~/go/pkg/mod + gocache):
24# el `go mod vendor` de las recetas Go acumula ahí decenas de GB sin tope (el vendor/ local de cada
25# receta ya tiene lo que el build necesita; el modcache sólo se usa DURANTE el vendor). Si la purga
26# pisa un vendor en curso, esa receta reintenta el próximo ciclo (cache-hit el resto). Sin esto, una
27# tanda Go grande llena el disco de 80G y el I/O-wait dispara el load (cuello real, no CPU/RAM).
28DISK_HIGH="${DISK_HIGH:-82}"
29(
30  while :; do
31    sleep 180
32    # Protección 1: árboles que un bwrap activo bind-monta (fase compile dentro del sandbox).
33    active=$(pgrep -af bwrap 2>/dev/null | grep -oE 'work/sources/[^ ]+' | sort -u)
34    # Protección 2: árboles cuya receta tiene un `hammer build` EN VUELO. Durante el fetch/`go mod
35    # vendor`/resolve_phases (host-side, ANTES de que arranque el bwrap) el árbol no está bind-montado
36    # ⇒ la protección 1 no lo cubre. Una tanda Go con árbol de deps enorme (dnscontrol/lazysql) tarda
37    # minutos vendoreando; sin esto, el watchdog le borra el go.mod a mitad → "no build system".
38    building=$(pgrep -af 'release/hammer' 2>/dev/null | grep -oE '[^ ]+\.toml' | sed 's#.*/##;s#\.toml$##' | sort -u)
39    for d in work/sources/*/; do
40      [ -d "$d" ] || continue; dd=${d%/}
41      printf '%s\n' "$active" | grep -qxF "$dd" && continue
42      nm=$(basename "$dd"); nm=${nm%-*}   # work/sources/<name>-<sha40> → <name> (el sha no trae '-')
43      printf '%s\n' "$building" | grep -qxF "$nm" && continue
44      # Protección 3: árbol CALIENTE (modificado hace <2 min) ⇒ se está extrayendo AHORA. Una dep
45      # transitiva (p.ej. cairo bajo pango/gtk4) se extrae host-side ANTES del bwrap y con un nombre
46      # que NO coincide con la receta en vuelo ⇒ protecciones 1 y 2 no la cubren. Sin esto, el rm -rf
47      # compite con el tar y deja el árbol a medias ("Cannot mkdir" / luego "Directory not empty" para
48      # siempre). Un árbol en frío (extracción ya fallida/terminada) queda purgable ⇒ se re-extrae limpio.
49      [ -n "$(find "$dd" -mmin -2 -print -quit 2>/dev/null)" ] && continue
50      rm -rf "$dd"
51    done
52    use=$(df --output=pcent "$HAMMER_DIR" 2>/dev/null | tr -dc '0-9')
53    if [ -n "$use" ] && [ "$use" -ge "$DISK_HIGH" ]; then
54      # OJO: `go clean -modcache`/`-cache` borran ~/go/pkg/mod y ~/.cache/go-build ENTEROS. Ambos los
55      # usa `go mod vendor` (modcache p/ módulos, go-build p/ verificar el grafo). Si la purga corre
56      # mientras un vendor está activo —o en la VENTANA justo antes de que arranque (otra receta de la
57      # cola en serie)— le arranca el cache bajo los pies (`.partial`/`go-build/...: no such file`) y
58      # ESE vendor falla. La purga de work/sources de arriba ya liberó lo grueso (segura: saltea las
59      # protegidas). Por eso NO purgo las caches Go si hay CUALQUIER `hammer build` en vuelo (no solo
60      # un `go mod vendor` visible en este instante): difiero al próximo tick / al gap idle entre
61      # ciclos. El sandbox `go install` usa GOCACHE=/src + -mod=vendor ⇒ no toca estas caches del host.
62      if pgrep -f 'go mod vendor' >/dev/null 2>&1 || pgrep -f 'release/hammer.* build ' >/dev/null 2>&1; then
63        echo "$(date -u +%FT%TZ) watchdog: disco ${use}% ≥ ${DISK_HIGH}% pero hay build en vuelo ⇒ difiero purga caches Go"
64      else
65        echo "$(date -u +%FT%TZ) watchdog: disco ${use}% ≥ ${DISK_HIGH}% ⇒ purgo caches Go"
66        go clean -modcache 2>/dev/null; go clean -cache 2>/dev/null
67      fi
68    fi
69  done
70) &
71
72# Colas a construir (sólo SELLA, PROMOTE=0; el hub promueve+firma). `recipes/incoming` es la cola de
73# staging general; `recipes/incoming-go` es la AISLADA del frente Go (pre-sembrada para moler 24/7).
74# build-farm hace `rm -rf work/farm` al inicio ⇒ construirlas EN SERIE (una por vuelta) es seguro,
75# sin colisión. El glob es TOP-LEVEL (`$Q/*.toml`), así que `recipes/incoming/.deferred/` (24 recetas
76# aparcadas con diagnóstico, p.ej. git con muro en libgit.a) NO se muele — es un subdir a propósito.
77# incoming-clib: libs C (toolkit/foundational) que el worker SELLA pero el cron de cosecha-go IGNORA
78# (son build-deps, se usan vía catálogo; no tienen binario que el gate Go pueda smoke-testear).
79QUEUES="${QUEUES:-recipes/incoming recipes/incoming-go recipes/incoming-clib recipes/incoming-kde}"
80
81# REBUILD DEL BINARIO AL ARRANCAR (2026-07-18): el hammer horneado en la imagen golden ENVEJECE.
82# Caso real que costó una noche de KDE: la golden del 29-jun traía un hammer sin el fix del overlay
83# lowerdir (commit e69eaaa, 12-jul) ⇒ toda receta de muchas deps (kio=52, kwin, plasma-*) desbordaba
84# el límite de 4KB del mount options y el sandbox NI ARRANCABA — 43 recetas atascadas jurando "en
85# cola". El source SÍ llega fresco (farm-sync rsync-ea el repo), pero nadie recompilaba. Reconstruir
86# aquí garantiza que el worker corre el CÓDIGO VIGENTE, no el fósil de la imagen. Cacheado: ~24s si
87# no cambió nada, minutos en frío. Si cargo falla, seguimos con el binario que haya (mejor que abortar).
88if command -v cargo >/dev/null 2>&1; then
89  echo "$(date -u +%FT%TZ) rebuild hammer desde el source rsync-eado (evita el fósil de la golden)…"
90  cargo build --release --bin hammer -j"$JOBS" 2>&1 | tail -2 || echo "  ⚠ rebuild falló — uso el binario existente"
91fi
92
93echo "$(date -u +%FT%TZ) worker-loop arrancado: JOBS=$JOBS IDLE_SLEEP=$IDLE_SLEEP QUEUES='$QUEUES'"
94while :; do
95  total=0
96  for Q in $QUEUES; do
97    n=$(ls "$Q"/*.toml 2>/dev/null | wc -l)
98    [ "$n" -gt 0 ] || continue
99    total=$((total + n))
100    echo "$(date -u +%FT%TZ) ciclo: $n recetas en $Q"
101    # LOCK COMPARTIDO CON campana-deuda.sh (2026-07-22): ambos construyen sobre el mismo work/, y
102    # `fetch` nombra el árbol de fuentes de forma determinista (`work/sources/<receta>-<sha16>`) ⇒
103    # dos procesos que construyan la misma DEP apuntan al mismo directorio y uno hace `remove_dir_all`
104    # mientras el otro corre `tar -x`, dejándolo a medias con "Directory not empty" (os error 39) para
105    # siempre. Se toma POR COLA y se suelta al terminarla, en vez de por bucle entero. Más fino no
106    # se puede sin romper el `xargs -P2` de build-farm.sh.
107    # OJO con la expectativa: `flock` NO es FIFO. Como el loop vuelve a pedirlo enseguida, suele
108    # ganarle la carrera a la campaña que espera; medido, la campaña entra al terminar TODAS las
109    # colas, no entre dos. La ventana real es el IDLE_SLEEP. Por eso la campaña espera con techo
110    # (LOCK_WAIT) y sale limpia si no entra, en vez de colgarse.
111    # NO cubre el `-P2` interno: dos recetas de la MISMA cola que compartan dep siguen pudiendo
112    # pisarse. Ese es el arreglo de fondo, un lock por árbol dentro de `fetch`.
113    ( flock 9; JOBS="$JOBS" PROMOTE=0 QUEUE="$Q" scripts/build-farm.sh 2>&1 | tail -50 ) 9>"$LOCK_FARM"
114  done
115  if [ "$total" -gt 0 ]; then
116    echo "$(date -u +%FT%TZ) ciclo terminado; store sellado disponible para el hub"
117  else
118    echo "$(date -u +%FT%TZ) colas vacías; durmiendo ${IDLE_SLEEP}s"
119  fi
120  sleep "$IDLE_SLEEP"
121done