Linux-Log-Verwaltung: journalctl-Befehle für systemd-Logs

Niveau: Anfänger
Geschätzte Dauer: ca. 20 Minuten
Ziel: Lernen, wie Sie System- und Dienstprotokolle abfragen, filtern und verwalten und mithilfe von Linux-Logs zur Fehlerbehebung Probleme lösen und die Verfügbarkeit des Servers sicherstellen.

Einführung

Eine zuverlässige Linux-Log-Verwaltung ist unerlässlich, um die Verfügbarkeit des Servers zu gewährleisten und eine Linux-Server-Diagnose durchzuführen. Bei der Verwaltung von Webservern müssen Sie Systemprotokolle mit journalctl analysieren, um die Ursache eines Problems schnell zu finden. Systemd (das Init-System und der Service-Manager der meisten modernen Linux-Distributionen) sammelt Systemprotokolle (allgemeine Aufzeichnungen von Systemvorgängen und systemweiten Ereignissen). Ein einzelnes Log (eine Aufzeichnung von Ereignissen, die innerhalb eines Betriebssystems oder einer Anwendung auftreten) wird von Systemd-journald (ein Systemdienst, der Logdaten sammelt und speichert) erfasst und im Journal (die binären Logdaten, die von systemd-journald erzeugt und verwaltet werden) abgelegt. Zum Anzeigen dieser Daten verwenden wir Journalctl (ein Kommandozeilenprogramm zum Abfragen und Anzeigen von systemd-Logs). Dieses Tutorial konzentriert sich darauf, mit journalctl-Befehlen die journalctl-systemd-Logs abzufragen, zu filtern und zu verwalten. Am Ende können Sie sicher auf der Kommandozeile arbeiten und Linux-Logs zur Fehlerbehebung einsetzen, um Probleme effizient zu lösen.

Voraussetzungen

Stellen Sie vor dem Start sicher, dass die folgenden Bedingungen erfüllt sind:

• Betriebssystem: Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12/13 oder AlmaLinux/Rocky 8/9/10
• Hardware- und Netzwerkanforderungen: keine (diese Anleitung verwendet grundlegende Kommandozeilenprogramme)
• Zugriff: sudo- oder root-Zugriff auf den Server
• Erforderliche Kenntnisse: grundlegende Nutzung der Linux-Kommandozeile

Schritt 1: Linux-Log-Verwaltung: Flüchtige und persistente Logs verstehen

Standardmäßig konfigurieren einige Systeme das Journal für flüchtige Logs (Logs, die nur im RAM gespeichert werden und beim Neustart verloren gehen). Für eine effektive Linux-Log-Verwaltung benötigen wir persistente Logs (Logs, die über Neustarts hinweg auf der Festplatte gespeichert bleiben), damit Sie Abstürze auch nach einem Neustart untersuchen können.

Führen Sie den folgenden Befehl aus, um Ihre Speicherkonfiguration zu prüfen:

sudo grep -i 'storage' /etc/systemd/journald.conf

Erwartete Ausgabe:

#Storage=auto

Die Ausgabe zeigt, ob der Speicher auf auto, persistent oder volatile gesetzt ist. Ein auskommentiertes #Storage=auto bedeutet, dass das Standardverhalten auto verwendet wird.

Unter Ubuntu 24.04 und Debian 13 existiert das Verzeichnis /var/log/journal bereits, und die persistente Protokollierung funktioniert ohne zusätzliche Konfiguration. Fehlt das Verzeichnis (etwa bei einer frischen AlmaLinux-Installation) und möchten Sie die persistente Protokollierung erzwingen, legen Sie das Verzeichnis an und starten Sie das systemd-Logging-System neu (der Dienst systemd-journald verwaltet dieses Verzeichnis):

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

Auf AlmaLinux-/RHEL-Systemen müssen Sie zusätzlich die Logs aus dem flüchtigen Speicherort /run/log/journal in den neuen persistenten Datenträgerspeicher übertragen (flush):

sudo journalctl --flush

Es sollte keine Ausgabe erscheinen. Das bestätigt, dass der Dienst erfolgreich neu gestartet wurde und nun persistente Daten auf die Festplatte schreibt.

Schritt 2: Grundlegende journalctl-Befehle für systemd-Logs

Um alle verfügbaren Einträge anzuzeigen, verwenden Sie den Standardbefehl.

Führen Sie den folgenden Befehl aus:

sudo journalctl

Erwartete Ausgabe:

May 20 10:00:00 server systemd[1]: Started Logging Service.
May 20 10:00:01 server kernel: Linux version 5.15.0-101-generic...

Sie sehen eine seitenweise Liste aller systemd-Logs Ihres Servers. Drücken Sie q, um den Pager zu beenden.

Um Logs effektiv mit journalctl zu analysieren, möchten Sie selten alles von Anfang an lesen. Mit dem Parameter -r können Sie die Ausgabe umkehren, sodass die neuesten Einträge zuerst erscheinen.

Führen Sie den folgenden Befehl aus:

sudo journalctl -r

Erwartete Ausgabe:

May 23 20:00:00 server sshd[1234]: Accepted publickey for user from 192.168.1.50...
May 23 19:59:58 server systemd[1]: Session 4 created for user.

Die neuesten Logeinträge erscheinen oben auf dem Bildschirm. Dies ist eine wichtige Technik, um nach einem Vorfall schnell Logs mit journalctl zu analysieren.

Schritt 3: Dienstprotokolle prüfen

Häufig müssen Sie eine bestimmte Unit (ein Objekt, das systemd verwalten kann) analysieren, etwa eine Service-Unit (ein Unit-Typ, der einen Dienst steuert, z. B. nginx oder sshd). Mit dem Parameter -u können Sie die Dienstprotokolle prüfen, zum Beispiel für den Webserver nginx.

Führen Sie den folgenden Befehl aus (vorausgesetzt, der Dienst ist installiert, z. B. über sudo apt install nginx -y oder sudo dnf install nginx -y):

sudo journalctl -u nginx

Erwartete Ausgabe:

May 23 18:00:00 server systemd[1]: Starting A high performance web server and a reverse proxy server...
May 23 18:00:01 server systemd[1]: Started A high performance web server and a reverse proxy server.

Sie sehen nur die Logeinträge des nginx-Dienstes. So lassen sich Fehler im Webverkehr von anderen Hintergrundereignissen des Systems trennen. Ist der Dienst nicht installiert, erscheint lediglich -- No entries --.

Um die Dienstprotokolle des SSH-Daemons zu prüfen, hängt der Unit-Name von der Distribution ab.

Für Ubuntu/Debian:

sudo journalctl -u ssh

Für AlmaLinux/RHEL/Rocky:

sudo journalctl -u sshd

Erwartete Ausgabe:

May 23 19:50:00 server sshd[1234]: Invalid user admin from 10.0.0.5 port 55432
May 23 19:55:00 server sshd[1235]: Accepted publickey for root from 10.0.0.2 port 44322

Sie sehen Authentifizierungsversuche und Ereignisse des SSH-Daemons.

Schritt 4: journalctl – Logs nach Zeit und Typ filtern

Bei großen Datenmengen benötigen Sie eine Logfilterung (das Eingrenzen der Logausgabe anhand bestimmter Kriterien). Die journalctl-Filterung von Logs nach Zeit ist besonders hilfreich, wenn ein Ausfall zu einem bekannten Zeitpunkt auftrat.

Um die seit dem letzten Systemstart erzeugten Meldungen zu sehen, prüfen wir die Boot-Logs (Aufzeichnungen von Ereignissen während des Systemstarts).

Führen Sie den folgenden Befehl aus:

sudo journalctl -b

Erwartete Ausgabe:

May 23 08:00:00 server kernel: Linux version 5.15.0-101-generic...
May 23 08:00:00 server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz...

Die Ausgabe beginnt mit dem allerersten Ereignis des aktuellen Bootvorgangs.

Für die zeitbasierte journalctl-Filterung verwenden Sie --since und --until.

Führen Sie den folgenden Befehl aus:

sudo journalctl --since "1 hour ago"

Erwartete Ausgabe:

May 23 19:00:00 server cron[567]: (root) CMD (/usr/local/bin/backup.sh)
May 23 19:05:00 server sudo[580]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/ls

Sie sehen alle Ereignisse der letzten 60 Minuten.

Um die Kernel-Logs (vom Linux-Kernel erzeugte Meldungen, typischerweise zu Hardware und Treibern) anzuzeigen, verwenden Sie den Parameter -k.

Führen Sie den folgenden Befehl aus:

sudo journalctl -k

Erwartete Ausgabe:

May 23 08:00:00 server kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex
May 23 08:00:01 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Sie sehen Meldungen auf Kernel-Ebene, die bei der Diagnose von Hardware- oder Treiberproblemen nützlich sind.

Schritt 5: Nach Priorität filtern

Jeder Eintrag hat eine Priorität (die einer Logmeldung zugewiesene Schweregradstufe). Die Stufen reichen von Debug (die niedrigste Prioritätsstufe, für detaillierte Informationen zur Fehlersuche) bis Error (eine Prioritätsstufe, die einen Fehler in einem Dienst oder Prozess anzeigt). Eine häufig geprüfte Stufe ist Warning (eine Prioritätsstufe für potenzielle Probleme, die derzeit noch keine Fehler sind).

Für die journalctl-Filterung von Logs nach Priorität verwenden Sie den Parameter -p.

Führen Sie den folgenden Befehl aus, um nur Fehler anzuzeigen:

sudo journalctl -p err

Erwartete Ausgabe:

May 23 10:15:20 server systemd[1]: Failed to start Custom Application Service.
May 23 14:30:00 server sshd[1122]: error: kex_exchange_identification: Connection closed by remote host

Sie sehen eine kompakte Liste, die nur Meldungen der Stufe „error“ enthält; der normale Betrieb wird ausgefiltert.

Führen Sie den folgenden Befehl aus, um Warnungen und Fehler anzuzeigen:

sudo journalctl -p warning

Erwartete Ausgabe:

May 23 10:15:15 server systemd-udevd[330]: vda: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/vda' failed with exit code 1.
May 23 10:15:20 server dhcpcd[400]: eth0: no IPv6 Routers available

Sie sehen sowohl Warnungen als auch Fehler und erhalten so einen breiteren Überblick über mögliche Probleme. Auf einem frischen Betriebssystem sind routinemäßige Warnmeldungen von Diensten wie multipathd, irqbalance, dhcpcd oder udev üblich, nicht jedoch kritische Dienstausfälle. Die genaue Ausgabe hängt stark von Ihrer Systemkonfiguration und Umgebung ab.

Schritt 6: Linux-Logs in Echtzeit überwachen

Beim Anwenden von Konfigurationsänderungen oder beim Reproduzieren eines Problems ist es am besten, die Linux-Logs in Echtzeit zu überwachen. Verwenden Sie dazu den Parameter -f (follow).

Führen Sie den folgenden Befehl aus:

sudo journalctl -f

Erwartete Ausgabe:

May 23 20:05:00 server sudo[2001]: user : TTY=pts/1 ; PWD=/ ; USER=root ; COMMAND=/bin/bash
May 23 20:05:00 server su[2002]: (to root) user on pts/1
May 23 20:05:00 server su[2002]: pam_unix(su:session): session opened for user root by user(uid=1000)

Sie sehen die neuesten Logeinträge; das Terminal bleibt aktiv und gibt neue Ereignisse aus, sobald sie auftreten. Drücken Sie Ctrl+C, um den Vorgang zu beenden.

Um die Logs des SSH-Daemons in Echtzeit zu überwachen, hängt der Unit-Name von der Distribution ab.

Für Ubuntu/Debian:

sudo journalctl -u ssh -f

Für AlmaLinux/RHEL/Rocky:

sudo journalctl -u sshd -f

Erwartete Ausgabe:

May 23 20:10:15 server sshd[2100]: Connection from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: Accepted publickey for admin from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: pam_unix(sshd:session): session opened for user admin by (uid=0)

Sie sehen SSH-Authentifizierungsversuche live, während sie stattfinden.

Schritt 7: Speicherplatz und Log-Rotation

Das systemd-Journal kann mit der Zeit stark anwachsen. Das Archivieren und Löschen alter Logs zur Platzersparnis nennt man Log-Rotation. Sie können prüfen, wie viel Speicherplatz das systemd-Journal aktuell belegt.

Führen Sie den folgenden Befehl aus:

sudo journalctl --disk-usage

Erwartete Ausgabe:

Archived and active journals take up 200.0M in the file system.

Die Ausgabe zeigt den insgesamt von Ihren Logdateien belegten Speicherplatz.

Um manuell eine Log-Rotation durchzuführen und Speicherplatz freizugeben, können Sie die Daten nach Zeit oder Größe bereinigen (Vacuum).

Führen Sie den folgenden Befehl aus, um nur die letzten 500 MB an Daten zu behalten:

sudo journalctl --vacuum-size=500M

Erwartete Ausgabe:

Vacuuming done, freed 0B of archived journals from /var/log/journal.

Die Ausgabe zeigt, dass alte Dateien gelöscht wurden, bis die Gesamtgröße unter 500 MB liegt.

Überprüfung

So stellen Sie sicher, dass Ihre Logging-Konfiguration korrekt funktioniert und der persistente Speicher aktiv ist:

1. Prüfen Sie, ob das Speicherverzeichnis für die Logs angelegt wurde:

   ls -ld /var/log/journal

   Sie sollten ein Verzeichnis sehen, das root gehört. Je nach Distribution lautet die Gruppe systemd-journal oder root (beides ist normal).

2. Bestätigen Sie, dass journald aktiv läuft:

   sudo systemctl status systemd-journald

   Der Dienst sollte den Status active (running) haben.

Fehlerbehebung

Wenn bei der Verwaltung der Logs Probleme auftreten, prüfen Sie diese häufigen Szenarien:

• Leere Dienstprotokolle (-- No entries --): Stellen Sie sicher, dass der Dienst tatsächlich installiert ist und läuft. Prüfen Sie außerdem, ob Sie den richtigen Unit-Namen für Ihre Distribution verwenden (z. B. ssh unter Debian/Ubuntu gegenüber sshd unter RHEL/AlmaLinux).
• Fehlendes Verzeichnis /var/log/journal: Auf manchen Systemen (wie AlmaLinux) müssen Sie dieses Verzeichnis manuell anlegen und den Logging-Dienst neu starten, um persistente Logs zu aktivieren. Wenn Sie diesen Schritt überspringen, verbleiben die Logs im flüchtigen Speicher (/run/log/journal).
• Zugriff verweigert (Permission denied): Wenn Sie die Logs nicht ohne sudo lesen können, stellen Sie sicher, dass Ihr Benutzer Mitglied der Gruppe systemd-journal oder adm ist (sudo usermod -aG systemd-journal $USER).

Änderungen rückgängig machen

Wenn Sie die persistente Protokollierung deaktivieren und zu flüchtigen Logs zurückkehren möchten (z. B. um Speicherplatz zu sparen):

1. Entfernen Sie das Verzeichnis für den persistenten Speicher:

   sudo rm -rf /var/log/journal

2. Starten Sie den Logging-Dienst neu, um den flüchtigen Speicher in /run/log/journal neu anzulegen:

   sudo systemctl restart systemd-journald

Fazit

Das war es. Sie kennen nun die Grundlagen der Linux-Log-Verwaltung. Mit den richtigen journalctl-Befehlen navigieren Sie effizient durch systemd-Logs, wenden Filter an und verwalten den Speicherplatz. Ob Sie nach einem Absturz Logs mit journalctl analysieren oder einfach den Zustand eines Dienstes prüfen: Die Beherrschung von journalctl ist ein zentraler Schritt zum Betrieb einer stabilen Infrastruktur.

Dokumentversion: 1.0
Zuletzt aktualisiert: Mai 2026
Verantwortlich: Team für technische Dokumentation