Modul 6 · 6.2
Läsa loggar med journalctl
Modul 6: Tjänster och loggar · Lästid: 11 minuter
Lärandemål: Efter den här lektionen kan du med journalctl söka riktat i serverns loggar (per tjänst, prioritet och tid), du vet var andra loggfiler finns, och du förhindrar att loggar fyller din disk.
Nyckelbegrepp: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioritet (err, warning, info), beständig lagring, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog
Loggen som första vittne
När något på din server inte fungerar står orsaken nästan alltid i en logg. En webbplats som visar en felsida, en tjänst som inte startar, en säkerhetskopia som inte kördes i natt: servern har skrivit ner det. En bra administratör tittar först i loggen och börjar först därefter ändra saker.
På moderna Linux-servrar samlar journald (en del av systemd) meddelanden från kärnan, från systemd själv och från alla tjänster i en enda logg: journalen. Du läser den med journalctl.
För att kunna läsa allt måste du vara med i gruppen adm eller systemd-journal, eller använda sudo. Utan de rättigheterna ser du bara dina egna meddelanden.
Var finns den? Beständig eller flyktig
journald sparar journalen på ett av två ställen:
- i
/var/log/journal/: beständig, loggarna finns kvar efter en omstart; - i
/run/log/journal/: flyktig, i minnet, borta efter en omstart.
Standardinställningen (Storage=auto i /etc/systemd/journald.conf) väljer beständig lagring om mappen /var/log/journal/ finns. På Debian skapar systemd-paketet den mappen redan sedan Debian 11, och på Ubuntu finns den också. Kontrollera det:
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 CETSer du bara ett enda uppstartstillfälle fast servern redan har startats om någon gång, då är dina loggar flyktiga. Skapa mappen (sudo mkdir -p /var/log/journal och sudo systemd-tmpfiles --create --prefix /var/log/journal) och starta om journald. Det är viktigt: efter en krasch vill du just veta vad som hände före omstarten.
Sedan Debian 12 installerar Debian inte längre rsyslog som standard. Det programmet skrev förr textfiler som /var/log/syslog och /var/log/auth.log. På en ny Debian-server finns de alltså inte; allt finns i journalen. Ubuntu har fortfarande rsyslog. Guider som säger "titta i /var/log/auth.log" kan du på Debian översätta till journalctl -u ssh.
Söka: filtren du verkligen använder
Utan filter visar journalctl allt, från det äldsta. Det är sällan vad du vill. De viktigaste filtren, som du kan kombinera:
| Filter | Exempel | Vad |
|---|---|---|
-u <unit> | journalctl -u nginx | bara den tjänsten |
-p <prioriteit> | journalctl -p err | bara fel och allvarligare |
--since, --until | --since "2026-11-09 03:00" --until "04:00" | tidsintervall; även today, yesterday, "1 hour ago" |
-b | journalctl -b, journalctl -b -1 | sedan den här uppstarten, eller den förra |
-f | journalctl -u nginx -f | följ live (som tail -f), avsluta med Ctrl+C |
-e | journalctl -u ssh -e | hoppa till slutet |
-n | journalctl -u ssh -n 50 | de senaste 50 raderna |
-k | journalctl -k | bara meddelanden från kärnan |
--no-pager | utan bläddring, praktiskt med grep |
Prioriteterna går från 0 (emerg) till 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Med -p err får du err och allt som är allvarligare. -p warning visar även varningar.
En typisk sökväg. Din webbplats ger sedan i morse ett 502-fel:
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'.Orsaken står där ordagrant: ett stavfel på rad 42 i en konfigurationsfil. Status 78 (CONFIG) bekräftar att det handlar om ett konfigurationsfel. Du behöver inte gissa något.
Två tips när du läser:
- Läs uppifrån och ned, och leta efter det första felet. Ett fel orsakar ofta en hel rad följdmeddelanden. Det första är oftast orsaken.
- Titta på tiden. Vad ändrades runt den tidpunkten? En automatisk uppdatering (lektion 4.2:
/var/log/unattended-upgrades/), en ändring du gjort, en omstart?
Andra loggfiler
Allt finns inte i journalen. Många program skriver också (eller bara) egna filer i /var/log/:
| Fil eller mapp | Vad |
|---|---|
/var/log/nginx/access.log och error.log | varje förfrågan och varje fel i nginx |
/var/log/apt/history.log | vad apt installerade och när |
/var/log/unattended-upgrades/ | automatiska uppdateringar (lektion 4.2) |
/var/log/fail2ban.log | blockeringar (lektion 5.3) |
/var/log/mysql/ eller journalen | MariaDB/MySQL, beroende på inställningen |
Stora textfiler läser du med less (sök med /), slutet med tail -n 50, live med tail -f och filtrerar med grep:
anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5Loggarna från Docker-containrar finns inte i /var/log utan hos Docker självt: docker compose logs (lektion 9.3).
Loggar får inte fylla din disk
En full disk är en av de vanligaste orsakerna till att en server "plötsligt" slutar fungera: databaser stannar, uppdateringar misslyckas, ibland kan du inte ens logga in. Loggar är ofta boven.
Journalen begränsar sig själv. Som standard använder den högst 10 % av filsystemet, med ett maximum på 4 GB (SystemMaxUse=). Så ser du hur mycket den använder nu och hur du rensar:
anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d # ta bort äldre än 30 dagar
anna@web1:~$ sudo journalctl --vacuum-size=500M # upp till 500 MBVill du ha en fast gräns, lägg då i en drop-in /etc/systemd/journald.conf.d/grootte.conf:
[Journal]
SystemMaxUse=1Goch starta om journald med sudo systemctl restart systemd-journald.
Textfiler i /var/log sköts av logrotate: varje dag eller vecka byter en fil namn (error.log.1), äldre versioner packas (.gz) och de äldsta tas bort. Reglerna per program finns i /etc/logrotate.d/. Paket från distributionen har med sig sin egen regel. Skriver ett eget program eller skript till en egen loggfil, skapa då en regel själv, annars växer filen i all oändlighet.
Hitta vad som tar plats:
anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5Loggar och integritet
Loggar innehåller IP-adresser, användarnamn och ibland e-postadresser: det är personuppgifter. Spara dem inte längre än nödvändigt (några veckor till några månader är vanligt för en liten server), låt dem inte ligga öppet (en mapp /logs i din webbrot är ett känt misstag) och kopiera dem inte hur som helst till andras tjänster.
På AlmaLinux och Rocky Linux
journalctl fungerar likadant. Där är rsyslog fortfarande påslaget som standard, med filer som /var/log/messages och /var/log/secure (motsvarigheten till auth.log). Meddelanden från SELinux finns i /var/log/audit/audit.log; ausearch -m avc -ts recent visar nyliga nekanden.
Sammanfattning
- journald samlar alla meddelanden i journalen; läs den med
journalctl, filtrerat på tjänst (-u), prioritet (-p), tid (--since) och uppstart (-b). - Kontrollera att journalen är beständig (
/var/log/journalfinns), annars förlorar du dina loggar vid en omstart. - Debian 12 och senare har som standard ingen rsyslog och därmed ingen
/var/log/auth.logoch/var/log/syslog; allt finns i journalen. - Leta efter det första felet och titta på vad som ändrades runt den tidpunkten.
- Håll koll på storleken: journalen begränsar sig själv (
--disk-usage,--vacuum-*), textfilerna sköts av logrotate.
Quiz
Uppgift
Uppgift Z6.2: Analysera en tjänst som kraschar. I exempelfilen journal-crash-1.txt finns utdata från systemctl status och journalctl för en tjänst som startar om gång på gång och sedan ger upp. Svara på: vad heter tjänsten, hur många gånger försökte systemd starta den, med vilken avslutningskod stoppade den, vad är orsaken enligt det första felmeddelandet, och vid vilken tid gav systemd upp? Programmet jämför med den fasta nyckeln. Titta sedan på din egen server om journalctl -p err -b visar fel, och om din journal är beständig.
Läs mer
- Manual
journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html - Manual
journald.conf(5)(Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html - Debian 12, versionsfakta 5.1.7 (rsyslog inte längre standard): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html
