Journald is de logboekservice van Systemd en houdt bij alle moderne Linux-distributies de logs bij voor het besturingssysteem en toepassingen. We gaan in op de praktische analyse- en filterfuncties van Journald, zodat je altijd het overzicht kunt bewaren.
Van platte tekst naar gestructureerde logboeken
De logdienst Journald heeft zich in de Linux-wereld al lang verspreid en zit in de meeste distributies. Het verschil met vroeger is enorm. De klassieke logbestanden waren in platte tekst en bevatten meestal regels met de datum, tijd en het door een programma gegenereerde logbericht. Dat was technisch gezien heel eenvoudig, maar niet zonder valkuilen.
De logsyntaxis was niet uniform voor alle programma’s en vaak niet aanpasbaar, wat het gericht zoeken naar informatie bemoeilijkte. Er moest ook altijd op worden gelet dat elk logbestand werd ‘geroteerd’ om ervoor te zorgen dat het niet oneindig groot werd, de harde schijf niet tot de laatste byte vulde en het systeem zo lamlegde. En niet in de laatste plaats was het vaak een uitdaging om een bepaalde logregel te koppelen aan vermeldingen uit andere logboeken – de ontbrekende context maakt het opsporen van fouten lastig.
Journald doet veel dingen anders. Het slaat niet alleen regels tekst op, maar ook talrijke metadata. Wanneer vond de gelogde gebeurtenis plaats, welk programma heeft die geleverd, met welke proces-ID en welke commando’s?
Journald slaat dat alles niet op in leesbare tekstbestanden, maar ook in een geïndexeerde database in /var/log/journal, die je met de tool journalctl bevraagt. Daardoor kun je logboekvermeldingen heel gericht en efficiënt vinden, analyseren en opschonen. Logboekrotatie en -compressie regelt Journald automatisch.
Logs lezen met journalctl
Journalctl kan naar believen filteren, bijvoorbeeld op exacte tijdstippen, bepaalde opstartprocessen, trefwoorden en verzendende processen. Als je journalctl zonder opties invoert in een terminal, worden alle logbestanden uit het journal weergegeven die voor jouw gebruikersaccount toegankelijk zijn – te beginnen met de oudste logboekvermelding die aanwezig is op het systeem.
Systeemlogs mogen vaak alleen met verhoogde rechten bekeken worden. Het volstaat echter als de gebruiker die het programma oproept lid is van een beheerdersgroep zoals wheel, adm of sudo. Journalctl vraagt niet om een wachtwoord.
Meestal wordt de uitvoer van journalctl automatisch geopend in een pager zoals less, die op de meeste Linux-systemen geïnstalleerd. Bij less doorzoek je de tekst met / (een schuine streep) vooruit en met ? (een vraagteken) achteruit. Met de toets N spring je naar het volgende zoekresultaat en met Shift+N naar het vorige.
Speciale uitgave: Je gegevens veilig in de Europese Cloud
- Hoe je overstapt van Amerikaanse cloud naar Europese alternatieven
- Lees over zelf je data beheren zonder cloud
- Ontdek welke Office- en AI-alternatieven echt werken
Lees c’t nu tijdelijk al vanaf 5,99 per maand
- Onbeperkt toegang tot ct.nl
- Exclusieve thema-nieuwsbrieven over AI, security, netwerken en development
- Eenvoudig op te zeggen
Met de pijltjestoetsen scrol je regel voor regel omhoog en omlaag, met Page Up en Page Down ga je sneller (pagina voor pagina) door het document, en met Q kun je less weer sluiten. Wil je de uitvoer liever direct in de terminal zien, voeg dan de optie --no-pager toe aan het journalctl-commando.
Om in de wirwar van logs die zich op een typisch Linux-systeem opstapelen de informatie te vinden die voor jou interessant is, is de optie -e een goede eerste stap. Dat is de verkorte notatie voor --pager-end en toont je alleen de laatste 1000 vermeldingen en springt direct naar het einde van het logboek.
Dat is meestal handig als je een recent opgetreden probleem wilt analyseren. Zo hoef je niet met verouderde vermeldingen te werken. Als alternatief kun je de optie -r gebruiken, die de volgorde van het logboek omkeert en de nieuwste logregel bovenaan in de pager weergeeft.
Logs nauwkeurig filteren
De echte kracht van Journald komt tot uiting in de vele filterfuncties. Daar komt alle context goed van pas die Journald bij elk logbericht verzamelt. Zo krijgt elke bootprocedure die het systeem heeft doorlopen een unieke ID toegewezen. Daarmee kun je eenvoudig zoeken naar logboekvermeldingen sinds de laatste of een specifieke andere bootsessie.
Zo toont het commando journalctl -b -1 je de logboeken van de sessie vóór de laatste boot (0 = huidige boot, -1 = laatste boot, -2 = voorlaatste keer booten, enzovoort). Een -b zonder getal staat gelijk aan -b 0. Je kunt daarmee echter zo ver teruggaan in de tijd als Journald de loggegevens bewaart.
Een lijst van alle bootsessies, inclusief indexnummer en start- en eindtijden, krijg je met journalctl --list-boots. Om de informatie verder te beperken, helpt de optie -n. Die werkt net als tail. Met -n 10 geef je journalctl door dat het alleen de laatste tien logregels moet weergeven. Ook de optie -f of --follow werkt net als tail en geeft nieuw toegevoegde logregels in realtime weer.
Als je de logs alleen voor een bepaalde periode nodig hebt, kun je de uitvoer beperken met --since en --until (afkortingen -S en -U). Zo toont journalctl --since "2026-05-10 23:00" --until "2026-05-11 01:00" je alleen de logs van die twee uur. Je kunt daarbij gebruikmaken van het volledige scala aan mogelijke datumnotaties dat Systemd begrijpt – ook formaten zoals 20 min ago, yesterday en simpelweg 11:11 als tijdstip voor de huidige dag zijn geldig. Veel meer praktische voorbeelden vind je in het hoofdstuk systemd.time van de Systemd-documentatie (zie link bij dit artikel).
De optie -u (of --unit) selecteert alleen de logregels die afkomstig zijn van bepaalde Systemd-units, zoals services of mounts. Als je alleen geïnteresseerd bent in de meldingen van NetworkManager, filter je deze eruit met -u NetworkManager. Als je meerdere units wilt bekijken, gebruik je de optie gewoon meerdere keren om de logs van alle genoemde items in één uitvoer te lezen.
journalctl -u NetworkManager -u bluetooth.serviceNet als bij het zusterprogramma systemctl wordt de vermelding NetworkManager geïnterpreteerd als NetworkManager.service. Je kunt de expliciete vermelding dat het om een service gaat weglaten. Bij een mount of andere unit-types moet je daarentegen de volledige unit-naam opgeven, zoals nas-foto-sync.mount.
Bij de klassieke logbestanden was grep een populair hulpmiddel om alleen de regels weer te geven die een bepaalde tekenreeks bevatten, bijvoorbeeld om alle gevallen van een bepaalde foutmelding op te sporen. Dat is ook zonder problemen mogelijk met de uitvoer van journalctl, maar er is een betere manier. De optie -g of --grep biedt dezelfde functionaliteit in journalctl zelf en filtert binnen de database, wat bij grote logbestanden aanzienlijk sneller gaat dan elke logregel naar het externe programma grep te sturen.
Bij onze tests duurden dergelijke zoekopdrachten minder dan de helft van de tijd die het klassieke grep-commando nodig had – een echte prestatiewinst.
Net als bij de originele grep worden Perl-compatibele reguliere expressies (Regex) ondersteund, zodat je niet alleen op vaste strings kunt filteren, maar ook op gegevens die volgens een bepaald schema zijn opgebouwd, zoals IP-adressen. Het volgende commando doorzoekt het logboek op IPv4-adressen in het bereik dat typische thuisnetwerken gebruiken:
journalctl --grep '192.168.[0-9]{1,3}.[0-9]{1,3}'Journald slaat ook de prioriteit van vermeldingen op, wat je kunt vergelijken met logniveaus of de urgentie van vermeldingen. Die loopt van 0 (Emergency, meestal een volledige systeemcrash) tot 7 (Debug, heel veel berichten die bij normaal gebruik overbodig zijn, maar kunnen helpen bij het opsporen van fouten).
De prioriteitsniveaus hebben nummers en korte namen (zie de tabel), journalctl begrijpt beide. Als je met -p op prioriteit filtert, krijg je alle vermeldingen te zien die aan het niveau voldoen of nog urgenter zijn, dus bij -p 3 alles met een prioriteit van 3 of lager. Een combinatie zoals -p alert..warning of -p 1..4 geeft alle vermeldingen weer die tussen de genoemde niveaus liggen.
Prioriteitsniveaus in Journald
| Prioriteitniveau | Korte naam | Lange naam en beschrijving |
|---|---|---|
| 0 | emerg | Emergency: systeem is onbruikbaar |
| 1 | alert | Alert: zo snel mogelijk reageren |
| 2 | crit | Critical: kritieke toestand |
| 3 | err | Error: fouttoestand |
| 4 | warning | Warning: waarschuwing |
| 5 | notice | Notice: normale situatie maar wel opletten |
| 6 | info | Informational: puur informatief bericht |
| 7 | debug | Debug: berichten voor foutopsporing |
Als je die mogelijkheden voor logfiltering slim combineert, benut je het potentieel van journalctl optimaal en kun je je zo concentreren op de berichten die relevant zijn. Elk irrelevant bericht dat je op die manier wegfiltert, maakt het makkelijker om de berichten te vinden die je verder helpen. Om bijvoorbeeld de laatste tien logberichten van NetworkManager weer te geven met het logniveau error of lager, combineer je de opties als volgt:
journalctl -u NetworkManager -b 0 -n 10 -p ‘err’Log-metadata in een oogopslag
Klassieke kernellogbestanden, die vóór de introductie van Journald in /var/log/messages of /var/log/kern.log stonden, worden weergegeven met het commando journalctl -k. Intern wordt dat commando vertaald naar de aanroep journalctl -b 0 _TRANSPORT=kernel. Dat commando filtert op logregels die sinds de huidige opstart zijn toegevoegd en waarvan het metadataveld _TRANSPORT de waarde kernel bevat. Zo maak je gebruik van de gegevensvelden – die Journald aan elke logboekvermelding toevoegt – door die als filtercriterium te gebruiken.
Als je wilt weten welke metadata Journald überhaupt opslaat, geeft de optie --output verbose je een overzicht van alle metadata die een vermelding bevat. Het standaardformaat (--output short) bevat alleen een tijdstempel, de hostnaam van het systeem en het eigenlijke logbericht en is daarmee gebaseerd op de klassieke syslog-bestanden.
Sat 2026-05-16 10:53:49.904340 CEST [s=591c15aadefe4f2aa7aaf9927dea74fd;i=2d70ac38;b=2ffd4e83d1d94c9fbe1358be5bab6f0a;m=3ad1444ee1f6;t=651eb77d56e22;x=8f914b231c93e368]
_TRANSPORT=syslog
PRIORITY=6
SYSLOG_FACILITY=3
_SELINUX_CONTEXT=unconfined
_SYSTEMD_SLICE=system.slice
_BOOT_ID=2ffd4e83d1d94c9fbe1358be5bab6f0a
_MACHINE_ID=52d292c5f646405ca2c592186b889d31
_HOSTNAME=samosa
_RUNTIME_SCOPE=system
_UID=0
_GID=0
_CAP_EFFECTIVE=1ffffffffff
SYSLOG_IDENTIFIER=smartd
SYSLOG_PID=1973
_PID=1973
_COMM=smartd
_EXE=/usr/sbin/smartd
_CMDLINE=/usr/sbin/smartd -n
_SYSTEMD_CGROUP=/system.slice/smartmontools.service
_SYSTEMD_UNIT=smartmontools.service
_SYSTEMD_INVOCATION_ID=c5dc00335f384ad5a3e2e2a8e3fd944f
SYSLOG_TIMESTAMP=May 16 10:53:49
MESSAGE=Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 176 to 181
SYSLOG_RAW=<30>May 16 10:53:49 smartd[1973]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature Celsius changed from 176 to 181
Journald bewaart bij elke gebeurtenis een hele reeks bruikbare metadata, die je met het commando journalctl –output verbose allemaal kunt bekijken.
Met de optie --output (-o) kun je het uitvoerformaat wijzigen en heb je de keuze uit een groot aantal ondersteunde weergavevormen. Naast verbose zijn er bijvoorbeeld ook json en json-pretty. De optie json geeft je een gestructureerde uitvoer in JSON-formaat met één regel per journal-vermelding. Ideaal om logs verder te verwerken of te analyseren met externe programma’s.
Het uitvoerformaat json-pretty levert een opgemaakte en gekleurde versie hiervan, wat de overzichtelijkheid ten goede komt.
De meest leesvriendelijke uitvoeroptie is verbose, die alle metadata bevat. Elk bericht begint met een tijdstempel, de gegevensvelden volgen regel voor regel daaronder.
Welke uitvoeroptie je ook kiest, in elk daarvan vind je het veld _TRANSPORT, waarin is opgeslagen via welke route het bericht aan Journald geleverd is. Zo werkt de hierboven beschreven matching op berichten die rechtstreeks van de kernel kwamen.
In de metadatavelden staat allerlei interessante informatie die in lastige situaties kan helpen bij het opsporen van fouten. Sommige, zoals _UID, _GID en _HOSTNAME, spreken grotendeels voor zich – ze verwijzen altijd naar de gebruiker, de groep en de host waarop het proces is gestart dat de betreffende logregel gegenereerd heeft.
Volgens hetzelfde principe als _TRANSPORT=kernel hierboven kun je de logberichten op elk willekeurig veld filteren, bijvoorbeeld _UID=1000. Een ander handig veld is _SYSTEMD_INVOCATION_ID, dat staat voor een uitvoering van een Systemd-unit.
Om dus alle logboekvermeldingen te vinden die een dienst van het begin tot het einde heeft geschreven, kopieer je gewoon de volledige metadataregel en plak je die in een journalctl-query. Voor extra context kun je met dezelfde ID het gelijknamige veld INVOCATION_ID (of USER_INVOCATION_ID als het om een gebruikersservice gaat) opvragen voor alles wat Systemd zelf over deze uitvoering te zeggen had.
Alle Journald-vermeldingen bevatten het veld _CURSOR, dat gevuld is met een zeer lange tekenreeks. Dat is een unieke identificatie van elk logbericht, die gebruikt kan worden om naar de juiste plek in een log te springen. De optie -c of --cursor gevolgd door de bijbehorende tekenreeks toont vermeldingen vanaf het betreffende logbericht. Noteer de cursorwaarde en gebruik de optie om de plek later tijdens een loganalyse makkelijk terug te vinden.
Meer veiligheid door Trusted Fields
Alle velden in een logboekvermelding die met een onderstrepingsteken beginnen, zijn zogenaamde Trusted Fields. Hun inhoud wordt door Journald zelf gegenereerd wanneer het het logboekbericht verwerkt, en het verzendende proces kan die niet wijzigen. Dat kan relevant zijn op het gebied van veiligheid.
Als er malware op het systeem is binnengedrongen, kan deze vooral het MESSAGE-veld van een logbericht vervalsen. De gegevens over van welk proces, welk uitvoerbaar bestand, welke gebruiker en welke groep de vermelding afkomstig is, zijn daarentegen onveranderlijk.
Vooral in situaties waarin forensisch IT-onderzoek nodig is, is het erg waardevol om op dergelijke gegevens te kunnen terugvallen. Terwijl malware bij klassieke logboeksystemen met leesbare tekst nog meer mogelijkheden had om zijn sporen uit te wissen, kan Journald helpen om dergelijke incidenten achteraf aan het licht te brengen.
Het veld SELINUX_CONTEXT is een voorbeeld van een nuttig Trusted Field. Als SELinux (een toegangscontrolesysteem binnen kernel) ingeschakeld is, kom je zo de beveiligingscontext te weten van het aanroepende proces.
Alle velden waarvan de naam niet met een onderstrepingsteken begint, worden direct door het loggende programma ingevuld en zo naar Journald verzonden. MESSAGE bevat bijvoorbeeld het eigenlijke logbericht, precies zoals het verzonden is.
De optie --output-fields is handig als je zelf wilt bepalen welke gegevensvelden worden weergegeven. Vooral bij het analyseren van grotere hoeveelheden gegevens loont het de moeite om de uitvoer te beperken tot de velden die je echt nodig hebt.
Daarvoor kies je eerst een van de uitvoertypen die normaal gesproken alle gegevens weergeven, zoals json of verbose. Gescheiden door komma’s kun je alle gegevensvelden opgeven die je nodig hebt. Sommige metagegevens (zoals _CURSOR en een tijdstempel) zijn standaard altijd aanwezig.
Om bijvoorbeeld alle mislukte SSH-aanmeldingspogingen te laten weergeven, voer je het volgende commando uit.
journalctl -o json --output-fields ="MESSAGE" _EXE "=/usr/sbin/sshd" --grep 'Invalid user'De weergegeven gegevensrecords kun je vervolgens met andere software verder analyseren – dankzij het JSON-formaat zonder foutgevoelige plaintext-parsing en met alleen de gegevens die je nodig hebt.
Voor _EXE is er ook een afkorting. Als je alleen het pad naar een willekeurig uitvoerbaar bestand als argument opgeeft, bijvoorbeeld journalctl /usr/bin/sshd, dan krijg je alleen de logberichten daarvan te zien.
Journald-configuratie
Meestal leveren Linux-distributies een journald.conf mee, die je kunt vinden in /etc/systemd/ of /usr/lib/systemd/. Daar staan veel opties vermeld, maar ze zijn uitgecommentarieerd. Dat zijn – ter referentie – de standaardwaarden die zijn ingebouwd en die Journald gebruikt, tenzij er expliciet andere zijn ingesteld.
Voor de meeste gevallen zijn die instellingen prima. Bij meer specifieke eisen kun je echter ook je eigen waarden instellen. Maak daarvoor de map /etc/systemd/journald.conf.d aan en voeg daar een eigen configuratiebestand toe. De instellingen daarin ‘overschrijven’ dan de standaardwaarden.
Je kunt je configuratie zelfs modulair opbouwen en voor meer overzicht over meerdere .conf-bestanden verdelen. Journald leest die, ongeacht hun opslaglocatie, in alfabetische volgorde op basis van de naam van het .conf-bestand in en past ze toe.
Het doorgaans vooraf geïnstalleerde journald.conf (zie voorgaande) geeft je een overzicht van de beschikbare opties. Zo is er bijvoorbeeld de instelling SystemMaxUse, waarmee je ervoor kunt zorgen dat Journald niet te veel schijfruimte in beslag neemt. De Journald-database staat in de map /var/log/journal.
Met de standaardinstelling groeit het journal tot maximaal 10 procent van de grootte van de partitie waarop die map staat, met een maximum van 4 GB. Als de drempelwaarde wordt bereikt, verwijdert Journald de oudste logboekvermeldingen om ruimte te maken voor nieuwe. Voor veel toepassingen is dat voldoende. Maar als – zoals oude Linux-rotten graag doen – /var/log naar een aparte partitie is verplaatst om te voorkomen dat de rest van het systeem vastloopt bij overmatige logging, is het handig om die waarde te verhogen, zodat die partitie ook volledig wordt benut.
In dat geval is de optie SystemKeepFree handig, die het tegenovergestelde doel heeft en bepaalt hoeveel ruimte op de schijf altijd vrij moet blijven. Daarbij is 15 procent de standaardinstelling.
Als zowel SystemMaxUse als SystemKeepFree ingesteld zijn, wat normaal gesproken niet zinvol is, geldt altijd de laagste waarde. Gebruik het commando journalctl --disk-usage om te zien hoeveel ruimte er momenteel in beslag wordt genomen.
Nadat je de instellingen hebt gewijzigd, moet je Journald opnieuw laden met het commando systemctl reload systemd-journald, zodat de wijzigingen worden toegepast. Daarna is het aan te raden om met systemctl status systemd-journald even de status van de service te bekijken – zo zie je of er problemen zijn opgetreden bij het laden van je wijzigingen.
Met een commando als journalctl -b -u systemd-journald bekijk je de actuele meldingen van Journald zelf.
Handige commandline-opties voor journalctl
Logs opschonen met de stofzuiger
In de tijd vóór Journald was de Logrotate-service een belangrijk onderdeel van een Linux-systeem. Die hield de logbestanden in de gaten om ze te roteren zodra ze een bepaalde bestandsgrootte of een vooraf ingestelde leeftijd bereikten – ze dus bijvoorbeeld verplaatsen van dpkg.log naar dpkg.log.1 om actuele vermeldingen in een nieuw dpkg.log te schrijven, ze bij de volgende rotatie te comprimeren naar dpkg.log.2.gz en na verloop van tijd steeds verder naar achteren te schuiven.
Dat doet Journald standaard zelf in een proces dat het vacuuming noemt, oftewel stofzuigen. De logs worden opgeslagen in binaire bestanden met de extensie .journal in /var/log/journal. Als de opslaglimiet bereikt is, wordt het oudste bestand verwijderd.
Gebruik journalctl --header om een overzicht te krijgen van de bestaande bestanden die Journald intern gebruikt. Met --vacuum-size, --vacuum-time en --vacuum-files kun je oudere logs handmatig wegzuigen.
Om dat te automatiseren, kun je in journald.conf de grootte van de journal-bestanden beperken met de optie SystemMaxFileSize. Dan moet Journald wel vaker opruimen, maar worden er per bewerking minder logregels verwijderd.
Soms maken compliancevoorschriften het noodzakelijk om logs slechts een bepaalde tijd te bewaren. Ook daarvoor biedt Journald configuratieopties. De optie MaxRetentionSec bepaalt na welke tijd logs verwijderd moeten worden. Standaard is die functie uitgeschakeld.
Naast een puur aantal seconden kun je daar ook uitdrukkingen als 30 days en 6 months gebruiken. Met Compress=false kun je de compressie van de .journal-bestanden ook uitschakelen, maar dat helpt eigenlijk alleen op systemen met een heel zwakke processor.
Conclusie
Journald introduceert nieuwe concepten in vergelijking met klassieke logbestanden. En het loont de moeite om je daarin te verdiepen. Als je de werking eenmaal begrijpt, word je beloond met een nauwkeurige analysetool die het beheer van de logs comfortabel overneemt, manipulatie voorkomt en ook in moeilijke situaties overzicht biedt.
Marvin Shah en Marco den Teuling
Praat mee