Direkt zum Inhalt
ColliePWA

10/Documentation

Fehlerbehebung

Symptome in den Begriffen, nach denen Sie tatsächlich suchen würden

Symptome unten, der Reihe nach: Durchsuchen Sie die Seite nach Ihrem Problem. Os { NotFound } von herdr plugin · update meldet "not currently on a branch" · tailscale serve failed · antwortet nicht (Dienst startet nicht) · Telefon kann die URL nicht öffnen · Seite lädt, bleibt aber leer (weiße Seite, 403) · Passwortabfrage akzeptiert die Eingabe nicht · keine Push-Benachrichtigungen · nach einem Neustart verschwunden · Ein Bereich bleibt schmal · Collie verweigert das Öffnen eines tmux-Fensters · tmux list: output did not parse · herdr plugin list zeigt die alte Version an · veraltete Benutzeroberfläche nach einem Rebuild.

herdr plugin … schlägt mit Error: Os { code: 2, kind: NotFound, message: "No such file or directory" } fehl (Plugin-Installation schlägt fehl, Aktionsaufruf schlägt fehl). Dies ist kein Collie-Problem: Es bedeutet, dass der Herdr-Server nicht läuft, sodass dessen CLI den Control-Socket (~/.config/herdr/herdr.sock) nicht erreichen kann. Das Erkennungsmerkmal ist der unverarbeitete Fehler Os {…}: Ein erreichbarer Server antwortet auf Pfad-/Manifest-Probleme mit strukturiertem JSON (z. B. plugin_manifest_not_found), ein reiner Os { NotFound } ist also ein fehlgeschlagener Socket-Verbindungsaufbau, bevor Collie oder Ihr Pfad überhaupt geprüft wird. Dies betrifft link, install, action invoke (jeden Unterbefehl, der mit dem Server kommuniziert), während herdr plugin --help weiterhin funktioniert (dieser öffnet den Socket nie). Lösung: Starten Sie zuerst Herdr (herdr server &, oder starten Sie einfach die Herdr-TUI, wodurch der Server gebootet wird), prüfen Sie, ob ls ~/.config/herdr/herdr.sock nun existiert, und wiederholen Sie dann die Installation. herdr plugin list ist ein schneller Test: Wenn derselbe Fehler auftritt, ist der Server inaktiv.

update schlägt mit You are not currently on a branch fehl. Eine GitHub-Installation vor 0.23.1 (#63): herdr plugin install löst den Zustand, anstatt zu klonen, sodass der alte update keinen Zweig hatte, in den er per git pull einpflegen konnte. Die Behebung ist im Checkout enthalten, den sie repariert; es ist also eine Neuinstallation erforderlich, um sie zu übernehmen: Falls dies mit "You are not currently on a branch" fehlschlägt enthält die drei Befehle.

start gibt note: tailscale serve failed aus. Collie selbst läuft einwandfrei (weiterhin erreichbar unter 127.0.0.1). Lediglich das Tailnet-Ingress wurde nicht gestartet, und der Fehler von Tailscale selbst wird im Terminal über dem Hinweis angezeigt. Typische Ursachen: Ihr Benutzer ist nicht der Tailscale-Operator (sudo tailscale set --operator=$USER), der Knoten ist abgemeldet (tailscale up) oder auf Headscale- / .internal-Tailnet-Domains sind keine HTTPS-Zertifikate verfügbar. Genau dafür ist COLLIE_SERVE_MODE=http vorgesehen: Setzen Sie es in .env, dann bin/collie restart. Prüfen Sie es mit tailscale serve status.

serve besagt HTTPS certificates are not enabled on this tailnet. Nichts wurde veröffentlicht und nichts wartet. Öffnen Sie die Admin-Konsole, aktivieren Sie „Enable HTTPS“ und führen Sie collie serve erneut aus. Auf Headscale- / .internal-Domains gibt es keine Zertifikate zum Aktivieren; verwenden Sie stattdessen COLLIE_SERVE_MODE=http.

Banner zeigt ⚠ Collie isn't answering on :8787 yet an (Dienst startet nicht, Verbindung verweigert). Der Dienst wurde gestartet, aber der HTTP-Server antwortet nicht auf die Prüfung. Überprüfen Sie zuerst die Unit (systemctl --user status collie), dann bin/collie logs (oder journalctl --user -u collie -f zur Live-Verfolgung) nach der Ursache: Meist ist der Port bereits belegt (setzen Sie COLLIE_PORT in .env, dann bin/collie restart, wodurch auch tailscale serve für den neuen Port erneut ausgeführt wird) oder der erste Build ist fehlgeschlagen (dies steht im Protokoll; beheben Sie dies und führen Sie bin/collie build aus). Die Unit startet alle 5 s automatisch neu; sobald die Ursache behoben ist, wird sie in der Regel von selbst wieder aktiv.

Telefon kann die Tailnet-URL nicht öffnen. Gehen Sie die Liste durch: (1) Auf dem Telefon läuft die Tailscale-App und es ist mit demselben Tailnet wie der Host verbunden; (2) Sie öffnen die tailnet-URL des Banners (bin/collie url), nicht die local-URL, denn http://127.0.0.1:8787 funktioniert nur auf dem Host selbst; (3) MagicDNS ist in den DNS-Einstellungen Ihres Tailnets aktiviert (die URL ist ein MagicDNS-Name); (4) der Host ist online (prüfen Sie tailscale status auf dem Host oder senden Sie einen Ping vom Telefon aus über die Tailscale-App an den Host); (5) Ihre Tailnet-Richtlinie lässt tatsächlich Peers für diesen Knoten zu. Falls nicht, weist das Banner nun unter der Zeile tailnet darauf hin und sonst nichts: Die Eingangsschnittstelle ist korrekt veröffentlicht, das Zertifikat ist gültig und curl vom Host selbst liefert den Statuscode 200 zurück, da Loopback-Verkehr den Paketfilter nie passiert. Zwei Faktoren machen diesen Fall besonders irreführend: tailscale ping gelingt (Disco-Pings umgehen ACLs) und blockierter Datenverkehr wird verworfen statt abgewiesen, sodass das Telefon hängen bleibt und der Eindruck entsteht, der Server sei inaktiv. Beheben Sie dies in Ihrer ACL-Richtlinie (<https://login.tailscale.com/admin/acls> bei Tailscale; Ihre Richtliniendatei bei Headscale). Die Prüfung erfolgt nach dem Best-Effort-Prinzip und ist bewusst vorsichtig ausgelegt: Sie schlägt nur dann an, wenn der Filter dieses Knotens nichts zulässt (was ebenso bedeuten kann, dass noch kein anderes Gerät dem Tailnet beigetreten ist), und verhält sich ansonsten neutral.

Seite lädt, bleibt aber leer (leere Seite, weißer Bildschirm); API-Aufrufe schlagen 403 cross-origin rejected fehl. Sie greifen über einen Ursprung auf Collie zu, den die Anwendung nicht erwartet: eine benutzerdefinierte Domain oder einen Proxy, der Host umschreibt. Erlauben Sie den genauen öffentlichen Ursprung über COLLIE_ALLOWED_ORIGINS (siehe Konfiguration) oder konfigurieren Sie den Proxy so, dass er Host unverändert weiterleitet (die vierte Proxy-Anforderung in docs/deployment.md).

Eine Eingabeaufforderung für sudo (oder SSH-Passphrase oder gpg) nimmt Ihre Antwort nicht an. Verwenden Sie Eingeben in der Steuerungszeile, nicht Senden. Senden überprüft den eingegebenen Text durch Zurücklesen vom Bildschirm, bevor Enter gedrückt wird (#34). Eine Passwortabfrage deaktiviert die Bildschirmausgabe, sodass nichts zum Zurücklesen vorhanden ist. Eingeben sendet Ihre Tastenanschläge direkt an das Pane, einschließlich Enter. Eingaben in Eingeben werden weder gespeichert noch in einen Entwurf übernommen oder später wiederhergestellt; sobald Collie eine Passwortabfrage erkennt, wird auch der gespeicherte Entwurf verworfen (#103).

Keine Push-Benachrichtigungen empfangen. Lösen Sie manuell eine Benachrichtigung aus: bin/collie push-test. Es gibt drei Ursachen in der Reihenfolge, in der der Befehl sie unterscheidet: Push meldet, dass es deaktiviert ist (die Schlüssel haben die Bridge nie erreicht; führen Sie push-keys aus und starten Sie neu, siehe Web Push); Push meldet, dass keine registrierten Geräte vorhanden sind (dieses Telefon hat Benachrichtigungen unter Einstellungen → Benachrichtigungen nie aktiviert); oder Push meldet einen Versand, aber es kommt nichts an (das Telefon nutzt einen reinen HTTP-Ursprung, der keinen sicheren Kontext darstellt; die Einstellungen markieren dies als insecure).

Collie ist nach einem Neustart verschwunden. Unter Linux liegt dies fast immer am Lingering, führen Sie also loginctl enable-linger $USER aus (Neustarts überstehen). Unter macOS startet der launchd-Agent bei Anmeldung; prüfen Sie daher, ob Sie tatsächlich angemeldet sind (nicht am Anmeldefenster verweilen) und ob der Agent geladen ist: launchctl print gui/$(id -u)/herdr.collie.

Das Terminal eines Bereichs bleibt schmal, und eine Vollbild-App darin wird gestaucht (Copilot CLI, top, jede TUI, die in einen Streifen gezeichnet wird, während der Rest des Spiegels leer bleibt). Das Terminal des Bereichs ist so schmal, und Collie spiegelt es originalgetreu wider. Die Breite eines Herdr-Bereichs stammt von seinem Rechteck im Split-Raster des Tabs; ein Bereich, der sich einen Tab teilt, erhält also einen Teil der Spalten. Herdr wendet die Bereichsgeometrie nur während ein Desktop-Client verbunden ist an (herdr#1709): Wenn nichts verbunden ist, bleibt der verbleibende Bereich beim Schließen eines Splits bei der alten schmalen Breite hängen, und pane.zoom sowie pane.resize über den Socket ändern daran ebenfalls nichts. Collie kann dies von seiner Seite aus nicht beheben; es schreibt die Bereichsgeometrie überhaupt nicht (ADR 0031: Das Smartphone verschiebt das Terminal des Operators nur beim Antippen von Show in terminal). Daran ist nichts anwendungsspezifisch: top in einem Bereich mit 54 Spalten sieht identisch aus. Führen Sie tput cols im Bereich aus, um es zu messen. Das ist die tatsächliche Breite, und sie kann von dem abweichen, was herdr pane layout meldet. Um das Problem zu beheben, verbinden Sie einen Herdr-Client und zoomen oder verändern Sie dort die Größe des Bereichs (herdr pane zoom <pane-id> --on passt das Terminal an, sobald etwas verbunden ist), oder schließen Sie den Bereich und öffnen Sie einen neuen (#167).

Collie verweigert das Öffnen eines tmux-Fensters (die Neuer Tab des Telefons lehnt ab und nennt window-size). Kein Fehler in der Anfrage: Bei tmux unter 3.7 führt das Erzeugen eines Fensters, während das window-size des Servers auf manual steht, zum Absturz des gesamten Servers (tmux #4849, behoben in 3.7), und ein abgestürzter Server reißt jedes Fenster mit sich. Collie lehnt stattdessen ab und nennt das vorgefundene tmux. Die Behebung ist die ausgegebene Zeile – tmux set -g window-size latest auf diesem Server – oder tmux 3.7. Nichts anderes ist betroffen: Jede andere Aktion auf diesen Bereichen funktioniert weiterhin (Anforderungen unterliegt der gleichen Einschränkung).

Collie protokolliert tmux list: output did not parse und das Dashboard bleibt leer. Kein Absturz: Manche tmux-Versionen (3.4, nicht 3.6b) maskieren das Trennzeichen, das dieser Adapter liest, bei der Ausgabe einer -F-Auflistung. Collie verarbeitet inzwischen beide Formate. Eine Auflistung, die zu null Zeilen führt, wird daher als mux-Fehler gemeldet, statt als leere Herd gespeichert zu werden; die Fehlerzeile nennt die tmux-Version und die Anzahl der gelesenen Zeilen. Wenn dieser Fehler weiterhin auftritt, notieren Sie die Version von tmux -V und erstellen Sie ein Issue; die Korrektur gehört in den Adapter, nicht in Ihre .env.

herdr plugin list zeigt nach einem update die alte Version an. Erwartetes Verhalten: Herdr speichert das Manifest zwischen, das bei der Installation oder beim Verknüpfen eingelesen wurde. Maßgeblich für die laufende Version ist der Build-Stempel in der Fußzeile oder bin/collie version. Bei einem verknüpften Klon verknüpft update neu und behebt dies automatisch (erzwingen Sie es mit herdr plugin link "$(pwd)"); ab Herdr ≥0.8.0 wird das Manifest ohnehin neu vom Datenträger eingelesen.

Telefon zeigt nach einem Rebuild eine veraltete Benutzeroberfläche. Der Service-Worker-Cache einer PWA ist ursprungsbezogen (per-origin). Wenn Sie Collie über zwei Ursprünge aufrufen (eine eigene Domain und die reine host:8787), erhalten Sie zwei Installationen, die jeweils ihr eigenes Bundle zwischenspeichern. Die Fußzeile Build-Stempel (vX.Y.Z · sha · time) zeigt das aktuell ausgeführte Bundle an; Collie meldet das ausgelieferte Bundle über den Header X-Collie-Build und /api/config. Bei einer Abweichung bietet die Fußzeile "neuer Build – zum Aktualisieren tippen." Öffnen Sie andernfalls die PWA einige Male neu (der SW aktualisiert sich automatisch) oder löschen Sie die Websitedaten dieses Ursprungs. Empfohlene Vorgehensweise: Wählen Sie einen HTTPS-Ursprung und bleiben Sie dabei. (Über reines HTTP kann sich der SW nicht registrieren; stets aktuell, aber ohne PWA-Funktionen.)

Diese Seite auf GitHub bearbeiten