2 Commits

Include renames

Author	SHA1	Message	Date
SergioandClaude Opus 5	fd09ca77b0	arjectl en la imagen: relanzar en caliente — y el genesis NO alcanzaba para eso ... El servicio que falla y agota su backoff sólo se podía recuperar reiniciando la máquina entera. Ya no. Y no hubo que escribir nada: **el cliente existía en tawasuyu y el crate se llama `arje-ctl`** (el binario, `arjectl`). Buscarlo por `arjectl` no lo encontraba, y de ahí salió mi conclusión falsa de que había que implementarlo — el protocolo ya traía ListEntes, SpawnCardFromDisk, StopCardFromDisk, KillEnte y EnteStatus. `recipes/arjectl.toml` lo construye del MISMO commit que `arje-zero` (98db584f), y no por comodidad: el bus es un protocolo entre dos binarios y un cliente de otro árbol puede conectar sin entenderse con el init. Publica sólo `arjectl`; el crate también produce un `systemctl` de camuflaje que acá no se instala — en una distro sin systemd, ese nombre en el PATH invita a escribir runbooks con el verbo ajeno. ⚠ EL HUECO QUE SÓLO SE VE USÁNDOLO: el genesis de la seed dice qué arranca AL BOOT, pero `start`/`restart` usan `SpawnCardFromDisk`, que lee `/etc/arje/cards.d/<label>.json` — y el armado no lo escribía: $ arjectl start gitea Error: arje-zero rechazó: card gitea: No such file or directory (buscada en /etc/arje/cards.d/gitea.json) Son dos preguntas distintas —qué arranca solo, y qué se puede encarnar a pedido— y arje las responde desde sitios distintos. `inyectar-cards.py` escribe ahora los dos árboles, y en `cards.d` escribe TODAS las cards, no sólo las nuevas: `sshd` viene del product-rootfs y tampoco era relanzable. Medido con la VM arrancada UNA sola vez: la imagen trae `cards.d/{gitea,sshd}.json` · `list-units` da PID/CPU/MEM/HILOS/reinicios · poner el `app.ini` + `arjectl start gitea` ⇒ **GET / 200 sin reiniciar** (uptime 6 min) · `arjectl restart gitea` cambia el PID (118 → 192) y sigue en 200. ⚠ Y un aviso que costó un HTTP intermitente: **`arjectl start` sobre un Ente YA VIVO lo DUPLICA** — `SpawnCardFromDisk` no deduplica por label y arje le da un ULID nuevo. En gitea el síntoma fue `unable to lock level db … resource temporarily unavailable` y un `[F]`: dos servidores peleando por el mismo estado. Para relanzar se usa `restart`, o se mira `list-units` antes. Un `start` idempotente es trabajo de arje, no de esta imagen. ⚠ Deuda anotada, no barrida: `arjectl` va en `perfil.servidor` porque este frente es el que lo pagó. TODA imagen de takana corre arje-zero como PID 1 y ninguna se puede operar sin él ⇒ el argumento para subirlo a `base` es fuerte, y es una línea. Se deja como decisión. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn	2026-09-14 17:59:11 +00:00
Sergio	3d79cdf98b	SDD 30 4c: GNOME con los demonios supervisados por arje — y el control arregló colord ... Los demonios de sistema pasan de lanzarse con `&` desde un script de 500 líneas a ser Cards del `genesis`. El bloqueo que este frente daba por corpus se levantó solo: otro agente selló evolution-data-server y gnome-shell mientras esto se escribía, y escritorio-gnome quedó 309/309. SE CORRIÓ UN CONTROL PRIMERO, y es lo único que hace interpretable el resultado: colord control: `MURIÓ al arrancar` cards: `ya vive (pid 175)` ColorManager control: `NO apareció en 40s` cards: `OK` login1/Accounts/UPower OK en los dos compositor wayland-0 y shell vivo en los dos El fallo del control DESAPARECIÓ, y no lo buscaba: colord moría arrancado por el script y vive arrancado por arje, con el bus ya listo porque la espera está dentro de su argv. Sin el control, «ColorManager OK» sería un dato suelto en vez de una diferencia. Los PIDs lo confirman: polkit=119, colord=175, upowerd=178, accounts=180 — de antes de que el lanzador de sesión existiera. QUÉ NO SE COMPROBÓ: no hay screendump; QEMU salió por timeout y el control tampoco lo tuvo. La comparación es serial contra serial y lo que se afirma es sobre los DEMONIOS, no sobre el pintado. Las piezas donde corresponde: `takana service-cards` (UNA sola implementación de receta→Card; el formato es contrato con card_core::Card), `targets.py --service-paths` (une qué-es con si-arranca), y un inyector en FICHERO APARTE porque anidar dos heredocs de python falló en vivo — el terminador del interno cerró el externo y media cosa corrió como shell. La espera del bus va DENTRO del argv de las 5 recetas de sistema: sin ella un daemon arranca antes de que dbus escuche y queda en modo idle sin registrar su nombre — un fallo que no se ve, porque el proceso vive y el bus no lo tiene. Los 5 hashes intactos. Y el guardia de gnome-start es por «¿está corriendo?», no por una perilla: así es correcto venga de donde venga el proceso y la misma copia sirve donde no se inyectaron cards.	2026-09-14 01:51:19 +00:00