Gå direkte til indholdet

Cookieindstillinger

Vælg for hver type, hvilke cookies du tillader. Du kan altid ændre dit valg via Cookieindstillinger nederst på hver side. Privatlivspolitik

Nødvendige

Altid slået til

Nødvendige for at logge ind, gemme din kurv og huske dine valg. De er altid slået til.

Hvilke cookies?
  • weboke_sessie, weboke_klant, weboke_remember: din session og at forblive logget ind
  • weboke_basket: din kurv
  • wkBtwIncl: vise priser med eller uden moms
  • wok_cookies: dit cookievalg, 12 måneder

Måler, hvilken annonce der fører til et besøg eller en bestilling, så vi ikke betaler for annoncer, der ikke virker.

Hvilke cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), op til 90 dage
  • OpenAI Ads, annoncer i ChatGPT
  • wok_aff: hvilken partner der henviste dig til os (affiliateprogram), 60 dage

4,6

Land og sprog

Hvert land har sin egen side med landets priser og moms.

Se

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 CET

Ser 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:

FilterEksempelHvad
-u <unit>journalctl -u nginxkun den tjeneste
-p <prioriteit>journalctl -p errkun fejl og værre
--since, --until--since "2026-11-09 03:00" --until "04:00"tidsrum; også today, yesterday, "1 hour ago"
-bjournalctl -b, journalctl -b -1siden denne opstart eller den forrige
-fjournalctl -u nginx -ffølg med live (som tail -f), stop med Ctrl+C
-ejournalctl -u ssh -espring til slutningen
-njournalctl -u ssh -n 50de sidste 50 linjer
-kjournalctl -kkun meddelelser fra kernen
--no-pageruden 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 mappeHvad
/var/log/nginx/access.log og error.loghver forespørgsel og hver fejl i nginx
/var/log/apt/history.loghvad apt installerede hvornår
/var/log/unattended-upgrades/automatiske opdateringer (lektion 4.2)
/var/log/fail2ban.logblokeringer (lektion 5.3)
/var/log/mysql/ eller journalenMariaDB/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 5

Logs 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 MB

Vil du have en fast grænse, så skriv i en drop-in /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

og 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 5

Logs 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/journal findes), ellers mister du dine logs ved en genstart.
  • Debian 12 og nyere har som standard ingen rsyslog og derfor ingen /var/log/auth.log og /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

1. Hvilken kommando viser kun dagens fejl fra nginx?



2. Din server blev genstartet i nat efter et crash. journalctl -b -1 giver "Specifying boot ID or boot offset has no effect, no persistent journal was found". Hvad betyder det?



3. En vejledning siger, at du finder mislykkede SSH-logins i /var/log/auth.log, men på din nye Debian 13-server findes den fil ikke. Hvor kigger du?



4. I en log står der tyve fejlmeddelelser efter hinanden. Hvor begynder du?



5. Din disk er fuld, og journalctl --disk-usage siger 400 MB. Hvad er det bedste næste skridt?



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.

Opgave Z6.2: Analysér en tjeneste, der crasher

Fil til denne opgave: journal-crash-1.txt







Det, du udfylder, og hvad vi finder, gemmer vi ikke. Din browser husker dine svar, og om du har bestået opgaven. Er du logget ind, gemmer vi kun, at du (næsten) bestod opgaven, i Mine kurser; der kan du også slette det.

Læs mere

Et øjeblik…

Opsæt dine domæner

Angiv for hvert domæne navneserverne, tilknytningen til din hosting, og hvem der bliver ejer.

Indlæser dine domæner…