From ad69429fa0bc77d010aaa96ed8f45fd756b6e764 Mon Sep 17 00:00:00 2001 From: Sergio Date: Sun, 23 Aug 2026 17:16:34 +0000 Subject: [PATCH] runbook: el volumen es de UN server, y el latido de gioser va por cron Deja escrito lo que costo 21 G el 2026-08-22: `farm-up.sh N` apunta los N workers al mismo VOL_NAME y un volumen de Hetzner se adjunta a un unico server, asi que correr sharded exige un volumen POR worker. Con el comando exacto. Y la linea de crontab del latido, que vive FUERA del repo y se perderia si gioser se rehace. Incluye por que las dos rutas van absolutas: cron arranca en $HOME y la redireccion del log se abre ahi, no donde uno cree. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn --- docs/runbooks/harkaq-granja-volumen.md | 44 ++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/docs/runbooks/harkaq-granja-volumen.md b/docs/runbooks/harkaq-granja-volumen.md index d7106887..e6aad1f3 100644 --- a/docs/runbooks/harkaq-granja-volumen.md +++ b/docs/runbooks/harkaq-granja-volumen.md @@ -34,6 +34,50 @@ scripts/farm/harkaq-vol.sh status - El bucle **borra el artefacto `-hkm` tras medir** (envenenaba la caché en la 1ª campaña) y gatea por ABI≥7 + binario-con-jaula (no medir ciego). +## Un volumen se adjunta a UN server (2026-08-22, costó 21 G) + +`farm-up.sh N` crea N workers en un bucle y **todos apuntan al mismo `VOL_NAME`**. Como un volumen +de Hetzner se adjunta a un único server, del segundo en adelante no queda nada que adjuntar. La +campaña de reconstrucción corrió sharded (`SHARD=i/N`) en dos workers: hworker-1 tomó +`harkaq-cosecha` y hworker-2 nació sin volumen, construyó el shard 1/2 entero en su disco raíz y el +dead-man se lo llevó a las 03:27Z. **397 artefactos sellados, 584 sin copia en ningún otro sitio** +(la lista quedó en `work/perdidos-hworker2.txt`). + +Lo caro no fue la falta de detección: `farm-up` **ya imprimía** `⚠ el store NO quedó en el volumen ⇒ +lo que construya se PIERDE`. Lo imprimió esa noche, con esas palabras, y siguió adelante armando el +dead-man y sembrando la cola. Un aviso que no detiene el pipeline no es un guardián cuando no hay +nadie leyendo el log. + +Desde entonces `farm-up` **corta** (`sin_volumen()`): pregunta antes quién tiene el volumen tomado, +ya no se traga el error del `attach`, y si el store no queda anclado borra el server recién creado +(vacío, para no dejar un idle facturando) y sale 1. Para correr sharded hace falta **un volumen por +worker**: + +```sh +VOL_NAME=harkaq-cosecha-1 scripts/farm/farm-up.sh 1 +VOL_NAME=harkaq-cosecha-2 scripts/farm/farm-up.sh 1 +SIN_VOLUMEN_OK=1 scripts/farm/farm-up.sh 1 # worker deliberadamente desechable +``` + +## El latido en gioser va por cron, no por sesión + +`latido.sh` cuelga el bucle de **tu sesión de shell**, y eso es lo correcto *en el laptop*: no hay +systemd y cronie sólo existe en uno de los dos arranques. En gioser la premisa se invierte — es un +server, no hay sesión permanente, y crond sí corre. El mismo 2026-08-22 el rescate de hworker-2 +dependía de que un agente estuviera despierto mirando, y la respuesta llegó después del auto-borrado. + +```crontab +*/30 * * * * HOME=/home/sergio PATH=/usr/local/bin:/usr/bin:/bin /mnt/vvv/hammer/scripts/farm/cosecha-cron.sh >>/mnt/vvv/hammer/work/cosecha-cron.log 2>&1 +``` + +Rutas **absolutas** las dos: cron arranca en `$HOME`, así que una ruta relativa al script no +resuelve y —peor— la redirección del log se abre en el directorio equivocado. El script hace su +propio `cd "$ROOT"`, trae su `flock`, tolera workers ausentes y **no baja el store** (sólo el +manifiesto de nombres) ⇒ no puede llenar el disco. Parar = borrar la línea. + +Lo que el latido **no** cubre: los artefactos siguen viviendo sólo en el volumen hasta que alguien +haga una pasada de respaldo. El volumen tiene borrado protegido, pero es UNA copia. + ## Parar de emergencia ```sh hcloud server list | grep hkw # ver workers