Message Bus Pitfalls (19.07.2026)

Kernproblem: Poll-Cron fehlt auf Agent B

Der Message Bus hat ZWEI unabhängige Komponenten:

Push (sofort) — mesh-send-to-b schiebt JSON via SCP in B's Inbox. Funktioniert sofort.
Poll (periodisch) — Ein Cron-Job auf B liest die Inbox, verarbeitet Nachrichten, schreibt Antwort in outbox.

Ohne #2 liegen Nachrichten für immer in der Inbox. Symptom: A sendet, Push erfolgreich, aber B antwortet nie. Kein Fehler — einfach kein Prozess, der die Inbox liest.

Diagnose

# 1. Nachricht senden
mesh-send-to-b "test" "ping-$(date +%s)"

# 2. Prüfen ob angekommen
ssh mehlzoerwer@172.24.34.142 'sudo ls -lt /root/.hermes/msg_bus/inbox/'

# 3. 60s warten, dann prüfen ob verarbeitet (inbox sollte leer sein)
sleep 60
ssh mehlzoerwer@172.24.34.142 'sudo ls /root/.hermes/msg_bus/inbox/'

# 4. Outbox prüfen (Antwort von B?)
ssh mehlzoerwer@172.24.34.142 'sudo ls -lt /root/.hermes/msg_bus/outbox/'

Lösung: Poll-Cron auf B

Variante A: System-Cron (empfohlen — keine LLM-Tokens)

# Auf B: /usr/local/bin/mesh-process-inbox.sh
#!/bin/bash
INBOX=/root/.hermes/msg_bus/inbox
OUTBOX=/root/.hermes/msg_bus/outbox
SENT=/root/.hermes/msg_bus/sent
for f in "$INBOX"/*.json; do
    [ -f "$f" ] || continue
    # Verarbeite Nachricht, schreibe Antwort
    # ... (implementiere Logik)
    mv "$f" "$SENT/"
done

# Cron: */1 * * * * /usr/local/bin/mesh-process-inbox.sh

Variante B: Hermes-Cron mit free-Modell

{
  "id": "b-msg-bus-poll",
  "name": "Message Bus Poll",
  "prompt": "Prüfe /root/.hermes/msg_bus/inbox/ auf neue JSON-Nachrichten. Verarbeite jede: lies topic+message, antworte in outbox. Lösche verarbeitete aus inbox.",
  "model": "google/gemini-2.5-flash:free",
  "provider": "openrouter",
  "schedule": "*/1 * * * *"
}

Fallback: SSH direkt

Wenn Poll-Cron nicht existiert und dringende Kommunikation nötig:

# Zustand direkt prüfen
ssh mehlzoerwer@172.24.34.142 'sudo cat /root/.hermes/msg_bus/inbox/*.json'

# Cron-Jobs direkt managen
ssh mehlzoerwer@172.24.34.142 'sudo python3 -c "..."'

# B rebooten
ssh mehlzoerwer@172.24.34.142 'sudo -n reboot'

SSH ist der ultimative Fallback — funktioniert immer, solange ZeroTier steht.

2.2 KiB Raw Permalink Blame History