52eca1c22a
Wyciek plikow dispatch potwierdzony 2026-08-06 (session log, follow-up #1): LUSTRO re-pullowalo te same dwie akcje co 60 s przez wiele dni, odbijajac sie od bramki idempotencji, i nie zostawilo po sobie ani jednej linii w logach. Przyczyna zlozona z dwoch niezaleznych defektow: 1. Executor tworzyl actions/dispatch/<node>/ z 0o755 (aerbot:aerbot). Rsync-pull z noda uwierzytelnia sie jako inny uzytkownik, bedacy tylko *czlonkiem* tej grupy. --remove-source-files musi zrobic unlink pliku, a unlink wymaga prawa zapisu w katalogu nadrzednym, nie na samym pliku. Zrodlo przezywalo pobranie. (dispatch/piha mialo historycznie 775 i dlatego dzialalo.) 2. node-agent traktowal rc=23 jako benign obok 0 i 24, wiec rsync zglaszal porazke, a agent ja polykal. Executor: _ensure_inbox_dir() = mkdir + bezwarunkowy os.chmod(0o775). chmod jest bezwarunkowy z dwoch powodow: mkdir(mode=) jest maskowany przez umask procesu (przy 0o022 daje dokladnie feralne 0o755), a inboxy zalozone przez wczesniejszy build juz istnieja na flocie z 0o755. Naprawa w miejscu zapisu, a nie skanem przy starcie: jedno idempotentne wywolanie na tej samej sciezce kodu, ktora pisze plik dispatch, wiec nie da sie rozjechac z pisarzami. Blad chmod nie jest fatalny — akcja i tak sie wykonuje, a nieskasowane zrodlo widac teraz po stronie noda. Objete tez actions/deploy/<node>/ (deploy-runner): ten sam wzorzec drenowania tym samym rsync-pullem, ten sam defekt, jedno wywolanie obok. node-agent: klasyfikacja kodow wyjscia zamiast wspolnej listy benign. Weryfikacja empiryczna rsync 3.4.1 pokazala, ze rc=23 pokrywa dwa rozne przypadki, a rozroznia je dopiero stderr: * `change_dir ... No such file or directory` — executor zaklada inbox dopiero przy pierwszym dispatchu, wiec kazdy nod, do ktorego nic nie poszlo, dostaje rc=23 co cykl. DEBUG — inaczej byloby po linii na minute z wiekszosci floty i realny sygnal utonalby w szumie. * `sender failed to remove <plik>: Permission denied` — wlasnie ten wyciek. WARNING z pelnym stderr. Pusty (ale istniejacy) inbox to rc=0, nie 23 — dotychczasowy komentarz w kodzie mowil inaczej. rc=24 zostaje benign (wyscig z executorem piszacym inbox), pozostale kody to teraz ERROR, nie WARNING. Zachowanie funkcjonalne bez zmian: retry i idempotencja dzialaja jak dotad, zmienia sie wylacznie widocznosc. Testy: 4 nowe w test_executor_dispatch.py (oba inboxy 0o775 pod umask 0o022, naprawa istniejacego 0o755 in place, dispatch przezywa nieudany chmod), 5 w test_action_dispatch.py na klasyfikacje rc. Zastapiony test_pull_treats_empty_source_returncodes_as_non_error — kodyfikowal wlasnie to zalozenie, ktore okazalo sie bugiem. Oba zestawy sprawdzone mutacja: bez chmod padaja 3 testy executora, przy starej liscie benign pada test rc=23. node-agent 70 passed, control-plane 173 passed. Refs docs/sessions/2026-08-06.md (follow-up #1) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| deploy-local.sh | ||
| docker-compose.yml | ||
| Dockerfile | ||
| env.example | ||
| pyproject.toml | ||
| README.md | ||
control-plane
Observer + Supervisor + Executor + Operator UI na VPS — synteza world state z eventow i dyspozycja akcji.
Dokumentacja: kb/services/control-plane.md