hermes-erkenntnisse/nachtplan-2026-07-21.md

Nachtplan-Snapshot 2026-07-21 21:42 — Reboot-Persistenz VM302

Auftrag (Bär): Alle laufenden Jobs + Dienste auf VM302 reboot-fest machen (Kopien, Renders, Watcher, Dienste, CPU+GPU-Last) — ohne zu rebooten, nur Konfiguration + Verifikation. Zusatz: Pre-Reboot-Snapshot nach Nachtplan (Desktop) UND Forgejo (dieses Repo/diese Datei).

Ist-Zustand vor dem Eingriff

Ohne AtStartup-Trigger: WasabiSync-VideoTransfer, WasabiSync-U525566 (mcp, gar kein Trigger, nur manuell gestartet), ModelMigrationToM (mcp, gar kein Trigger), Barby-PseudoWatcher (SYSTEM, nur TimeTrigger), Barby-MatrixWatcher/-ModelSync/-Heartbeat (mcp, nur TimeTrigger), BarbyOutputSync (SYSTEM, nur TimeTrigger). Bereits AtStartup: JobLivenessWatchdog, BarbyOrchestrator, ComfyUI-Server (alle mcp, LogonType Password — Beweis, dass BootTrigger + Password-Logon grundsätzlich funktioniert, wenn das Konto-Passwort beim Registrieren bekannt ist).

Durchgeführte Änderungen

1) AtStartup-Trigger

• Barby-PseudoWatcher, BarbyOutputSync (SYSTEM/ServiceAccount-Logon, kein Passwort nötig): direkt per Set-ScheduledTask erweitert — bestehender TimeTrigger blieb, BootTrigger + Restart 3×/1min + StartWhenAvailable ergänzt. Laufende Instanz (BarbyOutputSync) nicht unterbrochen.
• WasabiSync-VideoTransfer, WasabiSync-U525566, ModelMigrationToM, Barby-MatrixWatcher, Barby-ModelSync, Barby-Heartbeat (mcp/Password-Logon): Set-ScheduledTask UND die COM-Route (RegisterTaskDefinition, auch mit LogonType S4U probiert) scheiterten beide ohne das mcp-Kontopasswort ("Der Benutzername oder das Kennwort ist falsch" bzw. Zugriff verweigert bei S4U). Windows verlangt bei jeder Neuregistrierung eines Password-Logon-Tasks das Passwort erneut — das ist harte Windows-Policy, keine reine Rechte-/Tool-Frage. Passwort wurde NICHT aus dem LSA-Secret-Store extrahiert (bewusst unterlassen — das wäre Credential-Dumping, nicht Konfiguration). Vaultwarden-Suche nach einem hinterlegten VM302/mcp-Windows-Passwort blieb erfolglos. → Stattdessen je ein SYSTEM-Begleit-Task <Name>-AtBoot neu registriert (kein Passwort nötig), identische Action, BootTrigger mit 45s Delay, Restart 3×/1-2min, StartWhenAvailable, MultipleInstancesPolicy IgnoreNew. Alle Skripte geprüft: keine Abhängigkeit von mcp-Profil oder Logon-Session (nutzen feste Pfade M:, B:, C:\ProgramData\rclone, localhost-APIs) — Ausnahme ModelMigrationToM, siehe Lücke unten. Verifiziert: Get-ScheduledTask zeigt jetzt bei allen 6 Original-Tasks weiterhin Boot=False (nicht änderbar ohne Passwort), aber bei allen 6 -AtBoot-Begleit-Tasks Boot=True, Ready.

2) Idempotenz (geprüft, kein Code-Umbau nötig)

• job-video-transfer.ps1 / job-u525566.ps1: rclone copy (kein sync) — kopiert nur Deltas, überspringt bereits identische Dateien. Resume nach Reboot funktioniert von Haus aus.
• copy-models-to-m.ps1: robocopy ohne /MIR, Standardverhalten kopiert nur wenn Ziel fehlt oder Quelle neuer/anders ist. Ebenfalls idempotent, kein /XO nötig.

3) Mounts + AutoLogon (nur geprüft, NICHT verändert — Bär-Auftrag: nicht ungefragt Passwort in

Registry schreiben)

• HKLM:\...\Winlogon: AutoAdminLogon = 0 (deaktiviert). DefaultUserName=mcp, DefaultDomainName=RDP.
• Lücke: R:\ (WasabiMount, LogonTrigger mcp) und Z:\ (RcloneMountStorageboxes, LogonTrigger matthias) sind reine Logon-Mounts. Ohne AutoLogon bleibt nach einem kalten Reboot keine interaktive Session automatisch offen → beide Laufwerke bleiben leer, bis sich jemand einloggt. ModelMigrationToM braucht genau diese beiden Pfade als Quelle (R:\comfyui, Z:\ki-modelle-backup). Vorschlag statt AutoLogon: wurde geprüft (UNC-Pfade \\10.10.10.1\vm302-modelle und \\u618602.your-storagebox.de\backup sind aktuell erreichbar, aber ob eine SYSTEM-Session ohne gecachte Credentials dieselben Freigaben erreicht, ist ungeklärt/nicht getestet ohne echten Reboot). Empfehlung: AutoAdminLogon=1 + DefaultPassword für mcp setzen — Bär-OK nötig, nicht selbst umgesetzt.
• Wasabi-Mount-Tasks selbst wurden NICHT angefasst (Absprache: das übernimmt der Wasabi-Sync/Mount- Agent parallel, keine Überschneidung).

4) Boot-Resume-Orchestrator

• Neu: M:\boot-resume.ps1 + Task Barby-BootResumeOrchestrator (SYSTEM, AtStartup, 2min Delay, Restart 2×/5min, ExecutionTimeLimit 1h).
• Logik: (1) ModelMigrationToM — prüft ob R:/Z: erreichbar UND ob letzter Lauf im Migrations-Log 0 FAIL meldet; sonst Re-Run (robocopy überspringt Fertiges). (2) Wasabi-Jobs — rclone size Quelle vs. Ziel, bei Ziel<Quelle und Task nicht schon laufend: Start-ScheduledTask. (3) ComfyUI-Orchestrator (Port 8197) — wartet bis gesund (max 2min), liest jobs_state.json, filtert Jobs mit status=error + "neu gestartet" (= durch einen Neustart abgebrochen), schreibt sie nach M:\boot-resume-pending-jobs.json. Kein automatisches Neu-Einreihen per Default (GPU-Zeit/Kosten, Duplikat-Risiko) — Parameter -ResubmitPendingRenderJobs vorhanden, falls gewünscht.
• Dry-Run erfolgreich (2026-07-21 21:30-21:33, -DryRun, keine Seiteneffekte):
  • R:\comfyui / Z:\ki-modelle-backup: beide aktuell erreichbar (weil matthias-Session offen ist).
  • ModelMigrationToM: kein "ENDE Migration"-Eintrag im Log → würde Re-Run anstoßen.
  • WasabiSync-VideoTransfer: Quelle 2.340.268.456.018 B, Ziel 133.503.175.414 B (läuft schon, State=Running → nicht angefasst, Begleit-Task deckt Kaltstart ab).
  • WasabiSync-U525566: Quelle 225.181.959.871 B, Ziel 210.507.535.710 B (93% fertig, Ready, NICHT laufend → würde im Realmodus neu gestartet).
  • Orchestrator: gesund, 1 durch einen früheren Neustart abgebrochener Job gefunden und nach M:\boot-resume-pending-jobs.json geschrieben.

Gesamtstatus

JA, mit einer bekannten Restlücke: nach einem Reboot laufen ComfyUI-Server, BarbyOrchestrator, JobLivenessWatchdog (schon vorher AtStartup), alle Barby-Watcher/-Sync (jetzt direkt oder über -AtBoot-Begleit-Task), beide Wasabi-Kopien und der neue Boot-Resume-Orchestrator automatisch an. Einzige Ausnahme: ModelMigrationToM braucht R:/Z:, die an interaktive Logons hängen — ohne AutoLogon (aktuell aus) bleibt das nach einem kalten kompletten kompletten Reboot liegen, bis sich mcp oder matthias einloggt. Boot-Resume-Orchestrator holt es dann automatisch nach, sobald die Laufwerke da sind (kein manuelles Nachschieben nötig) — nur der Zeitpunkt ist nicht "sofort nach Reboot", sondern "sobald jemand eingeloggt ist".

Kein Reboot durchgeführt. Alle Aussagen oben sind über Get-ScheduledTask, -DryRun-Lauf und direkte Zustandsprüfung (nicht behauptet) verifiziert.