journalctl-Befehl: Verwendung, Logs nach Dienst und Journal-Größe aufräumen

Der Befehl journalctl ist das Werkzeug, mit dem du die Logs, die Dienste und der Kernel im systemd-Journal hinterlassen, auswählst und liest. Auf Linux-Systemen mit systemd sammelt systemd-journald diese Logs im Journal. Beim Lesen der Logs nach Dienst, Zeit und Priorität auf einem AlmaLinux-9-Server und einem Debian-12-Server sah ein normales Konto nur seine eigenen Logs, und ein Server, der sein Journal im Arbeitsspeicher hält, konnte keinen früheren Start auswählen.

Die Ausgaben unten stammen von den beiden Servern. Hostnamen, Konten, Boot-IDs, die Prozessnummern auf dem AlmaLinux-Server und das Release des systemd-Pakets wurden durch Beispielwerte ersetzt, und beide Server gaben die Zeiten in UTC aus.

1️⃣ So verwendest du den journalctl-Befehl und liest aktuelle Logs

Wenn du journalctl ohne Optionen ausführst, öffnet sich das Journal ab der ältesten Zeile in less. Für aktuelle Logs legst du deshalb mit -n die Zeilenzahl fest. Lässt du die Zahl nach -n weg, erscheinen 10 Zeilen.

journalctl -n 3

Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Deactivated successfully.
Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Consumed 3.934s CPU time.
Oct 28 07:14:07 server1 sudo[851987]: pam_unix(sudo:session): session closed for user user

Eine Zeile besteht aus Zeit, Hostname, dem Programm, das den Log geschrieben hat, samt Prozessnummer und der Meldung. Mit -r kehrt sich die Reihenfolge um, und die neueste Zeile steht oben. Im crond-Log des AlmaLinux-Servers stand die zuletzt geschriebene CMDEND-Zeile ganz oben.

journalctl -r -u crond -n 3

Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-f beendet sich nach der letzten Zeile nicht, sondern gibt neu eintreffende Zeilen laufend weiter aus. Auf dem Debian-12-Server blieb mit -q und -t myapp die letzte logger-Zeile auf dem Bildschirm stehen, und mit logger wurden zwei weitere Zeilen geschrieben. Die beiden Zeilen erschienen direkt darunter.

journalctl -q -f -n 1 -t myapp

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test
Oct 28 07:14:35 server2 myapp[347881]: follow line 1
Oct 28 07:14:36 server2 myapp[347877]: follow line 2

-f hört erst auf, wenn du Ctrl+C drückst. Nutze es also, um den Log zu beobachten, während ein Dienst neu startet.

In less werden Zeilen, die breiter als der Bildschirm sind, rechts abgeschnitten; den abgeschnittenen Teil siehst du mit den Pfeiltasten. Ausgaben in eine Pipe oder Datei laufen nicht über less. Um ohne less direkt im Terminal auszugeben, hängst du --no-pager an.

2️⃣ journalctl-Logs nach Dienst

Die aktuellen Zeilen mischen die Logs vieler Dienste. Um den Log eines einzelnen Dienstes zu sehen, gibst du daher mit -u den Unit-Namen an. Das .service am Ende des Unit-Namens kannst du weglassen.

journalctl -u crond -n 4

Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

Schreibst du -u zweimal, erscheinen die Logs beider Dienste gemischt in zeitlicher Reihenfolge. Als auf dem AlmaLinux-Server crond und nginx zusammen für den 18. Oktober von 08:00 bis 08:15 ausgewählt wurden, folgten auf vier crond-Zeilen um 08:01 zwei nginx-reload-Zeilen um 08:12.

journalctl -u nginx -u crond --since '2026-10-18 08:00' --until '2026-10-18 08:15'

Oct 18 08:01:01 server1 CROND[381522]: (root) CMD (run-parts /etc/cron.hourly)
Oct 18 08:01:01 server1 run-parts[381528]: (/etc/cron.hourly) starting 0anacron
Oct 18 08:01:01 server1 run-parts[381534]: (/etc/cron.hourly) finished 0anacron
Oct 18 08:01:01 server1 CROND[381518]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 18 08:12:30 server1 systemd[1]: Reloading nginx - high performance web server...
Oct 18 08:12:30 server1 systemd[1]: Reloaded nginx - high performance web server.

systemctl status zeigt unter dem Dienststatus nur die letzten 10 Log-Zeilen, ältere Logs prüfst du deshalb mit journalctl -u. Direkt nachdem du systemctl restart für einen Dienst ausgeführt hast, rufst du journalctl -u auf und prüfst den Start-Log.

Logs, die Skripte oder Cron-Jobs mit logger geschrieben haben, findest du über ihre Kennung (Identifier) statt über eine Unit. Hinter -t schreibst du denselben Namen, der bei logger nach -t stand.

logger -t myapp 'journalctl test message'

Auf dem Debian-12-Server gab logger nichts auf dem Bildschirm aus, und die geschriebenen Zeilen wurden mit -t myapp gefunden.

journalctl -q -t myapp

Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

-g lässt nur Zeilen übrig, deren Meldung einen bestimmten Text enthält. Schreibst du den Suchtext komplett klein, wird Groß- und Kleinschreibung ignoriert.

journalctl -u crond -g anacron -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron

-n zählt die Zeilen, bevor -g filtert. Von den letzten beiden crond-Zeilen blieb deshalb nur die eine mit anacron übrig.

3️⃣ Logs nach Zeitraum und nach Start

--since und --until legen Anfang und Ende des ausgegebenen Zeitraums fest. Steht zwischen Datum und Uhrzeit ein Leerzeichen, setzt du den Wert in einfache Anführungszeichen.

Auf dem AlmaLinux-Server begannen die letzten 2 Stunden mit den crond-Zeilen von 06:01; unten stehen die ersten vier davon.

journalctl -u crond --since '-2h' | head -4

Oct 28 06:01:01 server1 CROND[802930]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 06:01:01 server1 run-parts[802936]: (/etc/cron.hourly) starting 0anacron
Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-b lässt nur Logs seit dem aktuellen Start übrig. Wenn du suchst, warum ein Server neu gestartet hat, prüfe zuerst in der Startliste, ob noch Logs vom vorherigen Start vorhanden sind.

journalctl -b -u crond -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

--list-boots gibt für jeden im Journal erhaltenen Start die Nummer, die Boot-ID und die Zeiten der ersten und letzten Zeile aus.

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 4f1c2a9be0d34c7a8e6b5d20c1f3a7e9 Sat 2026-10-17 08:29:26 UTC Wed 2026-10-28 07:16:10 UTC

Der AlmaLinux-Server hält sein Journal nicht auf der Festplatte und hatte daher nur einen Starteintrag. Deshalb endete -b -1 für den vorherigen Start nur mit einem Hinweis.

journalctl -b -1

Specifying boot ID or boot offset has no effect, no persistent journal was found.

Logs eines früheren Starts kannst du mit -b -1 nur auf Servern lesen, die das Journal auf der Festplatte (/var/log/journal) speichern.

4️⃣ journalctl-Fehlerlogs und Kernel-Logs

-p wählt Zeilen nach der Priorität des Logs aus. Gibst du eine Stufe an, erscheinen diese Stufe und alle wichtigeren, und die Stufe kannst du als Namen oder als Zahl schreiben.

Nachdem mit logger eine Zeile der Stufe err geschrieben und mit -p err ausgewählt wurde, fiel die notice-Zeile mit derselben Kennung (journalctl test message) weg, und nur die err-Zeile blieb.

logger -t myapp -p user.err 'journalctl error test'; journalctl -q -t myapp -p err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

Verbindest du zwei Stufen mit zwei Punkten, wird nur dieser Bereich ausgegeben. Mit warning..err bleiben nur die Stufen Warnung und Fehler übrig.

journalctl -q -t myapp -p warning..err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

-k lässt nur Kernel-Meldungen übrig und gibt nur Zeilen seit dem aktuellen Start aus.

journalctl -k -n 3

Oct 26 10:14:25 server1 systemd-rc-local-generator[96245]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 10:47:57 server1 systemd-rc-local-generator[512078]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 11:01:10 server1 systemd-rc-local-generator[520023]: /etc/rc.d/rc.local is not marked executable, skipping.

Die letzten drei -k-Zeilen auf dem AlmaLinux-Server waren alle systemd-rc-local-generator-Zeilen. Diese Zeilen sind Meldungen, die in den Kernel-Log-Puffer geschrieben wurden. Sie werden daher mit _TRANSPORT gleich kernel gespeichert und erscheinen auch bei -k.

5️⃣ Ausgabeformate von journalctl

-o ändert das Format jeder Zeile. Der Standardwert short entspricht fast einer syslog-Datei, und short-iso stellt die Zeit auf das ISO-8601-Format samt Zeitzone um. Beim Wechsel auf short-iso auf dem AlmaLinux-Server kam +0000 ans Ende der Zeit.

journalctl -u crond -n 2 -o short-iso

2026-10-28T07:01:01+0000 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
2026-10-28T07:01:01+0000 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

cat entfernt Zeit und Hostname und gibt nur die Meldung aus. Nutze es, wenn du Meldungen an grep oder ein anderes Programm weitergibst.

journalctl -u crond -n 2 -o cat

(/etc/cron.hourly) starting 0anacron
(root) CMDEND (run-parts /etc/cron.hourly)

json und json-pretty geben die im Journal gespeicherten Felder als Namen und Werte aus. Wählst du Felder mit --output-fields aus, kommen die Felder für Cursor, Zeit und Boot-ID immer mit. Auch als auf dem Debian-12-Server nur vier Felder ausgewählt wurden, erschienen __CURSOR, _BOOT_ID und zwei Zeitfelder mit.

journalctl -q -t myapp -n 1 -o json-pretty --output-fields=MESSAGE,PRIORITY,SYSLOG_IDENTIFIER,_PID

{
	"__REALTIME_TIMESTAMP" : "1793171676664200",
	"_PID" : "347877",
	"SYSLOG_IDENTIFIER" : "myapp",
	"MESSAGE" : "follow line 2",
	"__CURSOR" : "s=2a6f0c1d9e8b47a3b5c4d3e2f1a0b9c8;i=1a2b3;b=b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47;m=17cf8fe36f5;t=65ee150cf1188;x=1f2e3d4c5b6a7980",
	"_BOOT_ID" : "b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47",
	"PRIORITY" : "5",
	"__MONOTONIC_TIMESTAMP" : "1636264982261"
}

6️⃣ Speicherort des Journals und Größe aufräumen

Ob das Journal im Arbeitsspeicher oder auf der Festplatte liegt, bestimmt der Wert Storage= in journald.conf. Der Standardwert auto speichert auf der Festplatte, wenn der Ordner /var/log/journal existiert, sonst im Arbeitsspeicher (/run/log/journal).

Der AlmaLinux-Server hatte keinen Ordner /var/log/journal, sein Journal lag deshalb nur in /run/log/journal.

ls -ld /var/log/journal /run/log/journal

ls: cannot access '/var/log/journal': No such file or directory
drwxr-sr-x+ 4 root systemd-journal 80 Oct 17 08:30 /run/log/journal

Der Debian-12-Server hatte beide Ordner, und sein Journal sammelte sich auf der Festplatte.

ls -ld /var/log/journal /run/log/journal

drwxr-sr-x+ 2 root systemd-journal   40 Oct  9 08:43 /run/log/journal
drwxr-sr-x+ 4 root systemd-journal 4096 Sep 24 12:52 /var/log/journal

Um Logs über einen Neustart hinaus zu behalten, stellst du Storage= in journald.conf auf persistent und startest systemd-journald neu. Laut offiziellem Handbuch wird der Ordner /var/log/journal bei Bedarf automatisch angelegt. Für diesen Artikel wurden die Einstellungen nicht geändert.

Ein Journal auf der Festplatte ist wie die Blackbox eines Flugzeugs, die man nach einem Vorfall herausholt und ausliest.

--disk-usage gibt die Gesamtgröße der archivierten Journal-Dateien und der gerade genutzten Dateien aus. Bei einem normalen Konto auf dem Debian-12-Server, mit per -q ausgeblendetem [Hint]-Hinweis oben, war das Ergebnis eine einzige Zeile: 6.6M.

journalctl -q --disk-usage

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

Die Höchstgröße des auf der Festplatte gespeicherten Journals legst du mit SystemMaxUse= fest. Ohne Wert gilt als Obergrenze 10% der Dateisystemgröße (höchstens 4G), und in der journald.conf des Debian-12-Servers stand 50M.

grep -v '^#' /etc/systemd/journald.conf | grep -v '^$'

[Journal]
SystemMaxUse=50M

Um alte Journale sofort zu verkleinern, legst du mit --vacuum-size die zu behaltende Größe oder mit --vacuum-time den zu behaltenden Zeitraum fest. Beide Befehle löschen Journal-Dateien und wurden daher für diesen Artikel nicht ausgeführt.

journalctl --vacuum-size=200M

--vacuum-size=200M löscht archivierte Journal-Dateien, die ältesten zuerst, bis die Gesamtgröße unter 200M liegt.

journalctl --vacuum-time=2weeks

--vacuum-time=2weeks löscht Archivdateien, die nur Zeilen älter als 2 Wochen enthalten.

vacuum löscht nur archivierte Dateien und lässt die gerade genutzten stehen. Auch nach dem Ausführen sinkt die Zahl von --disk-usage daher eventuell nicht bis auf die angegebene Größe.

Textlogs unter /var/log schreibt rsyslog, das unabhängig von journald arbeitet. Deshalb werden die beiden Logs unterschiedlich gelesen und verwaltet.

7️⃣ Leserechte und Optionen des journalctl-Befehls

🔲 Leserechte

Führst du journalctl mit einem anderen Konto als root aus, erscheint oben ein [Hint]-Text, und du siehst nur die Logs, die dieses Konto geschrieben hat. Bei der Suche nach nginx-Logs mit einem normalen Konto auf dem Debian-12-Server kam nach dem Hinweis nur [-- No entries --].

journalctl -u nginx -n 5

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
-- No entries --

Laut id -nG gehörte dieses Konto nur zu einer Gruppe und war nicht in den Gruppen adm oder systemd-journal, die der Hinweis nennt.

id -nG

user

Laut offiziellem Handbuch können Konten in den Gruppen systemd-journal, adm und wheel das gesamte Journal lesen. adm und wheel bringen weitere Rechte mit, die die Distribution festlegt, und wheel erlaubt oft auch Verwaltungsaufgaben. Für ein Konto, das nur Logs liest, passt daher die Gruppe systemd-journal.

usermod -aG systemd-journal user

Der usermod-Befehl, der die Gruppe hinzufügt, wurde für diesen Artikel nicht ausgeführt. Nach dem Hinzufügen meldest du dich neu an und prüfst die Gruppen mit id -nG. Ein Konto mit Administratorrechten sieht auch mit sudo journalctl alle Logs.

Den [Hint]-Text blendest du mit -q aus. Auch mit -q siehst du aber nur die Zeilen, die dieses Konto geschrieben hat. --user liest das Benutzer-Journal dieses Kontos und funktioniert nur auf Servern, die das Journal auf der Festplatte speichern. Auf dem Debian-12-Server, der sein Journal auf der Festplatte hält, erschienen die systemd- und logger-Zeilen dieses Kontos.

journalctl --user -n 3

Oct 28 07:12:35 server2 systemd[347665]: Reached target default.target - Main User Target.
Oct 28 07:12:35 server2 systemd[347665]: Startup finished in 181ms.
Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

🔲 Optionen des journalctl-Befehls

📌 Wichtige Optionen: Ergebnisse aus diesem Artikel

📎 Weitere Optionen: laut offiziellem Handbuch

🔲 Simulator für den journalctl-Befehl

Im Simulator unten kannst du selbst Befehle eingeben und aktuelle Logs, Logs nach Dienst, Zeiträume, Prioritäten und Ausgabeformate prüfen.

🔢 FAQ & empfohlene Inhalte

🧭 Befehle für Systeminfo · Einstellungen: empfohlene Inhalte 8 Artikel · 2 Quellen

🗂️ Befehle für Systeminfo · Einstellungen

▸📂 Systeminfo4

📄 CPU · RAM · Festplatte · OS-Infos 📄 uname · Kernel-Version 📄 free-Befehl 📄 uptime-Befehl

▸📂 Einstellungen2

📄 timedatectl-Befehl 📄 localectl-Befehl

▸📂 Logs2

📄 logrotate 📄 journalctl-Befehl

▸🪐 Referenzen2

📡 journalctl(1) — systemd 252 📡 journald.conf(5) — systemd 252

Linux · Systeminfo

Linux CPU Info: Befehle für CPU, RAM, Festplatte und OS-Informationen

Unter Linux bekommst du die Zahl der CPU-Kerne sofort mit einer Zeile: [nproc].

Artikel lesen →Aktueller Beitrag

Linux · Systeminfo

Befehle zum Prüfen der Linux-Kernel-Version und so prüfst du die Distributionsversion

Beim Betrieb von Linux musst du manchmal die Linux-Kernel-Version und die Version der Distribution prüfen.

Artikel lesen →Aktueller Beitrag

Linux · Systeminfo

Linux-Befehl free: Speicherstatus prüfen

Der Linux-Befehl free zeigt die Speichernutzung und den freien Speicher eines Servers und liest dafür die Speicherinformationen aus /proc/meminfo.

Artikel lesen →Aktueller Beitrag

Linux · Systeminfo

Linux-Befehl uptime (Serverlaufzeit & Load Average über 1, 5, 15 Minuten prüfen)

Der Linux-Befehl uptime prüft die durchschnittliche Systemlast und wie lange der Server schon läuft.

Artikel lesen →Aktueller Beitrag

Linux · Einstellungen

Zeitsynchronisation auf Linux-Servern: timedatectl (ab CentOS 7)

Datum und Uhrzeit sind unter Linux wichtig, weil bei falscher Zeit im Serverbetrieb die Zeiten von DB-Daten, Log-Daten und Zugriffen auf den Webserver nicht mehr übereinstimmen können.

Artikel lesen →Aktueller Beitrag

Linux · Einstellungen

[Linux] localectl-Befehl

Ab CentOS 7 werden viele Befehle in zusammengeführter Form bereitgestellt.

Artikel lesen →Aktueller Beitrag

Linux · Logs

Linux Logrotate: Konzept und Einstellungen

Linux Logrotate ist, wie der Ausdruck „Logs rotieren“ schon sagt, ein Kunstwort aus Log und Rotate.

Artikel lesen →Aktueller Beitrag

Linux · Logs

journalctl-Befehl: Verwendung, Logs nach Dienst und Journal-Größe aufräumen

Der Befehl journalctl ist das Werkzeug, mit dem du die Logs, die Dienste und der Kernel im systemd-Journal hinterlassen, auswählst und liest, und auf Linux-Systemen mit systemd sammelt systemd-journald diese Logs im Journal.

Artikel lesen →Aktueller Beitrag

📡journalctl(1) — systemd 252 📡journald.conf(5) — systemd 252

ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt^{(bei Aktionsrabatten sinkt er ↓)}, steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.