Linux Logbestanden Lezen: Zo Vind je de Oorzaak met journalctl en /var/log

Wat is journalctl en waarom gebruik je het?

journalctl is het commando waarmee je de journal van systemd uitleest. Die journal verzamelt de meldingen van de kernel, van services en van je boot-proces op één plek. Je hoeft dus niet meer te raden in welk bestand een programma zijn fouten schrijft.

Het grote voordeel: je kunt logs filteren op dienst, tijdstip en ernst. Bij een storing zoek je zo in seconden naar de ene regel die ertoe doet, in plaats van door duizenden regels te scrollen. Vrijwel elke moderne distributie gebruikt systemd, waaronder Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux en openSUSE.

Let op dat je voor het volledige overzicht vaak sudo nodig hebt. Als gewone gebruiker zie je alleen je eigen logs, tenzij je lid bent van de groep systemd-journal, adm of wheel (afhankelijk van de distributie).

Linux logs bekijken: de basiscommando's

Typ je alleen journalctl, dan krijg je alle logs van oud naar nieuw in een pager. Dat is zelden wat je wilt. Deze varianten gebruik je het vaakst:

Met journalctl --list-boots zie je welke eerdere boots beschikbaar zijn. Dat werkt alleen als de journal persistent is ingesteld, zie hieronder.

Systemd logs filteren op dienst, tijd en ernst

Filteren is waar journalctl echt sterk in is. Je kunt de filters ook combineren.

Per dienst: journalctl -u

journalctl -u nginx
journalctl -u ssh --since today
journalctl -u mariadb -n 100 --no-pager

De naam van de unit vind je met systemctl list-units --type=service. Let op: SSH heet ssh op Debian en Ubuntu, maar sshd op RHEL-varianten.

Op tijd: --since en --until

journalctl --since "1 hour ago"
journalctl --since yesterday --until today
journalctl --since "2026-11-03 14:00" --until "2026-11-03 14:30"

Weet je ongeveer wanneer het misging? Kijk dan een paar minuten voor dat moment. De oorzaak staat meestal vóór het symptoom.

Op ernst: -p

Elke logregel heeft een prioriteit van 0 (emerg) tot 7 (debug). Met -p toon je die prioriteit en alles wat ernstiger is:

journalctl -p err
journalctl -p warning -b
journalctl -u nginx -p err --since today

-p err is een goed startpunt: je ziet alleen fouten en erger, zonder de ruis van gewone informatieve meldingen.

Zoeken in de tekst: -g

journalctl -g "out of memory" -b
journalctl -u postfix -g "timeout"

Wat doet journalctl -xe?

Je kent het misschien van een foutmelding bij het starten van een dienst: "See 'journalctl -xe' for details." Dat commando bestaat uit twee opties:

• -e (end): springt naar het einde van de logs, waar de nieuwste regels staan.
• -x (catalog): voegt een uitleg toe bij meldingen waarvoor systemd een helptekst in zijn catalogus heeft.

Zo zie je meteen wat er zojuist misging, vaak met een korte toelichting over de mogelijke oorzaak. Een nog gerichter alternatief is:

journalctl -xeu nginx

Dat toont de laatste meldingen van alleen die unit, inclusief uitleg. Combineer het met systemctl status nginx: die toont de status en de laatste logregels van de dienst.

Live meekijken: journalctl -f en tail -f

Wil je zien wat er gebeurt terwijl je iets uitprobeert, zoals een dienst herstarten? Volg dan de logs live:

journalctl -f
journalctl -fu nginx
tail -f /var/log/nginx/error.log

Open dit in een tweede terminalvenster en voer in het eerste de actie uit die de fout veroorzaakt. Stoppen doe je met Ctrl+C.

Waar staan de logbestanden van een Linux-server?

Naast de journal bewaren veel programma's hun eigen tekstlogs. Die staan bijna altijd in /var/log. De bestandsnamen verschillen per distributie:

Let op: nieuwere installaties, zoals Debian 12, hebben standaard geen rsyslog meer. Dan bestaan syslog en auth.log niet en zit alles in de journal. Vind je een bestand dus niet, dan is er geen fout: gebruik journalctl of installeer rsyslog.

/var/log/syslog en andere tekstlogs lezen

Tekstbestanden lees je met de standaardgereedschappen van Linux. Dit zijn de handigste:

sudo less /var/log/syslog          # bladeren, zoeken met / , afsluiten met q
sudo tail -n 100 /var/log/syslog   # laatste 100 regels
sudo tail -f /var/log/syslog       # live meelezen
sudo grep -i "error" /var/log/syslog
sudo grep -i "failed" /var/log/auth.log | tail -n 20
sudo less +F /var/log/syslog       # volgen, met Ctrl+C terug naar bladeren

Oudere logs worden door logrotate gecomprimeerd tot bestanden als syslog.2.gz. Die lees je zonder uitpakken met zgrep of zless:

sudo zgrep -i "error" /var/log/syslog.*.gz

Kijk ook naar kernelmeldingen met sudo dmesg -T --level=err,warn. De optie -T toont leesbare tijdstempels. Dat is nuttig bij hardware-, schijf- en geheugenproblemen.

Linux foutmeldingen opzoeken en begrijpen

Logs lezen is één ding, de betekenis begrijpen een ander. Met deze aanpak kom je meestal een heel eind:

1. Bepaal het tijdstip. Wanneer begon het probleem? Filter met --since en --until rond dat moment.
2. Zoek de eerste fout, niet de laatste. Een fout veroorzaakt vaak een kettingreactie. De bovenste melding in die reeks is meestal de oorzaak.
3. Lees de regels eromheen. Context vertelt vaak meer dan de foutmelding zelf, zoals een configuratie die net is gewijzigd of een schijf die vol raakte.
4. Zoek op de exacte tekst. Kopieer de kern van de melding, zonder tijdstempel, hostnaam en proces-ID, en zoek die op in je zoekmachine of in de documentatie van het programma.
5. Controleer de basis. Is de schijf vol (df -h), het geheugen op (free -h) of is de systeemtijd fout (timedatectl)? Veel mysterieuze fouten komen hierdoor.

Een logregel heeft altijd dezelfde opbouw: tijdstip, hostnaam, programma met proces-ID en dan de melding. Woorden als permission denied, no space left on device, connection refused en address already in use wijzen vaak direct naar de oorzaak. Wil je daarna systematisch verder, volg dan ons stappenplan om Linux te troubleshooten.

Praktijkvoorbeelden: drie veelvoorkomende situaties

1. Een dienst start niet

systemctl status nginx
journalctl -xeu nginx --no-pager | tail -n 40

Zoek naar meldingen over een syntaxisfout in de configuratie of een poort die al in gebruik is. Start de server als geheel niet meer op? Bekijk dan oorzaken en oplossingen als je Linux-server niet meer opstart.

2. Een proces is plotseling verdwenen

journalctl -k -b | grep -i -E "out of memory|oom|killed process"

Vind je hier regels, dan heeft de kernel een proces beëindigd omdat het geheugen op was. Dat past bij een traag systeem, waarbij onze handleiding over een trage Linux-server je verder helpt.

3. Verdachte inlogpogingen

journalctl -u ssh --since yesterday | grep -i "failed password"
sudo grep "Accepted" /var/log/auth.log | tail -n 20
last -n 20

Veel mislukte pogingen van losse IP-adressen zijn normaal internetgeluid. Een geslaagde login vanaf een onbekend adres is dat niet. Lees in dat geval direct wat je moet doen als je Linux-server is gehackt.

De journal beheren: bewaartijd en schijfruimte

Een veelgemaakte valkuil: als de map /var/log/journal niet bestaat, bewaart journald de logs alleen in het geheugen. Na een herstart zijn ze weg, en dus ook het bewijs van wat er misging. Zo maak je de journal persistent:

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

Of stel in /etc/systemd/journald.conf de regel Storage=persistent in. Controleer en beperk het gebruik van schijfruimte zo:

journalctl --disk-usage
sudo journalctl --vacuum-time=2weeks
sudo journalctl --vacuum-size=500M

Wil je logs langer bewaren dan een paar weken, bijvoorbeeld voor audits? Stuur ze dan naar een aparte logserver, zodat ze niet verdwijnen als de server zelf wordt aangetast.

Wanneer haal je een expert erbij?

Zelf logs lezen lost veel op. Maar sommige signalen vragen om een specialist, omdat doorgaan met proberen de schade kan vergroten:

• Schijffouten zoals I/O error, EXT4-fs error of een bestandssysteem dat read-only wordt. Blijf niet herstarten, want je risico op dataverlies stijgt.
• Tekenen van een inbraak, zoals onbekende gebruikers, vreemde processen of logs die gewist zijn.
• Kernel panics of herhaalde crashes zonder duidelijke oorzaak.
• Productiesystemen met downtime, waar elke minuut geld kost en een fout herstel duur is.
• Logs die je niet kunt duiden na het doorlopen van de stappen hierboven.

Twijfel je of het de moeite waard is? In ons artikel over Linux hulp inhuren lees je wanneer betaalde support loont en wat het kost. Bij een acuut probleem kun je meteen terecht bij onze spoedhulp bij incidenten.