Logs lezen met journalctl

Module 6: Diensten en logs · Leestijd: 11 minuten

Leerdoel: Na deze les kun je met journalctl gericht zoeken in de logboeken van je server (per dienst, prioriteit en tijd), weet je waar andere logbestanden staan, en voorkom je dat logs je schijf vullen.

Kernbegrippen: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioriteit (err, warning, info), persistente opslag, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Het logboek als eerste getuige

Als iets op je server niet werkt, staat de reden bijna altijd in een logboek. Een website die een foutpagina geeft, een dienst die niet start, een back-up die vannacht niet liep: de server heeft het opgeschreven. Een goede beheerder kijkt eerst in het logboek, en gaat pas daarna dingen veranderen.

Op moderne Linux-servers verzamelt journald (onderdeel van systemd) de meldingen van de kernel, van systemd zelf en van alle diensten in één logboek: de journal. Je leest het met journalctl.

Om alles te kunnen lezen moet je in de groep adm of systemd-journal zitten, of sudo gebruiken. Zonder die rechten zie je alleen je eigen meldingen.

Waar staat het? Persistent of vluchtig

journald bewaart de journal op een van twee plekken:

• in /var/log/journal/: persistent, de logs blijven na een herstart bewaard;
• in /run/log/journal/: vluchtig, in het geheugen, weg na een herstart.

De standaardinstelling (Storage=auto in /etc/systemd/journald.conf) kiest persistent als de map /var/log/journal/ bestaat. Op Debian maakt het systemd-pakket die map al sinds Debian 11 aan, en op Ubuntu bestaat hij ook. Controleer het:

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Zie je maar één opstartmoment terwijl de server al eens herstart is, dan zijn je logs vluchtig. Maak de map aan (sudo mkdir -p /var/log/journal en sudo systemd-tmpfiles --create --prefix /var/log/journal) en herstart journald. Dat is belangrijk: na een crash wil je juist weten wat er vóór de herstart gebeurde.

Sinds Debian 12 installeert Debian rsyslog niet meer standaard. Dat programma schreef vroeger tekstbestanden als /var/log/syslog en /var/log/auth.log. Op een nieuwe Debian-server bestaan die dus niet; alles staat in de journal. Ubuntu heeft rsyslog nog wel. Handleidingen die zeggen "kijk in /var/log/auth.log" kun je op Debian vertalen naar journalctl -u ssh.

Zoeken: de filters die je echt gebruikt

Zonder filter laat journalctl alles zien, vanaf het oudste. Dat is zelden wat je wilt. De belangrijkste filters, die je kunt combineren:

De prioriteiten lopen van 0 (emerg) tot 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Met -p err krijg je err en alles wat ernstiger is. -p warning laat ook waarschuwingen zien.

Een typisch zoekpad. Je website geeft sinds vanochtend een fout 502:

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

De oorzaak staat er letterlijk: een tikfout op regel 42 van een configuratiebestand. De status 78 (CONFIG) bevestigt dat het om een configuratiefout gaat. Je hoeft niets te raden.

Twee tips bij het lezen:

• Lees van boven naar beneden, en zoek de eerste fout. Een fout veroorzaakt vaak een hele reeks vervolgmeldingen. De eerste is meestal de oorzaak.
• Let op de tijd. Wat veranderde er rond dat moment? Een automatische update (les 4.2: /var/log/unattended-upgrades/), een wijziging van jou, een herstart?

Andere logbestanden

Niet alles staat in de journal. Veel programma's schrijven ook (of alleen) eigen bestanden in /var/log/:

Grote tekstbestanden lees je met less (zoeken met /), het einde met tail -n 50, live met tail -f, en filteren met grep:

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

De logs van Docker-containers staan niet in /var/log maar bij Docker zelf: docker compose logs (les 9.3).

Logs mogen je schijf niet vullen

Een volle schijf is een van de meest voorkomende oorzaken van een server die "ineens" niet meer werkt: databases stoppen, updates mislukken, je kunt soms zelfs niet meer inloggen. Logs zijn vaak de schuldige.

De journal begrenst zichzelf. Standaard gebruikt hij hoogstens 10% van het bestandssysteem, met een maximum van 4 GB (SystemMaxUse=). Hoeveel hij nu gebruikt en hoe je opruimt:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # ouder dan 30 dagen weg
anna@web1:~$ sudo journalctl --vacuum-size=500M    # tot 500 MB

Wil je een vaste grens, zet dan in een drop-in /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

en herstart journald met sudo systemctl restart systemd-journald.

Tekstbestanden in /var/log worden bijgehouden door logrotate: elke dag of week wordt een bestand hernoemd (error.log.1), oudere versies worden ingepakt (.gz) en de oudste weggegooid. De regels per programma staan in /etc/logrotate.d/. Pakketten uit de distributie brengen hun eigen regel mee. Schrijft een eigen programma of script naar een eigen logbestand, maak dan zelf een regel, anders groeit het bestand eindeloos.

Zoeken wat ruimte inneemt:

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Logs en privacy

Logboeken bevatten IP-adressen, gebruikersnamen en soms mailadressen: dat zijn persoonsgegevens. Bewaar ze niet langer dan nodig (een paar weken tot een paar maanden is gangbaar voor een kleine server), laat ze niet openbaar staan (een map /logs in je webroot is een bekende fout) en kopieer ze niet zomaar naar diensten van anderen.

Op AlmaLinux en Rocky Linux

journalctl werkt hetzelfde. Daar staat rsyslog nog wel standaard aan, met bestanden als /var/log/messages en /var/log/secure (de tegenhanger van auth.log). Meldingen van SELinux staan in /var/log/audit/audit.log; ausearch -m avc -ts recent toont recente weigeringen.

Samenvatting

• journald verzamelt alle meldingen in de journal; lees die met journalctl, gefilterd op dienst (-u), prioriteit (-p), tijd (--since) en opstart (-b).
• Controleer dat de journal persistent is (/var/log/journal bestaat), anders ben je je logs kwijt na een herstart.
• Debian 12 en later hebben standaard geen rsyslog en dus geen /var/log/auth.log en /var/log/syslog; alles staat in de journal.
• Zoek de eerste fout en kijk naar wat er rond dat moment veranderde.
• Houd de omvang in de gaten: de journal begrenst zichzelf (--disk-usage, --vacuum-*), tekstbestanden regelt logrotate.

Quiz

Opdracht

Opdracht Z6.2: Een crashende dienst ontleden. In het voorbeeldbestand journal-crash-1.txt staat de uitvoer van systemctl status en journalctl van een dienst die steeds opnieuw start en dan opgeeft. Beantwoord: hoe heet de dienst, hoe vaak probeerde systemd hem te starten, met welke afsluitcode stopte hij, wat is de oorzaak volgens de eerste foutmelding, en hoe laat gaf systemd het op? Het programma vergelijkt met de vaste sleutel. Kijk daarna op je eigen server of journalctl -p err -b fouten toont, en of je journal persistent is.

Verder lezen

• Handleiding journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Handleiding journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, releasenotes 5.1.7 (rsyslog niet meer standaard): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html