Branje dnevnikov z journalctl

Modul 6: Storitve in dnevniki · Čas branja: 11 minut

Učni cilj: Po tej lekciji boste z journalctl znali ciljno iskati po dnevnikih Vašega strežnika (po storitvi, prioriteti in času), vedeli boste, kje so druge dnevniške datoteke, in preprečili boste, da bi dnevniki zapolnili Vaš disk.

Ključni pojmi: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioriteta (err, warning, info), trajna hramba, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Dnevnik kot prva priča

Če na Vašem strežniku nekaj ne deluje, je razlog skoraj vedno zapisan v dnevniku. Spletno mesto, ki prikaže stran z napako, storitev, ki se ne zažene, varnostna kopija, ki se ponoči ni izvedla: strežnik je to zapisal. Dober skrbnik najprej pogleda v dnevnik in šele nato začne kaj spreminjati.

Na sodobnih strežnikih Linux journald (del sistema systemd) zbira sporočila jedra, samega systemd in vseh storitev v en dnevnik: journal. Berete ga z ukazom journalctl.

Da lahko preberete vse, morate biti v skupini adm ali systemd-journal ali pa uporabiti sudo. Brez teh pravic vidite samo svoja sporočila.

Kje je shranjen? Trajno ali začasno

journald hrani journal na enem od dveh mest:

• v /var/log/journal/: trajno, dnevniki ostanejo shranjeni tudi po ponovnem zagonu;
• v /run/log/journal/: začasno, v pomnilniku, po ponovnem zagonu jih ni več.

Privzeta nastavitev (Storage=auto v /etc/systemd/journald.conf) izbere trajno hrambo, če mapa /var/log/journal/ obstaja. Na Debianu to mapo že od Debiana 11 ustvari paket systemd, na Ubuntuju prav tako obstaja. Preverite:

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

Če vidite le en zagon, čeprav je bil strežnik že kdaj ponovno zagnan, so Vaši dnevniki začasni. Ustvarite mapo (sudo mkdir -p /var/log/journal in sudo systemd-tmpfiles --create --prefix /var/log/journal) in ponovno zaženite journald. To je pomembno: po sesutju želite vedeti prav to, kaj se je zgodilo pred ponovnim zagonom.

Od Debiana 12 Debian rsyslog ne namešča več privzeto. Ta program je nekoč pisal besedilne datoteke, kot sta /var/log/syslog in /var/log/auth.log. Na novem strežniku Debian ju torej ni; vse je v journalu. Ubuntu rsyslog še ima. Navodila, ki pravijo "poglejte v /var/log/auth.log", lahko na Debianu prevedete v journalctl -u ssh.

Iskanje: filtri, ki jih boste res uporabljali

Brez filtra journalctl prikaže vse, od najstarejšega naprej. To je redko tisto, kar želite. Najpomembnejši filtri, ki jih lahko kombinirate:

Prioritete gredo od 0 (emerg) do 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Z -p err dobite err in vse, kar je hujše. -p warning prikaže tudi opozorila.

Tipičen potek iskanja. Vaše spletno mesto od jutra vrača napako 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'.

Vzrok je zapisan dobesedno: tipkarska napaka v vrstici 42 konfiguracijske datoteke. Status 78 (CONFIG) potrjuje, da gre za napako v konfiguraciji. Ničesar Vam ni treba ugibati.

Dva nasveta za branje:

• Berite od zgoraj navzdol in poiščite prvo napako. Ena napaka pogosto povzroči cel niz posledičnih sporočil. Prvo je običajno vzrok.
• Bodite pozorni na čas. Kaj se je spremenilo okoli tega trenutka? Samodejna posodobitev (lekcija 4.2: /var/log/unattended-upgrades/), Vaša sprememba, ponovni zagon?

Druge dnevniške datoteke

Ni vse v journalu. Veliko programov piše tudi (ali samo) svoje datoteke v /var/log/:

Velike besedilne datoteke berete z less (iskanje z /), konec z tail -n 50, v živo z tail -f, filtrirate pa z grep:

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

Dnevniki vsebnikov Docker niso v /var/log, temveč pri samem Dockerju: docker compose logs (lekcija 9.3).

Dnevniki ne smejo zapolniti Vašega diska

Poln disk je eden najpogostejših vzrokov, da strežnik "kar naenkrat" ne deluje več: podatkovne baze se ustavijo, posodobitve ne uspejo, včasih se niti prijaviti ne morete več. Krivci so pogosto dnevniki.

Journal se omejuje sam. Privzeto porabi največ 10 % datotečnega sistema, z zgornjo mejo 4 GB (SystemMaxUse=). Koliko prostora zdaj porablja in kako ga počistite:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # odstranjeno, kar je starejše od 30 dni
anna@web1:~$ sudo journalctl --vacuum-size=500M    # do 500 MB

Če želite fiksno mejo, jo nastavite v dodatni datoteki (drop-in) /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

in ponovno zaženite journald z sudo systemctl restart systemd-journald.

Besedilne datoteke v /var/log vzdržuje logrotate: vsak dan ali teden se datoteka preimenuje (error.log.1), starejše različice se stisnejo (.gz), najstarejše pa se izbrišejo. Pravila za posamezne programe so v /etc/logrotate.d/. Paketi iz distribucije prinesejo svoje pravilo. Če Vaš lasten program ali skript piše v svojo dnevniško datoteko, sami ustvarite pravilo, sicer bo datoteka rasla brez konca.

Iskanje tega, kar zaseda prostor:

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

Dnevniki in zasebnost

Dnevniki vsebujejo naslove IP, uporabniška imena in včasih e-poštne naslove: to so osebni podatki. Ne hranite jih dlje, kot je potrebno (za majhen strežnik je običajno nekaj tednov do nekaj mesecev), ne puščajte jih javno dostopnih (mapa /logs v korenski mapi spletnega mesta je znana napaka) in jih ne kopirajte kar tako v storitve drugih ponudnikov.

Na AlmaLinux in Rocky Linux

journalctl deluje enako. Tam je rsyslog še privzeto vklopljen, z datotekami, kot sta /var/log/messages in /var/log/secure (ustreznica auth.log). Sporočila SELinux so v /var/log/audit/audit.log; ausearch -m avc -ts recent prikaže nedavne zavrnitve.

Povzetek

• journald zbira vsa sporočila v journal; berete ga z journalctl, filtriranega po storitvi (-u), prioriteti (-p), času (--since) in zagonu (-b).
• Preverite, da je journal trajen (/var/log/journal obstaja), sicer po ponovnem zagonu izgubite svoje dnevnike.
• Debian 12 in novejši privzeto nimajo rsysloga in zato ne /var/log/auth.log in /var/log/syslog; vse je v journalu.
• Poiščite prvo napako in poglejte, kaj se je spremenilo okoli tega trenutka.
• Spremljajte velikost: journal se omejuje sam (--disk-usage, --vacuum-*), za besedilne datoteke poskrbi logrotate.

Kviz

Naloga

Naloga Z6.2: Analiza storitve, ki se sesuva. V vzorčni datoteki journal-crash-1.txt je izpis ukazov systemctl status in journalctl za storitev, ki se vedno znova zaganja in nato obupa. Odgovorite: kako se storitev imenuje, kolikokrat jo je systemd poskušal zagnati, s katero izhodno kodo se je ustavila, kaj je vzrok glede na prvo sporočilo o napaki in ob kateri uri je systemd obupal? Program odgovore primerja s fiksnim ključem. Nato na svojem strežniku preverite, ali journalctl -p err -b prikaže napake in ali je Vaš journal trajen.

Za nadaljnje branje

• Priročnik journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Priročnik journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, opombe ob izdaji 5.1.7 (rsyslog ni več privzet): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html
• Upravljanje storitev s systemctl na Vašem VPS
• VPS: od prve prijave do varnega strežnika 8.4: Branje dnevnikov z journalctl in docker logs