nanobot: 2026-09-18 20:14:19

cron/jobs.json

@@ -191,8 +191,8 @@
         "originMetadata": {}
       },
       "state": {
-        "nextRunAtMs": 1789752737375,
+        "nextRunAtMs": 1789756337379,
-        "lastRunAtMs": 1789750937375,
+        "lastRunAtMs": 1789754537379,
         "lastStatus": "ok",
         "lastError": null,
         "runHistory": [
@@ -258,11 +258,25 @@
             "durationMs": 0,
             "error": null,
             "runId": null
+          },
+          {
+            "runAtMs": 1789752737377,
+            "status": "ok",
+            "durationMs": 0,
+            "error": null,
+            "runId": null
+          },
+          {
+            "runAtMs": 1789754537379,
+            "status": "ok",
+            "durationMs": 0,
+            "error": null,
+            "runId": null
           }
         ]
       },
       "createdAtMs": 1776109113795,
-      "updatedAtMs": 1789750937375,
+      "updatedAtMs": 1789754537379,
       "deleteAfterRun": false
     }
   ]

projects/devops/memory.md

@@ -179,3 +179,14 @@ Otevřené body po migraci:
 
 - Zdroje Optiplexu nebyly "pročistěné/zbavené" — uživatel je **prohlédl/pro kontroloval** a použil.
 - Při vyjmutí paměti speaker pípal = RAM sloty fungovaly, ale board sám o sobě se nechoval jako mrtvý; diagnóza root cause boardu nebyla proveditelná, necháme u neznámého.
+- 2026-09-18: Deníkový záznam k pádu serveru (17.9 večer — 18.9 ráno), doplňuje předchozí zápisy:
+
+- Padlý server byl **Dell Optiplex 9020** workstation z raných dob RSJ; dlouho sloužil jako server. Postupně mu byly měněny zdroj, kabely a větrák, přidána **RTX 4060 Ti** (deník uvádí Ti — proti dřívější zmínce "RTX 4060"; necháno jako otevřený detail) a hromada disků.
+- Symptom: z ničeho nic mrtvý; podezření nejdřív na síťování (vyvráceno). Při vyjmutí paměti deska píská chybové kódy → podezřelé CPU, DDR nebo deska. Diagnostika přes LLM ("klóda"/Claude) byla zmatená a nic z jejích rad nezabralo.
+- **Hypotéza Gemini:** problém může být v AliExpress kabelu zdroj→deska (odchází měnič/konvertor). Zvláštní, ale dobré vysvětlení a **proměřitelné** — jediná zatím proměřitelná hypotéza root cause.
+- Možnosti obnovy, jak je hodnotí uživatel:
+  - Aukro: stejná deska (9020) za ~3 kCZK — zvažována koupě aspoň na vyzkoušení, kdyby nic jiného. Uživatel nechápe ekonomiku prodejců (packing + shipping nuluje výdělek), ale je to dobrá koupě. Doufá, že v prdeli není CPU nebo RAM.
+  - **HP Z440 Workstation** pod stolem v práci — Intel Xeon E5-1650, 6 jader / 12 vláken, 32 GB (4 obsazené + 4 volné sloty). Hodnocen jako "úplně super" — ideální kandidát na náhradu, pokud ho dostane z vyřazování.
+  - **Vlastní hlavní PC** (nahoře v chlívku) — skoro se nepoužívá, nekompiluje se na něm, na hry není čas. Zvažováno jako virtualizační mašina: Proxmox host + Windows VM používané jen přes RDP. Má dost jader i paměti. Zdráhá se ("nechce se mi to samozřejmě dělat", "srát se s Windows je vopruz"), ale uznává, že by to mohlo stačit.
+- **Lekce vyřčená nahlas:** měl si zálohovat kontejnery z Proxmoxu, právě pro takovéhle případy. (Rezonuje s top priority pain pointem: zálohování.)
+- Kontext ekonomiky: nová sestava se stejnou RAM a lepším CPU ~15 l ("skoro moc na to, co na tom dělám nebo spíš nedělám").

projects/devops/state.md

@@ -5,7 +5,7 @@ timestamp: draft
 # Project devops
 
 ## Kde to je
-- **HW základna: Dell Optiplex 9010** (od 2026-09-18). Původní Proxmox server náhle zemřel (večer 2026-09-17, po vyjmutí RAM jen pískání speakeru, board mrtvý, root cause neznám). Do Optiplexu přesunuty RAM, disky i RTX 4060 — vše jede. BIOS měl problémy (celý přesun >1 h), změny v BIOSu se neukládají — k dořešení. Původní nvidia.hell incidenty (12.–13. 9.) se týkaly ještě původního stroje.
+- **HW základna: Dell Optiplex 9010** (od 2026-09-18). Původní server — **Dell Optiplex 9020** workstation z raných dob RSJ, dlouholetý server (měněny zdroj/kabely/větrák, přidána RTX 4060 (deník: 4060 Ti — neověřeno) + hromada disků) — náhle zemřel (večer 2026-09-17, po vyjmutí RAM pípání chybových kódů; podezření CPU/DDR/deska). Proměřitelná hypotéza: AliExpress kabel zdroj→deska (odcházející měnič). Do 9010 přesunuty RAM, disky i GPU — vše jede; BIOS měl problémy (celý přesun >1 h), změny v BIOSu se neukládají — k dořešení. Dlouhodobý kandidát na lepší host: HP Z440 z práce (Xeon E5-1650, 6c/12t, 32 GB, 4 volné sloty), pokud ho dostane z vyřazování; zvažováno i vlastní PC z chlívku jako Proxmox host + Windows VM přes RDP. Vyřčená lekce: zálohovat kontejnery z Proxmoxu (nemá se kam — PBS chybí).
 - LibreChat: běží jako podman kontejnery; jako Code Interpreter sandbox vybrán LibreCodeInterpreter (nsjail, 3 kontejnery). Research hotový (2026-09-13), rozhodnutí o nasazení (sdílená Docker VM vs dedikovaná Proxmox VM) ještě nepadlo.
 - Ollama na nvidia.hell: po incidentech 12.–13. 9. 2026 zaevidován root cause pádů — kauzální řetěz: ollama rozhoduje load podle VRAM ne volné RAM + vypíná mmap (podmínka na 9,5 GiB stroji nesplnitelná nikdy, regrese od 2026-06-05) + PLE host buffer u gemma4 + přerušený load leakuje napinovanou host paměť (neviditelná pro ps/nvidia-smi/cgtop, detekce jen `nr_foll_pin` delta v /proc/vmstat), uvolní **jen reboot** (rmmod driveru ověřeně NE). Cgroup pojistka (`MemoryMax=6G`, `MemorySwapMax=0`, bez MemoryHigh) ověřena zátěžovým testem: 240/240 SSH heartbeatů, load 3,41 vs 81 při incidentu. Skutečný zdroj zátěže = nanobot.hell (dávky přes ~10 modelů + embedding), LibreChat jen zesilovač. Reporty v `artifacts/2026-09-13_ollama-nvidia-full-report.md` (ucelený, s kuchařkou pro triáž) a `artifacts/2026-09-13_ollama-nvidia-negative-findings.md` (negativní zjištění), shrnutí v memory.md 2026-09-14. Zavržené cesty: earlyoom i jakákoli externí kill varianta, MemoryHigh pod MemoryMax, navýšení RAM (headroom konstanta 7,5 GiB), limit počtu modelů, OLLAMA_LOAD_TIMEOUT, upgrade ollamy, mmap override (neexistuje), ballooning (`balloon: 0` + pevná paměť), rmmod jako remedy.