Les logger med journalctl

Modul 6: Tjenester og logger · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du søke målrettet i loggene på serveren din med journalctl (etter tjeneste, prioritet og tid), du vet hvor andre loggfiler ligger, og du hindrer at logger fyller disken.

Nøkkelbegreper: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioritet (err, warning, info), varig lagring, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Loggen som første vitne

Når noe ikke virker på serveren din, står årsaken nesten alltid i en logg. Et nettsted som viser en feilside, en tjeneste som ikke starter, en sikkerhetskopi som ikke kjørte i natt: serveren har skrevet det ned. En god administrator ser først i loggen, og endrer ting først etterpå.

På moderne Linux-servere samler journald (en del av systemd) meldingene fra kjernen, fra systemd selv og fra alle tjenester i én logg: journalen. Du leser den med journalctl.

For å kunne lese alt må du være med i gruppen adm eller systemd-journal, eller bruke sudo. Uten disse rettighetene ser du bare dine egne meldinger.

Hvor ligger den? Varig eller flyktig

journald lagrer journalen på ett av to steder:

• i /var/log/journal/: varig, loggene blir tatt vare på etter en omstart;
• i /run/log/journal/: flyktig, i minnet, borte etter en omstart.

Standardinnstillingen (Storage=auto i /etc/systemd/journald.conf) velger varig lagring hvis mappen /var/log/journal/ finnes. På Debian lager systemd-pakken denne mappen allerede siden Debian 11, og på Ubuntu finnes den også. Kontroller 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 CET

Ser du bare ett oppstartstidspunkt selv om serveren har blitt startet på nytt, er loggene dine flyktige. Lag mappen (sudo mkdir -p /var/log/journal og sudo systemd-tmpfiles --create --prefix /var/log/journal) og start journald på nytt. Det er viktig: etter et krasj vil du nettopp vite hva som skjedde før omstarten.

Siden Debian 12 installerer ikke Debian rsyslog som standard lenger. Det programmet skrev tidligere tekstfiler som /var/log/syslog og /var/log/auth.log. På en ny Debian-server finnes de altså ikke; alt ligger i journalen. Ubuntu har fortsatt rsyslog. Veiledninger som sier "se i /var/log/auth.log" kan du på Debian oversette til journalctl -u ssh.

Søk: filtrene du faktisk bruker

Uten filter viser journalctl alt, fra det eldste. Det er sjelden det du vil. De viktigste filtrene, som du kan kombinere:

Prioritetene 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 som er mer alvorlig. -p warning viser også advarsler.

En typisk søkevei. Nettstedet ditt har gitt feil 502 siden i morges:

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'.

Årsaken står der bokstavelig: en skrivefeil på linje 42 i en konfigurasjonsfil. Status 78 (CONFIG) bekrefter at det er en konfigurasjonsfeil. Du trenger ikke gjette noe.

To tips når du leser:

• Les ovenfra og ned, og finn den første feilen. En feil gir ofte en hel rekke følgemeldinger. Den første er som regel årsaken.
• Se på tidspunktet. Hva endret seg rundt det tidspunktet? En automatisk oppdatering (leksjon 4.2: /var/log/unattended-upgrades/), en endring du gjorde, en omstart?

Andre loggfiler

Ikke alt ligger i journalen. Mange programmer skriver også (eller bare) egne filer i /var/log/:

Store tekstfiler leser du med less (søk med /), slutten med tail -n 50, live med tail -f, og filtrerer med grep:

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

Loggene til Docker-containere ligger ikke i /var/log, men hos Docker selv: docker compose logs (leksjon 9.3).

Logger skal ikke fylle disken

En full disk er en av de vanligste årsakene til at en server "plutselig" slutter å virke: databaser stopper, oppdateringer feiler, og noen ganger kan du ikke engang logge inn. Logger er ofte synderen.

Journalen begrenser seg selv. Som standard bruker den høyst 10 % av filsystemet, med et maksimum på 4 GB (SystemMaxUse=). Hvor mye den bruker nå, og hvordan du rydder:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # slett eldre enn 30 dager
anna@web1:~$ sudo journalctl --vacuum-size=500M    # opptil 500 MB

Vil du ha en fast grense, legg dette i en drop-in /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

og start journald på nytt med sudo systemctl restart systemd-journald.

Tekstfiler i /var/log holdes i orden av logrotate: hver dag eller uke får en fil nytt navn (error.log.1), eldre versjoner pakkes (.gz) og de eldste slettes. Reglene per program ligger i /etc/logrotate.d/. Pakker fra distribusjonen tar med sin egen regel. Skriver et eget program eller skript til en egen loggfil, må du lage en regel selv, ellers vokser filen uten stopp.

Finn ut hva som tar plass:

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

Logger og personvern

Logger inneholder IP-adresser, brukernavn og noen ganger e-postadresser: det er personopplysninger. Ikke ta vare på dem lenger enn nødvendig (noen uker til noen måneder er vanlig for en liten server), ikke la dem ligge åpent tilgjengelig (en mappe /logs i webroten er en kjent feil), og ikke kopier dem uten videre til andres tjenester.

På AlmaLinux og Rocky Linux

journalctl virker på samme måte. Der er rsyslog fortsatt slått på som standard, med filer som /var/log/messages og /var/log/secure (motstykket til auth.log). Meldinger fra SELinux ligger i /var/log/audit/audit.log; ausearch -m avc -ts recent viser nylige avvisninger.

Sammendrag

• journald samler alle meldinger i journalen; les den med journalctl, filtrert på tjeneste (-u), prioritet (-p), tid (--since) og oppstart (-b).
• Kontroller at journalen er varig (/var/log/journal finnes), ellers mister du loggene ved en omstart.
• Debian 12 og nyere har ikke rsyslog som standard, og dermed ingen /var/log/auth.log og /var/log/syslog; alt ligger i journalen.
• Finn den første feilen og se på hva som endret seg rundt det tidspunktet.
• Hold øye med størrelsen: journalen begrenser seg selv (--disk-usage, --vacuum-*), tekstfiler håndteres av logrotate.

Quiz

Oppgave

Oppgave Z6.2: Analyser en tjeneste som krasjer. Eksempelfilen journal-crash-1.txt inneholder utdataene fra systemctl status og journalctl for en tjeneste som starter på nytt igjen og igjen og så gir opp. Svar på: hva heter tjenesten, hvor mange ganger prøvde systemd å starte den, med hvilken avslutningskode stoppet den, hva er årsaken ifølge den første feilmeldingen, og når ga systemd opp? Programmet sammenligner med fasiten. Se deretter på din egen server om journalctl -p err -b viser feil, og om journalen din er varig.

Les mer

• Håndbok journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Håndbok journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, utgivelsesnotater 5.1.7 (rsyslog ikke lenger standard): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html