Modul 6 · 6.2
Læs logs med journalctl
Modul 6: Tjenester og logs · Læsetid: 11 minutter
Læringsmål: Efter denne lektion kan du med journalctl søge målrettet i din servers logs (efter tjeneste, prioritet og tid), du ved, hvor andre logfiler ligger, og du forhindrer, at logs fylder din disk.
Centrale begreber: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioritet (err, warning, info), vedvarende lagring, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog
Loggen som første vidne
Når noget på din server ikke virker, står årsagen næsten altid i en log. Et website, der viser en fejlside, en tjeneste, der ikke starter, en backup, der ikke kørte i nat: serveren har skrevet det ned. En god administrator kigger først i loggen og ændrer først derefter på tingene.
På moderne Linux-servere samler journald (en del af systemd) meddelelserne fra kernen, fra systemd selv og fra alle tjenester i én log: journalen. Du læser den med journalctl.
For at kunne læse alt skal du være med i gruppen adm eller systemd-journal eller bruge sudo. Uden de rettigheder ser du kun dine egne meddelelser.
Hvor ligger den? Vedvarende eller flygtig
journald gemmer journalen ét af to steder:
- i
/var/log/journal/: vedvarende, loggene bevares efter en genstart; - i
/run/log/journal/: flygtig, i hukommelsen, væk efter en genstart.
Standardindstillingen (Storage=auto i /etc/systemd/journald.conf) vælger vedvarende, hvis mappen /var/log/journal/ findes. På Debian opretter systemd-pakken allerede den mappe siden Debian 11, og på Ubuntu findes den også. Kontrollér 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 kun én opstart, selv om serveren allerede har været genstartet, er dine logs flygtige. Opret mappen (sudo mkdir -p /var/log/journal og sudo systemd-tmpfiles --create --prefix /var/log/journal), og genstart journald. Det er vigtigt: efter et crash vil du netop gerne vide, hvad der skete før genstarten.
Siden Debian 12 installerer Debian ikke længere rsyslog som standard. Det program skrev tidligere tekstfiler som /var/log/syslog og /var/log/auth.log. På en ny Debian-server findes de altså ikke; alt ligger i journalen. Ubuntu har stadig rsyslog. Vejledninger, der siger "kig i /var/log/auth.log", kan du på Debian oversætte til journalctl -u ssh.
Søgning: de filtre, du faktisk bruger
Uden filter viser journalctl alt, fra det ældste. Det er sjældent det, du vil have. De vigtigste filtre, som du kan kombinere:
| Filter | Eksempel | Hvad |
|---|---|---|
-u <unit> | journalctl -u nginx | kun den tjeneste |
-p <prioriteit> | journalctl -p err | kun fejl og værre |
--since, --until | --since "2026-11-09 03:00" --until "04:00" | tidsrum; også today, yesterday, "1 hour ago" |
-b | journalctl -b, journalctl -b -1 | siden denne opstart eller den forrige |
-f | journalctl -u nginx -f | følg med live (som tail -f), stop med Ctrl+C |
-e | journalctl -u ssh -e | spring til slutningen |
-n | journalctl -u ssh -n 50 | de sidste 50 linjer |
-k | journalctl -k | kun meddelelser fra kernen |
--no-pager | uden bladring, praktisk sammen med grep |
Prioriteterne går fra 0 (emerg) til 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Med -p err får du err og alt, hvad der er mere alvorligt. -p warning viser også advarsler.
En typisk søgning. Dit website giver siden i morges en 502-fejl:
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'.Årsagen står der helt bogstaveligt: en tastefejl på linje 42 i en konfigurationsfil. Status 78 (CONFIG) bekræfter, at det drejer sig om en konfigurationsfejl. Du behøver ikke at gætte.
To tips, når du læser:
- Læs oppefra og ned, og find den første fejl. En fejl fører ofte til en hel række følgemeddelelser. Den første er som regel årsagen.
- Hold øje med tidspunktet. Hvad ændrede sig omkring det tidspunkt? En automatisk opdatering (lektion 4.2:
/var/log/unattended-upgrades/), en ændring, du selv lavede, en genstart?
Andre logfiler
Ikke alt ligger i journalen. Mange programmer skriver også (eller kun) egne filer i /var/log/:
| Fil eller mappe | Hvad |
|---|---|
/var/log/nginx/access.log og error.log | hver forespørgsel og hver fejl i nginx |
/var/log/apt/history.log | hvad apt installerede hvornår |
/var/log/unattended-upgrades/ | automatiske opdateringer (lektion 4.2) |
/var/log/fail2ban.log | blokeringer (lektion 5.3) |
/var/log/mysql/ eller journalen | MariaDB/MySQL, afhængigt af indstillingen |
Store tekstfiler læser du med less (søg med /), slutningen med tail -n 50, live med tail -f, og du filtrerer med grep:
anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5Logs fra Docker-containere ligger ikke i /var/log, men hos Docker selv: docker compose logs (lektion 9.3).
Logs må ikke fylde din disk
En fuld disk er en af de mest almindelige årsager til, at en server "pludselig" holder op med at virke: databaser stopper, opdateringer mislykkes, og nogle gange kan du ikke engang logge ind. Logs er ofte synderen.
Journalen begrænser sig selv. Som standard bruger den højst 10 % af filsystemet med et maksimum på 4 GB (SystemMaxUse=). Hvor meget den bruger nu, og hvordan du rydder op:
anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d # ældre end 30 dage væk
anna@web1:~$ sudo journalctl --vacuum-size=500M # op til 500 MBVil du have en fast grænse, så skriv i en drop-in /etc/systemd/journald.conf.d/grootte.conf:
[Journal]
SystemMaxUse=1Gog genstart journald med sudo systemctl restart systemd-journald.
Tekstfiler i /var/log vedligeholdes af logrotate: hver dag eller uge omdøbes en fil (error.log.1), ældre versioner pakkes (.gz), og de ældste slettes. Reglerne for hvert program står i /etc/logrotate.d/. Pakker fra distributionen har deres egen regel med. Skriver et eget program eller script til en egen logfil, så lav selv en regel, ellers vokser filen uendeligt.
Find ud af, hvad der fylder:
anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5Logs og privatliv
Logs indeholder IP-adresser, brugernavne og nogle gange mailadresser: det er personoplysninger. Gem dem ikke længere end nødvendigt (nogle uger til nogle måneder er almindeligt for en lille server), lad dem ikke ligge offentligt tilgængeligt (en mappe /logs i din webroot er en kendt fejl), og kopiér dem ikke bare til andres tjenester.
På AlmaLinux og Rocky Linux
journalctl virker på samme måde. Der er rsyslog stadig slået til som standard med filer som /var/log/messages og /var/log/secure (modstykket til auth.log). Meddelelser fra SELinux ligger i /var/log/audit/audit.log; ausearch -m avc -ts recent viser de seneste afvisninger.
Opsummering
- journald samler alle meddelelser i journalen; læs den med
journalctl, filtreret efter tjeneste (-u), prioritet (-p), tid (--since) og opstart (-b). - Kontrollér, at journalen er vedvarende (
/var/log/journalfindes), ellers mister du dine logs ved en genstart. - Debian 12 og nyere har som standard ingen rsyslog og derfor ingen
/var/log/auth.logog/var/log/syslog; alt ligger i journalen. - Find den første fejl, og se på, hvad der ændrede sig omkring det tidspunkt.
- Hold øje med størrelsen: journalen begrænser sig selv (
--disk-usage,--vacuum-*), tekstfiler håndteres af logrotate.
Quiz
Opgave
Opgave Z6.2: Analysér en tjeneste, der crasher. I eksempelfilen journal-crash-1.txt står output fra systemctl status og journalctl for en tjeneste, der starter igen og igen og derefter giver op. Besvar: hvad hedder tjenesten, hvor mange gange forsøgte systemd at starte den, med hvilken exitkode stoppede den, hvad er årsagen ifølge den første fejlmeddelelse, og hvornår gav systemd op? Programmet sammenligner med den faste nøgle. Se derefter på din egen server, om journalctl -p err -b viser fejl, og om din journal er vedvarende.
Læs mere
- 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, release notes 5.1.7 (rsyslog ikke længere som standard): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html
- Administrer tjenester med systemctl på din VPS
- VPS: fra første login til sikker server 8.4: Læs logs med journalctl og docker logs
