RootForge

journalctl: System-Logs lesen, filtern und auswerten

journalctl meistern: Logs nach Dienst, Zeit und Priorität filtern, Boots vergleichen, JSON-Export, Speicherverbrauch begrenzen und häufige Log-Muster verstehen – der komplette Guide.

7 min Lesezeit
  1. Wie das systemd-Journal funktioniert
  2. Journal persistent machen
  3. Grundlegende Befehle
  4. Nach Dienst filtern
  5. Nach PID oder Prozess filtern
  6. Nach Benutzer filtern
  7. Zeitbasiertes Filtern
  8. Relative Zeitangaben
  9. Absolute Zeitangaben
  10. Zeitzone beachten
  11. Prioritäten und Schweregrade
  12. Syslog-Prioritäten
  13. Boot-Logs vergleichen
  14. Nach Kernel-Panics suchen
  15. Kernel-Logs und Hardware-Probleme
  16. Ausgabeformate und Export
  17. Export für Analyse
  18. Journal-Speicher verwalten
  19. Dauerhafte Konfiguration
  20. Häufige Log-Muster erkennen
  21. Service-Start-Fehler diagnostizieren
  22. SSH-Brute-Force erkennen
  23. OOM-Killer (Out of Memory)
  24. Festplatten-Probleme
  25. Netzwerk-Probleme
  26. Praktische Aliase
  27. Fazit

journalctl: System-Logs lesen, filtern und auswerten

Wenn auf einem Linux-System etwas nicht stimmt, ist das Journal die erste Anlaufstelle. journalctl gibt dir Zugriff auf alle systemd-Logs – von Service-Abstürzen über Kernel-Meldungen bis zu Login-Events. Wer die Filteroptionen kennt, findet Fehler in Sekunden statt Minuten.

Wie das systemd-Journal funktioniert

Das systemd-Journal (systemd-journald) sammelt Logs aus mehreren Quellen:

┌────────────────────────────────────────────────┐
│           systemd-journald                     │
│                                                │
│  ← systemd-Services (stdout/stderr)            │
│  ← Kernel (dmesg)                              │
│  ← syslog (Kompatibilität)                     │
│  ← Audit-System                               │
│  ← systemd-Coredump                           │
└────────────────────────────────────────────────┘
         │
         ▼
   Binäres Journal
   /var/log/journal/    (persistent, wenn Verzeichnis existiert)
   /run/log/journal/    (nicht persistent, geht bei Reboot verloren)

Journal persistent machen

# Prüfen ob Journal persistent ist
ls /var/log/journal/
# Wenn leer oder nicht existent → nicht persistent

# Persistent machen
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

# Prüfen
journalctl --disk-usage

Grundlegende Befehle

# Alle Logs anzeigen (älteste zuerst, mit Pager)
journalctl

# Neuste Logs zuerst (reverse)
journalctl -r

# Letzte N Zeilen
journalctl -n 50
journalctl -n 100

# Logs live verfolgen (wie tail -f)
journalctl -f

# Ohne Pager (für Skripte/Pipes)
journalctl --no-pager

# Vollständige Zeilen (kein Abschneiden)
journalctl --no-pager -l

# Kurze Übersicht (kompaktes Format)
journalctl -o short

Nach Dienst filtern

# Logs eines bestimmten Services
journalctl -u nginx
journalctl -u nginx.service   # .service kann weggelassen werden

# Live-Logs eines Services
journalctl -u nginx -f

# Letzte 50 Zeilen eines Services
journalctl -u nginx -n 50

# Mehrere Services gleichzeitig
journalctl -u nginx -u mysql -u php-fpm

# Logs einer Unit-Datei
journalctl -u "meine-app*"   # Wildcards möglich

Nach PID oder Prozess filtern

# Logs eines bestimmten Prozesses (PID)
journalctl _PID=1234

# Logs eines Programms (alle Instanzen)
journalctl _COMM=bash
journalctl _COMM=sshd

# Logs eines ausführbaren Programms
journalctl _EXE=/usr/sbin/nginx

Nach Benutzer filtern

# Logs eines bestimmten Users (UID)
journalctl _UID=1000

# eigene User-ID herausfinden
id -u

# Logs von root (UID 0)
journalctl _UID=0

Zeitbasiertes Filtern

Relative Zeitangaben

# Heute
journalctl --since today

# Gestern
journalctl --since yesterday --until today

# Letzte X Zeitspanne
journalctl --since "1 hour ago"
journalctl --since "2 hours ago"
journalctl --since "30 minutes ago"
journalctl --since "1 day ago"
journalctl --since "1 week ago"

Absolute Zeitangaben

# Exakter Zeitstempel
journalctl --since "2026-02-18 10:00:00"
journalctl --since "2026-02-18 10:00:00" --until "2026-02-18 12:00:00"

# Datum ohne Uhrzeit (ab Mitternacht)
journalctl --since "2026-02-18"

# Kombiniert mit Service-Filter
journalctl -u nginx --since "1 hour ago"

Zeitzone beachten

# Logs in lokaler Zeitzone anzeigen
journalctl --since today

# UTC-Zeitstempel erzwingen (für Remote-Analyse)
TZ=UTC journalctl --since today

Prioritäten und Schweregrade

Syslog-Prioritäten

Zahl Name Bedeutung
0 emerg System nicht nutzbar
1 alert Sofortige Reaktion nötig
2 crit Kritischer Zustand
3 err Fehler
4 warning Warnung
5 notice Normaler, aber wichtiger Zustand
6 info Informativ
7 debug Debug-Meldungen 
# Nur Fehler und schlimmer (0-3)
journalctl -p err

# Nur Warnungen und schlimmer (0-4)
journalctl -p warning

# Nur kritische (0-2)
journalctl -p crit

# Genau eine Priorität (nicht "und schlimmer")
journalctl -p "4..4"   # nur warnings

# Bereich: zwischen warning und error
journalctl -p "3..4"

# Praktisch: Alle Fehler der letzten Woche
journalctl -p err --since "1 week ago" --no-pager

# Mit Service kombiniert
journalctl -u nginx -p err

Boot-Logs vergleichen

# Aktuellen Boot (seit letztem Start)
journalctl -b

# Letzten Boot (vor dem aktuellen)
journalctl -b -1

# Vorletzten Boot
journalctl -b -2

# Alle verfügbaren Boots auflisten
journalctl --list-boots
# IDX BOOT ID                          FIRST                        LAST
#  -5 abc123...                        2026-02-10 08:00:00          2026-02-10 18:00:00
#  -4 def456...                        2026-02-11 09:00:00          2026-02-11 19:00:00
#  -1 ghi789...                        2026-02-17 08:00:00          2026-02-17 22:00:00
#   0 jkl012...                        2026-02-18 08:00:00          now

# Fehler beim letzten Absturz (vorheriger Boot)
journalctl -b -1 -p err

# Kernel-Logs des letzten Boots
journalctl -b -1 -k

Nach Kernel-Panics suchen

# Boots die mit Kernel Panic endeten
journalctl --list-boots | while read idx bootid first last; do
    count=$(journalctl -b "$idx" 2>/dev/null | grep -c "Kernel panic" 2>/dev/null)
    [ "$count" -gt 0 ] && echo "Boot $idx: $count Kernel Panics"
done

Kernel-Logs und Hardware-Probleme

# Nur Kernel-Meldungen (entspricht dmesg)
journalctl -k

# Kernel-Logs des aktuellen Boots
journalctl -k -b

# Live-Kernel-Meldungen
journalctl -k -f

# Kernel-Fehler suchen
journalctl -k -p err

# Hardware-Fehler (MCE, Memory, Disk)
journalctl -k | grep -i "error\|fail\|critical\|mce\|oom"

# OOM-Killer (Out of Memory)
journalctl -k | grep -i "oom\|killed process"

# Disk-Fehler
journalctl -k | grep -iE "ata|scsi|nvme|io error"

# USB-Events
journalctl -k | grep -i "usb"

Ausgabeformate und Export

# Kurzformat (Standard)
journalctl -o short

# Kurzformat mit Mikrosekunden
journalctl -o short-precise

# Nur die Nachricht (ohne Metadaten)
journalctl -o cat

# JSON (eine Zeile pro Eintrag)
journalctl -o json -u nginx | head -3

# JSON (eingerückt, lesbar)
journalctl -o json-pretty -u nginx -n 1

# Verbose (alle Felder)
journalctl -o verbose -u nginx -n 3

Export für Analyse

# Logs in Datei exportieren
journalctl -u nginx --since "1 day ago" --no-pager > nginx-logs.txt

# Als JSON exportieren (für Log-Management)
journalctl -u nginx --since "1 day ago" -o json --no-pager > nginx-logs.json

# Binäres Journalformat exportieren (für Transfer zu anderem System)
journalctl --export > journal.export

# Statistiken über Logs
journalctl --header

# Welche Services haben wie viele Einträge?
journalctl --no-pager -o json | \
  python3 -c "
import json, sys, collections
units = [json.loads(l).get('_SYSTEMD_UNIT','unknown') for l in sys.stdin if l.strip()]
for unit, count in collections.Counter(units).most_common(20):
    print(f'{count:6d}  {unit}')
"

Journal-Speicher verwalten

# Aktueller Speicherverbrauch
journalctl --disk-usage

# Altes Journal löschen (nach Zeit)
sudo journalctl --vacuum-time=7days
sudo journalctl --vacuum-time=2weeks
sudo journalctl --vacuum-time=1month

# Auf bestimmte Größe begrenzen
sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-size=1G

# Auf bestimmte Dateianzahl begrenzen
sudo journalctl --vacuum-files=5

Dauerhafte Konfiguration

sudo nano /etc/systemd/journald.conf

[Journal]
# Maximale Gesamtgröße des persistenten Journals
SystemMaxUse=500M

# Mindestens so viel frei halten
SystemKeepFree=1G

# Maximale Größe einer einzelnen Journal-Datei
SystemMaxFileSize=50M

# Maximales Alter
MaxRetentionSec=1month

# Maximale Dateien
SystemMaxFiles=10

# Nicht-persistentes Journal (nur RAM)
# Storage=volatile

sudo systemctl restart systemd-journald
journalctl --disk-usage  # Neue Größe prüfen

Häufige Log-Muster erkennen

Service-Start-Fehler diagnostizieren

# Service status
sudo systemctl status mein-service

# Die letzten Logs des Services
journalctl -u mein-service -n 50 --no-pager

# Nur Fehler beim letzten Start
journalctl -u mein-service -b -p err

# Vollständiger Output ohne Kürzung
journalctl -u mein-service -n 20 -l --no-pager

SSH-Brute-Force erkennen

# Fehlgeschlagene Logins
journalctl _COMM=sshd | grep "Failed password" | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

# Alle Authentifizierungsversuche
journalctl -u ssh --since "1 day ago" | grep -E "Invalid|Failed|Accepted"

# Gesperrte IPs (fail2ban)
journalctl -u fail2ban | grep "Ban"

OOM-Killer (Out of Memory)

# OOM-Events finden
journalctl -k | grep -i "oom\|out of memory\|killed process"

# Detailinfo zu einem OOM-Kill
journalctl -k --since "1 hour ago" | grep -A5 "Killed process"

Festplatten-Probleme

# I/O-Fehler
journalctl -k | grep -iE "I/O error|blk_update_request|end_request"

# SMART-Fehler (wenn smartd läuft)
journalctl -u smartd | grep -i "error\|fail"

# Dateisystem-Fehler
journalctl -k | grep -iE "ext4|xfs|btrfs" | grep -i "error"

Netzwerk-Probleme

# Interface-Status-Änderungen
journalctl -k | grep -i "link\|eth\|ens\|wlan\|wlo\|enp"

# DHCP-Events
journalctl -u systemd-networkd
journalctl -u NetworkManager | grep -i "dhcp"

# Verbindungsabbrüche
journalctl --since "1 day ago" | grep -i "disconnect\|timeout\|refused"

Praktische Aliase

Füge diese in deine ~/.bashrc oder ~/.zshrc ein:

# Logs eines Services live verfolgen
alias jf='journalctl -f -u'             # jf nginx
alias je='journalctl -u'               # je nginx -n 50

# Nur Fehler
alias jerr='journalctl -p err -b --no-pager'

# Kernel-Fehler
alias jkerr='journalctl -k -p err -b --no-pager'

# Systemd-Fehler (alle Services)
alias jfail='journalctl -p err --since today --no-pager'

Fazit

Das systemd-Journal ist mächtiger als klassische Textlog-Dateien: strukturierte Daten, frei filterbar, mit Zeitstempeln, Prioritäten und Metadaten. Die wichtigsten Kombinationen:

  • journalctl -u service -f → Live-Logs verfolgen
  • journalctl -p err -b → Alle Fehler seit letztem Boot
  • journalctl -u service --since "1 hour ago" → Zeitbasierte Analyse
  • journalctl -k | grep -i error → Kernel-Probleme finden
  • journalctl --vacuum-time=7days → Speicher freigeben

War dieser Artikel hilfreich?

Verwandte Artikel

Systemadministration

SSH-Schlüssel erstellen und sicher verwenden – Schritt für Schritt

SSH-Schlüssel mit ed25519 erstellen, auf Server kopieren, ~/.ssh/config einrichten und SSH absichern – dieser Guide erklärt alles für Einsteiger und Entwickler.

Systemadministration

Nginx Webserver unter Linux einrichten – Installation, Konfiguration und SSL

Nginx 1.28 installieren, Virtual Hosts konfigurieren, Reverse Proxy einrichten und SSL mit Let's Encrypt aktivieren – der komplette Praxisguide für Linux-Server.

Systemadministration

systemd verstehen – Services, Timer und Logs auf Linux

systemd-Services erstellen, verwalten und debuggen: Unit-Dateien schreiben, Dienste automatisch starten, mit journalctl Logs lesen und systemd Timer als Cron-Ersatz nutzen.