mesh-configs/skills/autonomous-ai-agents/mesh-file-task-queue/references/failover-poller-2026-08-06.md

Failover-Poller Reaktivierung + Update-Cadence (2026-08-06)

Ausgangslage

• Am 2026-08-03 wurde mesh-master-poller.sh deaktiviert (Flag AUSFALL_FALLBACK_AKTIV=0), weil das 30s-Fenster zu aggressiv war: VERPASST=30 < 1 Polling-Zyklus (30–60s), wodurch jeder frische Task (HelloWorld, Wissensbasis) fälschlich auf ziel_agent='beliebig' umgeleitet wurde.
• Am 2026-08-06 (Nutzer zufrieden mit Systemzustand) wieder aktiviert — aber robust statt aggressiv.

Nutzer-Grundregel (WICHTIG)

„zeiten erfragen noch mit problemlöser vorher!!!" — bevor Betriebs-Zeitparameter (Failover-Fenster, Polling-Intervalle) gesetzt werden, IMMER den Problemlöser konsultieren, nicht eigenmächtig raten. Ablauf: mesh-task-create.sh UnraidHermes "<auftrag>" brainstorming high 0.5 "<Briefing + JSON-Frage>" an einen online-rechenstarken Agenten (UnraidHermes), Ergebnis-JSON validieren, DANN umsetzen. Der 03.08.-Fehler kam genau von Setzen ohne Abstimmung.

Vom Problemlöser (UnraidHermes) empfohlene Parameter

{
  "verpasst_sekunden": 180,
  "modus": "nur_alarm",
  "ping_check": true,
  "begruendung": "180s = 3 volle Polling-Zyklen bei 30-60s Cron-Intervall. Nur-Alarm statt auto_relabel verhindert Fehlumlackierung wie am 03.08. Ping-Check: Alarm feuert nur wenn Ziel-Agent wirklich down, nicht bei Latenz/Auslastung."
}

Begründung:

• 180s statt 30s: 30s war < 1 Zyklus → jeder frische Task sofort "verwaist". 60s = 1 Zyklus (zu knapp, kein Cron-Jitter-Puffer). 180s = 3 Zyklen → ein online Agent hat 3 Chancen den Task zu sehen; ein beschäftigter Agent wird nicht fälschlich als weg erkannt.
• Ping-Check: ping -c1 -W2 <zt-ip> vor Alarm; nur wenn Ziel wirklich down → Alarm. Verifiziert 2026-08-06: frischer Task = still, alter Task + online Agent = still (kein Fehlalarm). Laptop war wieder online → korrekt kein Alarm.
• Modus nur_alarm: schreibt nur AUSFALL_ALARM ins Event-Log /srv/work/log/events.jsonl, Master entscheidet manuell. Kein Auto-Relabel (die Wurzel des 03.08.-Bugs). Späteres Upgrade auf auto_relabel NUR nach nachgewiesener Ping-Erkennungs-Stabilität.

Umsetzung in mesh-master-poller.sh

• AUSFALL_FALLBACK_AKTIV=1
• VERPASST=180
• Schleife über offen/*.json: Alter = now - anlage_ts; wenn >180s → Agent-IP aus Registry auflösen, Ping-Check; wenn online → continue (kein Alarm); wenn down → Event-Log-Eintrag (AUSFALL_ALARM).
• Cron: * * * * * /usr/local/bin/mesh-master-poller.sh >> /var/log/mesh-poller.log 2>&1 (alle 60s).
• Kein Auto-Relabel, kein beliebig.

Update-Cadence (Nutzer-Entscheid 2026-08-06)

Brainstorming über Rhythmus (Technik/KI-Experte/Nerd/Kaufmann) ergab: wöchentlich statt täglich.

	täglich	alle 3 Tage	wöchentlich
Risiko	klein, oft	mittel	kumuliert, 1× gebündelt
Aufwand	28×/Monat	10×/Monat	4×/Monat
Mesh-Sync	ständig driftend	ok	1× sauber synchron

Politik:

• Sicherheits-Hotfixes (SSH, Auth, Keys, ZeroTier) → sofort, nicht warten.
• Feature-/Routine-Updates → wöchentlich gebündelt; alle 4 Agenten in einem Zug + 1× Verifikation.
• Changelog vor dem Durchziehen kurz auf Breaking-Changes prüfen.
• Umsetzung: Cron-Job mesh-hermes-wochenupdate (Mo 06:00, deliver=telegram, no_agent) ruft /root/.hermes/scripts/update_mesh.sh — updatet Master + UnraidHermes .34.142 + SwitchHermes .20.26 + LaptopHermes .178.202 synchron (hermes update --yes via SSH + sshpass), verifiziert Versionen. Stille bei "kein Update nötig"; Meldung nur wenn es was zu tun gibt/Problem.

Verifikations-Hinweis

• Der Alarm-Zweig (echte Down-IP) konnte an dem Tag live nicht mehr getestet werden (alle Agenten online; destruktiver Test wurde angehalten). Kern-Verhalten (frisch=still, alt+online=still) verifiziert; der Down-Pfad ist trivialer Code, aber als "validiert" erst nach einem echten Ausfall anzusehen.