journalctl-cheatsheet: Linux-logs tailen, filteren en volgen

journalctl in één zin: journalctl -u <service> -f volgt de live log van een service, journalctl -u <service> -n 100 toont de laatste 100 regels, en journalctl --since "1 hour ago" toont alles van recent. Daarmee dek je 90% van de momenten waarop je je afvraagt waarom een service uit ligt. De rest van deze cheatsheet is de copy-paste-set die je het man-page-lezen om 2 uur ‘s nachts bespaart — filteren op unit, tijd, prioriteit en boot, plus de opruimcommando’s die voorkomen dat het journal je schijf opeet. Elk commando hieronder draait ongewijzigd op elke systemd-distro (Ubuntu, Debian, Fedora, Arch).

Wat is journalctl en waarom niet gewoon /var/log/syslog lezen?

Klassieke Linux-logging schreef platte tekstbestanden onder /var/log — syslog, auth.log, messages. systemd verving dat door het journal: een binaire, geïndexeerde log beheerd door systemd-journald. Gewone grep kan het niet lezen; journalctl is de enige voordeur, en in ruil daarvoor krijg je filteren op service, tijd, boot en ernst zonder regex-acrobatiek.

Het mentale model is simpel: het journal slaat alles op, en journalctl is de query-tool. Een service heeft geen eigen logbestand nodig — alles wat het naar stdout/stderr schrijft terwijl het onder systemd draait, belandt automatisch in het journal. Daarom werkt journalctl -u nginx ook als je geen idee hebt waar nginx zijn error-log heeft geconfigureerd.

Eén kanttekening: bij sommige minimale installaties is het journal vluchtig (opgeslagen in /run, gewist bij reboot) omdat /var/log/journal niet bestaat. Los het één keer op:

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

Hoe zie ik de laatste 100 regels van een log?

-n beperkt de output tot de nieuwste N regels (standaard 10):

journalctl -n 100                      # last 100 lines of everything
journalctl -u nginx -n 100             # last 100 lines from one unit
journalctl -n 100 --no-pager           # print and exit — perfect for piping

--no-pager is belangrijker dan het lijkt: zonder opent journalctl less en blijft je script, pipe of ssh-eenregelaar hangen op een toetsaanslag. Elk commando dat je verder doorsluist moet hem meekrijgen.

Hoe volg ik logs live, zoals tail -f?

De flag -f is de tail -f van journalctl — hij streamt nieuwe regels zodra ze binnenkomen:

journalctl -f                    # everything, live
journalctl -u sshd -f            # just the SSH daemon, live
journalctl -u ollama -f -n 50    # live, but start with the last 50 lines

Dit is het commando om in een tweede terminal te draaien terwijl je in de eerste een service herstart: systemctl restart nginx in het ene paneel, journalctl -u nginx -f in het andere, en de oorzaak van de crash meldt zich meestal binnen enkele seconden. Ik draai exact deze loop in mijn homelab elke keer dat een container of service zich misdraagt.

Hoe toon ik logs van een specifieke service?

-u filtert op systemd-unit:

journalctl -u nginx                    # one unit, all history
journalctl -u nginx -u redis           # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # the exact-match alternative

Units kunnen helper-units spawnen die de interessante output vasthouden — een falende web-app logt de echte error soms onder een andere unit. Toont -u <service> niets terwijl de service duidelijk draait, zoek dan eerst de echte unitnaam:

systemctl list-units --type=service | grep -i <guess>

Hetzelfde -u-patroon werkt voor timers (systemctl list-timers toont namen) en userservices — voeg voor alles wat onder systemd --user draait --user toe:

journalctl --user -u pipewire -n 50

Hoe filter ik logs op tijd?

--since en --until nemen timestamps, maar accepteren ook vergevingsgezinde relatieve formuleringen:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Combineer een tijdsvenster met een unit en je hebt incidenttriage in één regel: “wat logde de API tussen 09:00 en het moment dat hij neerviel?” Dat is voor één doos sneller dan welke logaggregator dan ook.

Hoe toon ik alleen errors (of warnings)?

-p filtert op prioriteit, met de syslog-zwaartenamen:

journalctl -p err -b              # errors only, since this boot
journalctl -p warning..alert -u nginx   # a range of severities

Prioriteiten, aflopend: emerg, alert, crit, err, warning, notice, info, debug. Als een doos “raar doet”, is journalctl -p err -b --since today de snelste sanity-check — hij antwoordt op de vraag of er daadwerkelijk iets faalt, zonder ruis van routine-info-regels.

Hoe zie ik logs van de vorige boot?

Services die bij het opstarten crashen schrijven logregels vóór je huidige boot, en journalctl toont stilzwijgend alleen de huidige. -b selecteert boots:

journalctl -b                 # current boot only
journalctl -b -1              # previous boot
journalctl -b -1 -u sshd      # why SSH died last time
journalctl --list-boots       # index of stored boots

Dit is de meest nuttige flag voor het geval “het was kapot, ik heb gereboot en nu zie ik de error niet meer” — de error staat er nog, één boot terug.

Snel naslaan: de flags om te onthouden

Doel	Commando
Eén service live volgen	journalctl -u <svc> -f
Laatste 100 regels	journalctl -n 100
Sinds een uur geleden	journalctl --since "1 hour ago"
Errors deze boot	journalctl -p err -b
Vorige boot	journalctl -b -1
Schijfgebruik van het journal	journalctl --disk-usage
Machineleesbare output	journalctl -o json-pretty
Alleen kernelmeldingen	journalctl -k

Hoe voorkom ik dat het journal mijn schijf vult?

Kijk wat het kost, en stel een limiet in:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # keep newest 500 MB
sudo journalctl --vacuum-time=30d      # keep newest 30 days

Om de limiet permanent te maken, zet je SystemMaxUse=500M onder de sectie [Journal] in /etc/systemd/journald.conf, gevolgd door sudo systemctl restart systemd-journald. Met de groottelimiet en het bootfilter hierboven blijft het journal een tool en geen langzaam lek in je schijf.

journalctl vs dmesg vs /var/log — waar kijk je eerst?

• journalctl — applicatie- en servicegedrag. Alles wat systemd beheert staat hier, geïndexeerd en filterbaar. Standaard eerste stop.
• journalctl -k / dmesg — kernel en hardware: OOM-kills, USB-resets, schijffouten. Stierf een proces mysterieus, kijk hier naar de OOM-killer voordat je de app de schuld geeft.
• /var/log/<app>/ — alleen voor apps die hun eigen bestandslogging doen (nginx access-logs, PostgreSQL). Zelfs dan belanden opstartfouten meestal alsnog in het journal.

Dezelfde workflow geldt voor lokale AI-diensten — loopt een ollama serve-unit vast, dan laat journalctl -u ollama -n 100 direct de fout bij het laden van het model zien, zoals behandeld in de Ollama vs LM Studio-vergelijking.

Dat is de hele cheatsheet: -u voor unit, -f om te volgen, -n voor regels, --since voor tijd, -p voor ernst, -b voor boots. Zes flags dekken vrijwel elke logvraag die een Linux-doos je stelt.