Logs unter Linux: journalctl, /var/log, rsyslog und logrotate

Wenn ein Dienst nachts ausfällt, steht die Antwort fast immer in den Logs. Die Frage ist nur, wo Sie sie finden. In modernen Distributionen (Ubuntu, Debian, RHEL, Fedora, Arch) sammelt der Dienst journald die Ereignisse, gelesen werden sie mit dem Befehl journalctl. Zugleich schreiben viele Programme gewöhnliche Textdateien nach /var/log, und deren Größe überwacht logrotate. Im Folgenden erfahren Sie, wie Sie journalctl-Logs unter Linux praktisch nutzen, wo die übrigen Protokolle liegen und wie Sie bei der Rotation nichts Wichtiges verlieren.

Wo die Logs unter Linux liegen

Es gibt drei Quellen. Es hilft, sie sich als Karte vorzustellen:

• journald — das binäre Journal von systemd. Es nimmt Standardausgabe und Standardfehler aller Dienste, die Kernelmeldungen und syslog auf. Gespeichert wird es in /var/log/journal/ (dauerhaft) oder /run/log/journal/ (bis zum Neustart).
• /var/log — Textdateien. Sie werden von rsyslog (zum Beispiel /var/log/syslog, /var/log/auth.log) oder direkt von Anwendungen geschrieben: nginx, PostgreSQL, MySQL.
• Kernel-Ringpuffer — Meldungen von Treibern und Hardware, angezeigt mit dmesg oder journalctl -k.

Die meisten Dateien in /var/log sind nur für root oder die Gruppe adm lesbar. Deshalb müssen Sie die Lesebefehle oft mit sudo ausführen.

journalctl: die Grundbefehle

Ohne Argumente zeigt journalctl das gesamte Journal von den ältesten Einträgen an, über den Pager less. Das brauchen Sie selten, meist engen Sie die Auswahl sofort ein.

journalctl              # gesamtes Journal, von alt nach neu
journalctl -e           # direkt am Ende öffnen
journalctl -n 50        # die letzten 50 Zeilen
journalctl -r           # umgekehrt, neueste oben
journalctl --no-pager   # ohne less, praktisch für Skripte und grep

Im Pager funktionieren die gewohnten Tasten von less: / — suchen, G — ans Ende, q — beenden. Lange Zeilen werden auf die Bildschirmbreite gekürzt; mit den Pfeiltasten nach links und rechts scrollen Sie sie.

Logs eines bestimmten Dienstes: journalctl -u

Der häufigste Fall: Sie wollen sehen, was eine einzelne systemd-Unit geschrieben hat. Eine Datei suchen und durchgrepen müssen Sie dafür nicht:

$ sudo journalctl -u nginx -n 20
Oct 14 03:12:41 web1 systemd[1]: Starting nginx.service - A high performance web server...
Oct 14 03:12:41 web1 nginx[1834]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Failed with result 'exit-code'.

Die Option -u lässt sich wiederholen: journalctl -u nginx -u php8.2-fpm zeigt beide Dienste nach Zeit gemischt, was hilft, wenn ein Fehler an der Schnittstelle zweier Dienste entsteht. Für Benutzer-Units (systemctl --user) nutzen Sie journalctl --user -u name.

Logs in Echtzeit: journalctl -f

sudo journalctl -u nginx -f

Das ist das Gegenstück zu tail -f: Der Befehl zeigt die letzten 10 Einträge und wartet auf neue. Praktisch ist ein separates Terminal dafür, während Sie den Dienst neu starten oder einen Fehler nachstellen. Beenden lässt es sich mit Strg+C.

Filter nach Zeit und Start des Systems

Wenn Sie wissen, wann der Vorfall war, grenzen Sie den Zeitraum mit --since und --until ein. Beide verstehen genaue Datumsangaben ebenso wie relative Werte:

journalctl --since "2026-10-14 02:50" --until "2026-10-14 03:30"
journalctl --since "1 hour ago"
journalctl --since yesterday --until today
journalctl -u nginx --since "10 min ago"

Eine weitere nützliche Auswahl sind die Systemstarts. Hat sich der Server selbst neu gestartet, sucht man die Ursache am Ende der vorherigen Sitzung:

$ journalctl --list-boots
 -2 8f1c...  Sat 2026-10-12 09:01:12 UTC  Sun 2026-10-13 22:47:03 UTC
 -1 a7d2...  Sun 2026-10-13 22:48:30 UTC  Tue 2026-10-14 03:05:51 UTC
  0 c3e9...  Tue 2026-10-14 03:07:02 UTC  Tue 2026-10-14 09:15:40 UTC

$ journalctl -b -1 -e      # Ende des vorherigen Starts
$ journalctl -b            # nur der aktuelle Start

Die Liste der Starts gibt es nur, wenn das Journal auf der Festplatte gespeichert wird. Wie Sie das einschalten, steht weiter unten im Abschnitt zur Konfiguration von journald.

Filter nach Wichtigkeit: journalctl -p

Jeder Eintrag hat eine syslog-Priorität von 0 bis 7. Die Option -p zeigt die angegebene Stufe und alle wichtigeren:

journalctl -p err -b              # alle Fehler seit dem letzten Start
journalctl -p warning..err -u ssh # Bereich der Stufen für einen Dienst

Der Befehl journalctl -p err -b ist eine gute erste Prüfung nach einem Neustart oder einem Update: In Sekunden sehen Sie, was schiefgelaufen ist.

Suche und weitere Filter

journald speichert zu jedem Eintrag strukturierte Felder. Nach ihnen filtern Sie ohne grep:

journalctl _PID=1834                 # nach Prozessnummer
journalctl _COMM=sshd                # nach Programmname
journalctl _UID=1000                 # nach Benutzer
journalctl /usr/sbin/sshd            # nach dem Pfad der ausführbaren Datei
journalctl -k                        # nur Kernelmeldungen (wie dmesg)
journalctl -t CRON                   # nach dem syslog-Bezeichner
journalctl -g "Out of memory"        # Textsuche mit regulärem Ausdruck

Die Option -g (--grep) gibt es ab systemd 237. Auf älteren Systemen verwenden Sie die normale Pipeline journalctl --no-pager | grep .... Filter auf verschiedene Felder werden mit „UND“ verknüpft, daher liefert journalctl -u nginx -p err --since today nur die heutigen Fehler von nginx.

Ausgabeformate

Die Option -o ändert das Format. Die nützlichsten Varianten:

• -o short-iso — Zeit nach ISO 8601, gut vergleichbar mit den Logs der Anwendung.
• -o verbose — alle Felder eines Eintrags, einschließlich _SYSTEMD_UNIT, _PID, _BOOT_ID.
• -o json oder json-pretty — zur Verarbeitung in Skripten oder mit jq.
• -o cat — nur der Nachrichtentext, ohne Datum und Host.

journalctl -u myapp -o json --since today | jq -r '.MESSAGE'

journald konfigurieren: Speicherung und Größe

Die Einstellungen stehen in /etc/systemd/journald.conf. Überschreibungen legen Sie bequemer in /etc/systemd/journald.conf.d/*.conf ab. Der wichtigste Parameter ist Storage:

• persistent — das Journal wird auf die Festplatte in /var/log/journal geschrieben und übersteht einen Neustart.
• volatile — nur im Arbeitsspeicher, unter /run/log/journal.
• auto (Standard) — auf die Festplatte, wenn das Verzeichnis /var/log/journal existiert.

Auf manchen minimalen Images fehlt das Verzeichnis, und nach einem Neustart ist die Historie verschwunden. Dauerhafte Speicherung aktivieren Sie so:

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

Damit das Journal nicht die ganze Platte belegt, setzen Sie Grenzen:

# /etc/systemd/journald.conf.d/size.conf
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month

Standardmäßig beträgt SystemMaxUse 10 % der Größe des Dateisystems, höchstens aber 4 GB.

Das journalctl-Journal aufräumen

$ journalctl --disk-usage
Archived and active journals take up 1.8G in the file system.

sudo journalctl --vacuum-size=300M   # nicht mehr als 300 MB behalten
sudo journalctl --vacuum-time=2weeks # Einträge älter als zwei Wochen löschen
sudo journalctl --rotate             # aktive Dateien schließen, damit auch sie gelöscht werden können

Löschen Sie Dateien in /var/log/journal nicht mit rm. Der Befehl vacuum erledigt dasselbe sauber und fasst die gerade aktive Datei nicht an.

rsyslog: klassische Textlogs

rsyslog ist ein Dienst, der syslog-Meldungen annimmt (auch die, die aus journald weitergereicht werden) und sie nach Regeln in Dateien sortiert. Die Konfiguration liegt in /etc/rsyslog.conf und /etc/rsyslog.d/*.conf. Eine Regel besteht aus einem Selektor Quelle.Stufe und einer Aktion:

# /etc/rsyslog.d/50-default.conf (Ausschnitt)
auth,authpriv.*        /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
kern.*                 -/var/log/kern.log

Das Minuszeichen vor dem Pfad bedeutet, dass nach jeder Zeile nicht sofort auf die Festplatte synchronisiert wird. Das ist schneller, aber bei einem Absturz können die letzten Zeilen verloren gehen. Nach einer Änderung prüfen Sie die Syntax und starten den Dienst neu:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Der Hauptgrund, rsyslog neben journald zu betreiben, ist die Weiterleitung der Logs an einen zentralen Server. Eine Zeile schickt alles per TCP:

# /etc/rsyslog.d/90-remote.conf
*.* @@logs.example.com:514

Ein Zeichen @ steht für UDP, zwei @@ für TCP. Fällt der Server komplett aus, bleibt die Kopie der Logs auf einem anderen Rechner erhalten. Um aus einem Skript eine eigene Meldung in das Systemprotokoll zu schreiben, verwenden Sie logger:

logger -t backup -p user.err "Sicherung der Datenbank fehlgeschlagen"
journalctl -t backup -n 5

logrotate: Rotation der Logs

Textlogs wachsen endlos, solange sie niemand kürzt. Darum kümmert sich logrotate: Einmal am Tag (über cron oder den Timer logrotate.timer) benennt er die aktuelle Datei um, komprimiert alte und löscht die ältesten. Allgemeine Einstellungen liegen in /etc/logrotate.conf, Regeln für einzelne Programme in /etc/logrotate.d/.

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Eine Regel ohne Änderungen prüfen und die Rotation sofort auslösen:

sudo logrotate -d /etc/logrotate.d/myapp   # Trockenlauf mit Ausgabe der Details
sudo logrotate -f /etc/logrotate.d/myapp   # jetzt rotieren

Ein typischer Fehler ist, postrotate oder copytruncate zu vergessen. Dann schreibt die Anwendung über den alten Dateideskriptor weiter in das umbenannte app.log.1, und das neue app.log bleibt leer.

Textlogs lesen

Für Dateien in /var/log reichen die Standardwerkzeuge:

sudo tail -n 100 /var/log/syslog          # die letzten Zeilen
sudo tail -F /var/log/nginx/error.log     # verfolgen, auch über eine Rotation hinweg
sudo less +G /var/log/auth.log            # am Ende öffnen
sudo zgrep "Failed password" /var/log/auth.log.*.gz   # in komprimierten Archiven suchen
sudo grep -c " 500 " /var/log/nginx/access.log        # wie viele Antworten 500 waren

Beachten Sie tail -F mit großem F: Anders als -f öffnet es die Datei neu, wenn logrotate sie ersetzt.

Schritt für Schritt: einen nächtlichen Ausfall untersuchen

Den Fall „Dienst ist nachts abgestürzt“ gehen Sie am besten in dieser Reihenfolge durch:

1. systemctl status myapp — aktueller Zustand und die letzten Zeilen des Journals.
2. journalctl -u myapp --since "03:00" --until "03:30" — was der Dienst im Moment des Absturzes geschrieben hat.
3. journalctl -p err -b — gab es im selben Zeitraum weitere Fehler im System?
4. journalctl -k --since "03:00" -g "Out of memory|Killed process" — hat der OOM Killer des Kernels einen Prozess beendet?
5. Die Logs der Anwendung selbst in /var/log/myapp/, einschließlich der .gz-Archive.
6. Wenn der Server neu gestartet wurde: journalctl -b -1 -e.

Fazit

Für die tägliche Arbeit mit Logs unter Linux genügen wenige Befehle: journalctl -u für einen Dienst, -f für den Strom, --since und -p err zum Eingrenzen, -b -1 für die Analyse eines Neustarts. Textjournale liegen in /var/log, rsyslog sortiert und verschickt sie, und logrotate sowie journalctl --vacuum-* verhindern, dass Logs die Platte füllen. Journalctl, Rotation und Diagnose der Systemlast behandeln wir im Linux-Kurs in der Praxis.