Zum Inhalt

Container-Status und Logs ansehen

Ungeprüft

Diese Anleitung ist noch nicht durchgespielt worden; Befehle, Bezeichnungen und erwartete Ausgaben können abweichen. Was noch zu prüfen ist, steht in todo/doku.md.

Nur nachsehen

Auf dieser Seite wird nichts geändert, nur nachgesehen. Was du auf dem Host darüber hinaus tun darfst, steht in Was man von Hand darf.

Ziel

Du weißt, ob die Container eines Hosts laufen, und hast die Logs eines Containers vor dir, um einen Fehler einzugrenzen.

Voraussetzungen

Jeder Container hat eine systemd-Unit mit seinem Namen und der Endung .service, etwa hedgedoc-server.service für den Container hedgedoc-server. Die Namen der Container stehen in der Stack-Datei der App hinter containers:.

Die meisten Befehle gibt es in zwei Formen: als Abkürzung mit cue cmd, die du auf deinem Rechner im Ordner des Hosts ausführst (syslet/werner oder syslet/containerhost) und die per SSH auf dem Host läuft, und direkt auf dem Host nach ssh werner.garage-lab.de. Die Abkürzungen stehen in syslet/syslet_tool.cue.

Schritte

1. Laufende Container ansehen

Bash
1
cue cmd ps

Direkt auf dem Host: podman ps.

Erwartet: eine Tabelle mit einer Zeile je laufendem Container, in der Spalte STATUS etwa Up 3 days oder Up 3 days (healthy). Fehlt ein Container in der Liste, läuft er nicht; steht dort (unhealthy), läuft er, aber sein Healthcheck schlägt fehl.

Gestoppte Container zeigt podman ps -a auf dem Host, mit Exited (<code>) in der Spalte STATUS.

2. Status der Unit ansehen

Bash
1
cue cmd -t unit=hedgedoc-server.service status

Direkt auf dem Host: systemctl status hedgedoc-server.service.

Erwartet: In der Zeile Active: steht einer dieser Zustände:

Active: Bedeutung
active (running) Der Container läuft.
activating (auto-restart) Der Container ist abgestürzt, systemd startet ihn gleich neu.
failed systemd hat aufgegeben; darunter steht oft Start request repeated too quickly. Weiter mit Gecrashten Dienst neu starten.
inactive (dead) Der Container wurde gestoppt, von Hand oder weil er laut Repo nicht laufen soll.

Unter der Zeile Active: folgen die letzten Zeilen aus dem Log.

3. Logs lesen

Fortlaufend, ab den letzten Zeilen:

Bash
1
cue cmd -t unit=hedgedoc-server.service logs

Erwartet: die letzten Zeilen des Logs, dann jede neue Zeile, sobald sie geschrieben wird. Mit Ctrl+C beendest du die Ausgabe.

Direkt auf dem Host, nur die letzten 100 Zeilen und ohne Mitlaufen:

Bash
1
journalctl -u hedgedoc-server.service -n 100 --no-pager

Die Logs der Unit enthalten die Ausgabe der App und dazu die Meldungen von systemd und Podman, etwa warum ein Container nicht starten konnte. Ab einem bestimmten Zeitpunkt, etwa seit dem letzten Neustart des Hosts, geht es mit journalctl -u hedgedoc-server.service -b bzw. --since "1 hour ago".

Nur die Ausgabe der App, ohne systemd und Podman, zeigt podman logs --tail 100 hedgedoc-server auf dem Host.

4. Speicher und CPU ansehen

Bash
1
cue cmd stats

Direkt auf dem Host: podman stats.

Erwartet: eine Tabelle, die sich laufend aktualisiert, mit Speicher (MEM USAGE / LIMIT) und CPU je Container; mit Ctrl+C beendest du sie. Steht ein Container dauerhaft nahe an seinem Limit, wird er bei mehr Last vom Kernel beendet; die Limits stehen in syslet/<host>/host.cue.

5. Hostnamen und Container zuordnen

Wenn du nur weißt, unter welcher Adresse eine App nicht erreichbar ist:

Bash
1
cue cmd ingress

Erwartet: eine Tabelle mit Container, Port, TLS und Hostname für alle Apps des Hosts, etwa hedgedoc-server mit md.garage-lab.de. Dieser Befehl läuft nur auf deinem Rechner und braucht keine Verbindung zum Host.

Prüfen

Du kennst den Zustand der Unit (Active:) und hast im Log die Meldung gefunden, die zum Fehler passt.

Wenn etwas schiefgeht