deadman: --puede-borrar sourcea /etc/hammer-deadman.env (o daba falso-negativo)
Cazado con el 1er worker real: el token vive en /etc/hammer-deadman.env (lo carga systemd como EnvironmentFile), pero corrido A MANO (farm-up --puede-borrar) ese fichero no se lee solo ⇒ mi cadena de fallback no lo veía ⇒ decía 'sin token' y farm-up habría DESTRUIDO un worker que sí puede matarse. Fix: sourcear el EnvironmentFile antes de la cadena de tokens desnudos. Verificado en worker real: 'SÍ: puedo borrar mi id=154276696'. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Delta semántico
Ninguna definición cambió: el cambio es de texto, documentación o datos.
1 archivos · +8 −0
- scripts/farm/deadman.sh +8 −0
diff --git a/scripts/farm/deadman.sh b/scripts/farm/deadman.sh
index 2fccaf7b..5be2d38a 100644
--- a/scripts/farm/deadman.sh
+++ b/scripts/farm/deadman.sh
@@ -62,6 +62,14 @@ log() { echo "$(date -u +%FT%TZ) deadman: $*" >> "$LOG"; }
# para matarse (ésa es su razón de ser: vive en el worker). Así que busca el token en CADENA — el
# volumen primero, porque es lo más persistente (sobrevive al server, la idea del volumen del usuario).
: "${HCLOUD_TOKEN:=}"
+# La service lo recibe vía EnvironmentFile, pero corrido A MANO (farm-up --puede-borrar) ese fichero
+# NO se carga solo ⇒ hay que sourcearlo, o la verificación da falso-negativo y destruye un worker que
+# SÍ puede matarse (lo cazó el 1er worker real, 2026-07-23). Es formato KEY=value.
+if [ -z "$HCLOUD_TOKEN" ] && [ -r /etc/hammer-deadman.env ]; then
+ . /etc/hammer-deadman.env 2>/dev/null || true
+ : "${HCLOUD_TOKEN:=}"
+fi
+# Y ficheros de token DESNUDO (otros caminos de creación): el volumen primero, que es lo persistente.
if [ -z "$HCLOUD_TOKEN" ]; then
for f in /mnt/cosecha/.hcloud-token /root/.hcloud-token /etc/hcloud-token; do
[ -r "$f" ] || continue