Linux commando: journalctl

1. De basis

De taak van journalctl is om het systemd-journal te lezen en te filteren. Het journal is een gestructureerd log dat wordt bijgehouden door een achtergronddienst genaamd systemd-journald. Elk bericht van de kernel, van systemd zelf, en van elke dienst die het start, stroomt dat journal in. journalctl is het venster waardoor je het bekijkt.

Dit is belangrijk omdat het verandert hoe je problemen oplost. Op een oud systeem moest je weten welk bestand je moest openen: /var/log/syslog voor algemene berichten, /var/log/auth.log voor aanmeldingen, een apart bestand per applicatie. Met het journal vraag je het aan een gereedschap en versmal je van daaruit:

Een register voor het hele systeem, en een commando om het te bevragen: op dienst, op boot, op tijd, of op hoe ernstig het bericht is.

Dit artikel begint met het eenvoudigste gebruik en bouwt stap voor stap op naar filteren op unit en boot, prioriteitsniveaus, de gestructureerde velden onder elke regel, uitvoerformaten, en hoe je voorkomt dat het journal je schijf volloopt. Aan het eind voelt logs lezen op een systemd-machine als routine.

Het juiste mentale model: het journal is een database van logregels, geen tekstbestand. journalctl is het zoekgereedschap. Elke regel die je op het scherm ziet, is eigenlijk een record met veel velden, en de gewone uitvoer is slechts een vriendelijke weergave ervan.

1.1 Het eenvoudigst mogelijke gebruik

Draai journalctl zonder opties en het toont het hele journal, oudste eerst, in een pager:

$ journalctl
-- Journal begins at Wed 2024-05-01 09:12:04 CEST. --
May 01 09:12:04 xps kernel: Linux version 6.8.0-50-generic ...
May 01 09:12:04 xps kernel: Command line: BOOT_IMAGE=/boot/vmlinuz ...
...

De uitvoer opent in less, dus je kunt scrollen en zoeken met /, net als bij het lezen van een bestand. Druk op q om te stoppen. Op een machine die al weken draait, kan dit een heel lange lijst zijn, en daarom gaan de volgende secties allemaal over het versmallen ervan.

1.2 Meestal heb je root nodig

Een gewone gebruiker ziet alleen zijn eigen gebruikersdiensten en, op veel systemen, een beperkte weergave. Om het volledige systeemjournal te lezen, draai je het met sudo:

$ sudo journalctl

Op de meeste distributies geeft het toevoegen van je account aan de groep systemd-journal leestoegang tot het hele journal, zonder telkens sudo. Het lidmaatschap werkt vanaf je volgende aanmelding.

3. Een korte geschiedenis

Om journalctl te begrijpen moet je weten waar het vandaan komt, want het verving een manier van loggen die decennialang nauwelijks was veranderd.

Het grootste deel van de Unix-geschiedenis werd loggen gedaan door syslog: een dienst (zoals syslogd of later rsyslog) ontving berichten en voegde ze als tekstregels toe aan bestanden onder /var/log. Het was simpel, leesbaar voor mensen, en makkelijk te verwerken met grep, awk en vrienden. De zwakte was structuur: een logregel was slechts een tekenreeks, dus filteren op dienst, gebruiker of exacte tijd betekende tekst ontleden en hopen dat elk programma zijn regels op dezelfde manier opmaakte.

systemd, voor het eerst uitgebracht in 2010 door Lennart Poettering en Kay Sievers, wilde het oude init-systeem vervangen dat diensten bij het opstarten startte. Een paar jaar later voegde het project zijn eigen logdienst toe, systemd-journald, en daarmee het gereedschap journalctl. In plaats van platte tekst slaat het journal elke regel op als een set sleutel/waarde-velden in een geindexeerd binair bestand, zodat filteren en sorteren ingebouwd zijn.

Het journal heeft syslog niet volledig gedood. Veel systemen draaien rsyslog naast het journal, waarbij regels worden doorgestuurd zodat de klassieke tekstbestanden blijven bestaan voor gereedschappen en gewoontes die ze verwachten. Maar op een standaard moderne installatie is journalctl de belangrijkste manier om logs te lezen. Dit artikel is geverifieerd tegen systemd-versie 255.

5. Gemiddelde gebruiksgevallen

5.1 Logs voor een dienst: -u

Dit is het meest bruikbare filter. De vlag -u (kort voor unit) beperkt de uitvoer tot een systemd-unit, zoals een webserver of database:

$ journalctl -u nginx.service
$ journalctl -u ssh            # the .service suffix is optional

Combineer het met de vlaggen die je al kent voor een scherpe, praktische weergave:

$ journalctl -u nginx -n 50      # last 50 lines for nginx
$ journalctl -u nginx -f         # follow nginx live

In plaats van te jagen op het juiste logbestand, noem je de dienst en zie je precies zijn berichten, samengevoegd op tijdvolgorde.

5.2 Filter op tijd: --since en --until

De opties --since (-S) en --until (-U) beperken de uitvoer tot een tijdvenster. Ze accepteren exacte tijdstempels en vriendelijke woorden:

$ journalctl --since "2026-07-12 09:00:00"
$ journalctl --since "1 hour ago"
$ journalctl --since yesterday --until "09:00"
$ journalctl -u nginx --since today

Woorden als today, yesterday, en zinsdelen als 10 min ago worden direct begrepen. Zo beantwoord je "wat gebeurde er rond het moment dat de site eruit lag?" zonder door dagen aan geschiedenis te scrollen.

5.3 Alleen deze boot: -b

Een server kan meerdere keren zijn herstart. De vlag -b (kort voor boot) beperkt het journal tot een enkele boot. Zonder nummer betekent het de huidige boot:

$ journalctl -b          # everything since the last boot
$ journalctl -b -1       # the previous boot
$ journalctl --list-boots

Het laatste commando toont elke boot die het journal onthoudt, met een index en een tijdbereik:

$ journalctl --list-boots
IDX BOOT ID           FIRST ENTRY                  LAST ENTRY
 -2 8b909d28e49e4884  Sat 2026-06-20 10:20:39 CEST Sat 2026-06-20 15:35:36 CEST
 -1 6f4e7bd5d6ea468f  Sat 2026-06-20 15:36:13 CEST Sat 2026-06-20 16:24:37 CEST
  0 c62bfe02a8b64075  Sun 2026-06-21 13:28:43 CEST Sun 2026-06-21 15:19:26 CEST

De huidige boot is altijd 0, en oudere boots tellen af met negatieve nummers. Zo controleer je "ging er iets mis voor de laatste herstart?".

5.4 Filter op ernst: -p

Niet elk bericht is even belangrijk. De vlag -p (kort voor priority) houdt alleen regels op of boven een ernstniveau. Het journal gebruikt de acht klassieke syslog-niveaus:

Vraag om een niveau op naam of nummer, en je krijgt dat niveau en alles wat ernstiger is:

$ journalctl -p err          # errors, crit, alert, emerg only
$ journalctl -p warning -b    # warnings and worse, this boot

Filteren op err en hoger is een snelle manier om een druk log terug te brengen tot de regels die meestal aandacht verdienen. Je kunt ook een bereik geven in de vorm FROM..TO om de uitvoer vast te pinnen op een band van niveaus en de rest weg te laten:

$ journalctl -p err..alert    # only err, crit, and alert (not emerg, not warning)

5.5 Kernelberichten: -k

De vlag -k (kort voor dmesg, het traditionele kernelbericht-commando) toont alleen berichten van de kernel zelf, voor de huidige boot:

$ journalctl -k          # like dmesg, but from the journal

Hier zoek je naar hardwareproblemen: een falende schijf, een netwerkkaart die reset, of een out-of-memory-gebeurtenis.

5.6 Een crash onderzoeken: Boot-ID's als ankers

Wanneer je een onverwachte herstart of een beveiligingsincident onderzoekt, wordt de boot je onderzoekseenheid, en de Boot-ID is wat het verankert. Elke keer dat de machine start, kent de kernel een nieuwe, unieke identifier van 32 tekens toe, en het journal stempelt elke regel van die sessie ermee in het veld _BOOT_ID. Omdat de ID vast is voor de hele boot, identificeert het een sessie betrouwbaar, zelfs als de klok verspringt of bestanden worden geroteerd, wat de wandkloktijd op zichzelf niet kan beloven.

De relatieve index zag je eerder (-b -1 voor de vorige boot). Voor bewijsmateriaal wil je vaak de exacte boot, genoemd op zijn ID uit --list-boots:

$ journalctl -b 6f4e7bd5d6ea468f9b1cbe30f800c32d    # one exact boot, by its ID

De echte kracht komt van het combineren van het bootfilter met de andere die je al kent, om een scherpe vraag te stellen over een enkele sessie. Om de boot voor een crash te onderzoeken:

$ journalctl -b -1 -k -p err       # kernel errors from the previous boot
$ journalctl -b -1 -p err          # all errors and worse, previous boot
$ journalctl -b -1 -u sshd         # who touched ssh before the reboot

Dit is de alledaagse vorm van log-forensiek: kies de boot, versmal dan op de kernel, een prioriteit, een dienst of een tijdvenster tot alleen de relevante regels overblijven. Boot-ID's maken van "wat gebeurde er tijdens die ene sessie?" een precieze zoekvraag in plaats van een scroll door een samengevoegde tijdlijn.

7. Wat de meeste gebruikers niet weten

7.1 Elke regel is eigenlijk een record met veel velden

De gewone journalctl-uitvoer ziet eruit als tekst, maar elke regel is opgeslagen als een bundel velden. Vraag om het verbose-formaat en een enkele regel ontvouwt zich tot alles wat het journal erover weet:

$ journalctl -n 1 -o verbose
Thu 2026-09-24 08:58:47.550521 CEST [s=f6a6...;i=26de0c;b=84ee...]
    PRIORITY=6
    _HOSTNAME=xps
    _UID=0
    _GID=982
    _PID=1249
    _COMM=nordvpnd
    _EXE=/usr/sbin/nordvpnd
    _SYSTEMD_UNIT=nordvpnd.service
    _BOOT_ID=84ee2a04d2c94a348d1a43b1d1c09db4
    SYSLOG_IDENTIFIER=nordvpnd
    MESSAGE=HTTP call finished in 240ms

Dit is de kern van wat het journal anders maakt dan een tekstlog. Het programma leverde de MESSAGE, en het journal hechtte de rest automatisch: welk proces, welke gebruiker, welke dienst, welke boot. Omdat die velden geindexeerd zijn, is filteren op elk ervan snel en exact, zonder tekst te ontleden.

Een syslog-bestand onthoudt de zin. Het journal onthoudt de zin, wie hem zei, wanneer, bij welke boot, vanuit welk proces, en onder welke dienst, allemaal als aparte velden die je kunt bevragen.

7.2 Het journal kan vluchtig zijn: logs kunnen bij herstart verdwijnen

Hier is een verrassing die veel mensen betrapt. Of je logs een herstart overleven, hangt af van het bestaan van een map:

• Als /var/log/journal/ bestaat, is het journal persistent: het wordt naar schijf geschreven en over herstarts heen bewaard.
• Als die map niet bestaat, is het journal vluchtig: het leeft alleen in het geheugen onder /run/log/journal/ en wordt bij elke herstart gewist.

Op sommige minimale systemen is de standaard vluchtig, wat betekent dat journalctl -b -1 voor een eerdere boot niets teruggeeft, omdat de logs van die boot nooit werden bewaard. De instelling wordt bestuurd door Storage= in /etc/systemd/journald.conf. Om persistente logs te garanderen, zorg je dat de map bestaat en laat je journald ernaartoe wegschrijven:

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

Dit ene verschil verklaart een veelvoorkomende frustratie: "Ik herstartte om het op te lossen en nu is het bewijs weg." Op een server waar je om geeft, moet persistente opslag altijd aan staan.

7.3 Monotone tijdstempels overleven een klokwijziging

De tijdstempels die je normaal ziet, zijn wandkloktijd, en wandkloktijd kan verspringen. Wanneer NTP de klok corrigeert, of een beheerder hem met de hand instelt, verschuiven de gewone logtijden mee, wat de schijnbare volgorde van gebeurtenissen kan verstoren. Het journal registreert ook een monotone tijdstempel: seconden sinds de machine opstartte, die alleen maar vooruit telt. Vraag erom met het uitvoerformaat short-monotonic:

$ journalctl -b -o short-monotonic
[   12.345678] xps systemd[1]: Started NetworkManager.
[   15.892134] xps nginx[812]: nginx.service started.
[   18.456201] xps sshd[1123]: Accepted publickey for peter

Het nummer tussen haakjes is de verstreken tijd sinds het opstarten. Omdat het niet achteruit kan, geeft het een betrouwbare volgorde van gebeurtenissen, zelfs over een klokaanpassing heen, wat het het formaat van keuze maakt wanneer je exact reconstrueert wat er tijdens een boot of incident gebeurde. Het past van nature bij de Boot-ID uit sectie 5.6: de Boot-ID kiest de sessie, en de monotone klok fixeert de volgorde van gebeurtenissen erin, ook wanneer de wandklok niet te vertrouwen is.

7.4 Het journal kan verzegeld worden, maar het is niet versleuteld

Twee feiten over de veiligheid van het journal verrassen mensen, en beide zijn de moeite waard om te weten:

• Het journal is standaard niet versleuteld. Binaire opslag stopt terloops bewerken met een teksteditor, maar wie de bestanden kan lezen, kan de berichten lezen. Behandel het niet als een plek om geheimen te verbergen.
• Het journal kan manipulatie-aantoonbaar zijn. Een functie genaamd Forward Secure Sealing (FSS) ondertekent het journal periodiek met een sleutel, zodat latere wijzigingen aan oude regels kunnen worden gedetecteerd. Je zet het aan door een sleutelpaar te genereren:

$ sudo journalctl --setup-keys      # generate an FSS key pair
$ journalctl --verify               # check the journal for tampering

Verzegelen verbergt de inhoud niet; het bewijst of die achteraf werd gewijzigd. Dat onderscheid telt op een machine waar de logs bewijsmateriaal kunnen worden: FSS beantwoordt "is dit log gewijzigd?", niet "kunnen anderen het lezen?".

7.5 Waar journalctl stopt, nemen andere gereedschappen het over

Het journal leest zijn eigen opslag, en daar houdt het op. Een paar buren pakken het van daaruit op:

• systemctl status nginx toont de toestand van een unit en zijn laatste paar journal-regels samen, wat vaak genoeg is om te beginnen.
• dmesg leest de kernel-ringbuffer rechtstreeks; journalctl -k toont dezelfde berichten via het journal.
• rsyslog schrijft op veel systemen nog klassieke tekstbestanden in /var/log, handig voor gereedschappen die ze verwachten.
• Voor veel machines slikt een centrale logverzamelaar (zoals een ELK- of Loki-stack) de JSON-uitvoer van het journal, zodat je alle servers tegelijk kunt doorzoeken.

Deze grens kennen houdt je efficient: journalctl voor de geschiedenis van een machine, een verzamelaar wanneer je veel machines in een weergave nodig hebt.

9. Veelgemaakte fouten

9.1 Mythe versus werkelijkheid

9.2 Andere valkuilen om te vermijden

• Per ongeluk alleen de huidige boot lezen. Veel voorbeelden gebruiken -b, wat oudere boots verbergt. Laat -b weg, of gebruik -b -1, wanneer je geschiedenis van voor de laatste herstart nodig hebt.
• sudo vergeten. Als gewone gebruiker zie je misschien maar een deel van het journal. Gebruik sudo, of word lid van de groep systemd-journal, om alles te lezen.
• Het journal de schijf laten vullen. Als de ruimte opraakt, ruim oude regels dan veilig op met een vacuum in plaats van bestanden met de hand te verwijderen:

$ sudo journalctl --vacuum-size=500M    # keep at most 500 MB
$ sudo journalctl --vacuum-time=2weeks   # delete entries older than 2 weeks

• Naar grep pipen wanneer een vlag beter is. journalctl | grep nginx werkt maar is traag en onhandig. journalctl -u nginx of -g pattern laat het journal voor je filteren.
• Lokale tijd verwachten in scripts. Tijdstempels tonen standaard je lokale tijdzone. Voeg --utc toe wanneer je een stabiele, vergelijkbare tijd over servers heen nodig hebt.
• Niet weten dat journald berichten laat vallen onder belasting. Om zichzelf tegen een vloed te beschermen, beperkt journald de snelheid per dienst (standaard 10000 berichten in 30 seconden) en schrijft het dan een notitie dat het de rest heeft "Suppressed". Als een heel spraakzame dienst regels lijkt te missen, kan die de limiet hebben geraakt, niet gefaald. Verhoog RateLimitBurst= in /etc/systemd/journald.conf als je echt elke regel nodig hebt.