mitigation(solaria): M1 — NODE_TYPE=lte_node wyłącza prune node-agenta
Mitygacja tymczasowa z incydentu 2026-07-30-ollama-solaria-vanish (§7, M1),
na czas backfillu embed (faza mailowa KB). Na SOLARII node-agent robił
niefiltrowany `docker container prune` co cykl (60 s), kasując również
kontenery z `restart: unless-stopped` zatrzymane świadomie przez operatora.
Zweryfikowane w kodzie (services/node-agent/src/node_agent.py, linie zgodne
z incydentem): `self.node_type` jest czytane wyłącznie w run_safe_cleanup()
(648, 654) i w dwóch liniach logu (250, 1103). `lte_node` daje wczesny return
w run_safe_cleanup — monitoring, eventy, dispatch akcji bez zmian.
_cleanup_control_plane_fs jest bramkowane node_name == VPS, nie node_type.
stability-agent nie prune'uje — node-agent był jedynym źródłem.
Ścieżka deployu zweryfikowana: deploy-service.sh:100 składa
${HOST_DIR}/runtime/${SERVICE}/docker-compose.override.yml, a HOST_DIR to
hosts/<node> w obu wywołaniach (deploy-node.sh:102 operatorskie,
deploy-runner.sh:170 agentowe). Dowód, że plik nie jest martwy: działający
kontener na SOLARII ma NODE_TYPE=ai_node, co występuje wyłącznie w tym pliku.
`docker compose config` na złożeniu daje NODE_TYPE=lte_node, group_add 999+996
zachowane, projekt "node-agent" (bez zmiany nazwy projektu).
Skutek uboczny: lte_node pomija CAŁY cleanup, więc dangling images i build
cache też nie są sprzątane — pilnować miejsca na dysku SOLARII.
Zdjąć po wdrożeniu R1 na nodzie → przywrócić NODE_TYPE=ai_node.
Nie zdeployowane — deploy po stronie operatora.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 14:49:22 +02:00
|
|
|
|
# MITYGACJA TYMCZASOWA (M1) — założona 2026-08-04.
|
|
|
|
|
|
# NODE_TYPE=lte_node wyłącza run_safe_cleanup() (niefiltrowany
|
|
|
|
|
|
# `docker container prune`) na czas backfillu embed (faza mailowa KB).
|
|
|
|
|
|
# Incydent: docs/incidents/2026-07-30-ollama-solaria-vanish.md (§7, M1).
|
|
|
|
|
|
# Bez tego każdy zatrzymany kontener na SOLARII znika w ≤60 s — również taki
|
|
|
|
|
|
# z `restart: unless-stopped`, zatrzymany świadomie przez operatora.
|
|
|
|
|
|
# Warunek zdjęcia: R1 (filtrowanie prune po restart policy / labelu compose)
|
|
|
|
|
|
# wdrożony na tym nodzie — R1–R3 są w toku po stronie subsystemu A.
|
|
|
|
|
|
# Po zdjęciu przywrócić: NODE_TYPE=ai_node.
|
|
|
|
|
|
# Zakres wyłączenia: `lte_node` pomija CAŁY cleanup, więc na czas mitygacji
|
|
|
|
|
|
# nie są też sprzątane dangling images ani build cache — pilnować miejsca
|
|
|
|
|
|
# na dysku. Monitoring, eventy i dispatch akcji działają bez zmian
|
|
|
|
|
|
# (self.node_type jest czytane wyłącznie w run_safe_cleanup i dwóch liniach logu).
|
2026-05-27 13:34:23 +02:00
|
|
|
|
services:
|
|
|
|
|
|
node-agent:
|
2026-07-29 19:20:08 +02:00
|
|
|
|
# Docker GID on SOLARIA is 996 (not the Debian default 999 the base compose
|
|
|
|
|
|
# assumes). Without this the agent starts with "Docker unavailable:
|
|
|
|
|
|
# Permission denied" on /var/run/docker.sock and reports no containers
|
|
|
|
|
|
# (recon RECON-multiagent-2026-07-27.md, A2/E19). Compose concatenates
|
|
|
|
|
|
# group_add lists, so the base 999 stays alongside; 996 is what grants
|
|
|
|
|
|
# socket access here. Same per-host pattern as piha (123) and lustro (991).
|
|
|
|
|
|
group_add:
|
2026-07-30 15:44:17 +02:00
|
|
|
|
- "996" # host docker gid, verified 2026-07-30 (getent group docker → 996)
|
2026-05-27 13:34:23 +02:00
|
|
|
|
environment:
|
|
|
|
|
|
- NODE_NAME=solaria
|
mitigation(solaria): M1 — NODE_TYPE=lte_node wyłącza prune node-agenta
Mitygacja tymczasowa z incydentu 2026-07-30-ollama-solaria-vanish (§7, M1),
na czas backfillu embed (faza mailowa KB). Na SOLARII node-agent robił
niefiltrowany `docker container prune` co cykl (60 s), kasując również
kontenery z `restart: unless-stopped` zatrzymane świadomie przez operatora.
Zweryfikowane w kodzie (services/node-agent/src/node_agent.py, linie zgodne
z incydentem): `self.node_type` jest czytane wyłącznie w run_safe_cleanup()
(648, 654) i w dwóch liniach logu (250, 1103). `lte_node` daje wczesny return
w run_safe_cleanup — monitoring, eventy, dispatch akcji bez zmian.
_cleanup_control_plane_fs jest bramkowane node_name == VPS, nie node_type.
stability-agent nie prune'uje — node-agent był jedynym źródłem.
Ścieżka deployu zweryfikowana: deploy-service.sh:100 składa
${HOST_DIR}/runtime/${SERVICE}/docker-compose.override.yml, a HOST_DIR to
hosts/<node> w obu wywołaniach (deploy-node.sh:102 operatorskie,
deploy-runner.sh:170 agentowe). Dowód, że plik nie jest martwy: działający
kontener na SOLARII ma NODE_TYPE=ai_node, co występuje wyłącznie w tym pliku.
`docker compose config` na złożeniu daje NODE_TYPE=lte_node, group_add 999+996
zachowane, projekt "node-agent" (bez zmiany nazwy projektu).
Skutek uboczny: lte_node pomija CAŁY cleanup, więc dangling images i build
cache też nie są sprzątane — pilnować miejsca na dysku SOLARII.
Zdjąć po wdrożeniu R1 na nodzie → przywrócić NODE_TYPE=ai_node.
Nie zdeployowane — deploy po stronie operatora.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 14:49:22 +02:00
|
|
|
|
- NODE_TYPE=lte_node # M1 (2026-08-04) — było: ai_node; przywrócić po R1
|
2026-05-27 14:07:27 +02:00
|
|
|
|
- VPS_EVENTS_HOST=100.95.58.48
|
2026-05-27 13:34:23 +02:00
|
|
|
|
- VPS_EVENTS_USER=oskar
|
|
|
|
|
|
- VPS_EVENTS_PATH=/opt/homelab/events
|
|
|
|
|
|
- CHECK_INTERVAL=60
|
2026-05-27 13:59:28 +02:00
|
|
|
|
volumes:
|
2026-06-12 14:32:12 +02:00
|
|
|
|
- /home/oskar/.ssh:/home/homelab/.ssh:ro
|
