Čtení logů pomocí journalctl

Modul 6: Služby a logy · Doba čtení: 11 min.

Cíl lekce: Po této lekci budete umět pomocí journalctl cíleně hledat v logech svého serveru (podle služby, priority a času), budete vědět, kde najdete další logovací soubory, a zabráníte tomu, aby logy zaplnily Váš disk.

Klíčové pojmy: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, priorita (err, warning, info), trvalé ukládání, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Log jako první svědek

Když na Vašem serveru něco nefunguje, důvod je téměř vždy zapsaný v logu. Web, který zobrazuje chybovou stránku, služba, která se nespustí, záloha, která v noci neproběhla: server si to zapsal. Dobrý správce se nejdřív podívá do logu a teprve potom začne něco měnit.

Na moderních linuxových serverech shromažďuje journald (součást systemd) zprávy jádra, samotného systemd i všech služeb do jednoho logu: do journalu. Čtete ho pomocí journalctl.

Abyste mohli číst vše, musíte být ve skupině adm nebo systemd-journal, případně použít sudo. Bez těchto oprávnění uvidíte jen své vlastní zprávy.

Kde je uložen? Trvale, nebo dočasně

journald ukládá journal na jedno ze dvou míst:

• do /var/log/journal/: trvale, logy zůstanou zachovány i po restartu;
• do /run/log/journal/: dočasně, v paměti, po restartu zmizí.

Výchozí nastavení (Storage=auto v /etc/systemd/journald.conf) zvolí trvalé ukládání, pokud adresář /var/log/journal/ existuje. Na Debianu tento adresář vytváří balíček systemd už od Debianu 11 a na Ubuntu existuje také. Ověřte si to:

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

Pokud vidíte jen jedno spuštění, ačkoli se server už někdy restartoval, jsou Vaše logy dočasné. Vytvořte adresář (sudo mkdir -p /var/log/journal a sudo systemd-tmpfiles --create --prefix /var/log/journal) a restartujte journald. Je to důležité: po pádu chcete vědět právě to, co se dělo před restartem.

Od Debianu 12 se rsyslog standardně neinstaluje. Tento program dříve zapisoval textové soubory jako /var/log/syslog a /var/log/auth.log. Na novém serveru s Debianem tedy neexistují; vše je v journalu. Ubuntu rsyslog stále má. Návody, které říkají „podívejte se do /var/log/auth.log“, můžete na Debianu převést na journalctl -u ssh.

Hledání: filtry, které opravdu použijete

Bez filtru zobrazí journalctl vše, od nejstarších záznamů. To je málokdy to, co chcete. Nejdůležitější filtry, které můžete kombinovat:

Priority jdou od 0 (emerg) do 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. S -p err dostanete err a vše závažnější. -p warning zobrazí i varování.

Typický postup hledání. Váš web od rána vrací chybu 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'.

Příčina je tam napsaná doslova: překlep na řádku 42 konfiguračního souboru. Stav 78 (CONFIG) potvrzuje, že jde o chybu v konfiguraci. Nemusíte nic hádat.

Dva tipy ke čtení:

• Čtěte shora dolů a hledejte první chybu. Jedna chyba často vyvolá celou řadu následných zpráv. Ta první bývá příčinou.
• Všímejte si času. Co se kolem té doby změnilo? Automatická aktualizace (lekce 4.2: /var/log/unattended-upgrades/), Vaše úprava, restart?

Další logovací soubory

Ne všechno je v journalu. Mnoho programů zapisuje také (nebo jen) vlastní soubory do /var/log/:

Velké textové soubory čtete pomocí less (hledání pomocí /), konec pomocí tail -n 50, naživo pomocí tail -f a filtrujete pomocí grep:

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

Logy kontejnerů Dockeru nejsou v /var/log, ale přímo v Dockeru: docker compose logs (lekce 9.3).

Logy nesmí zaplnit Váš disk

Plný disk je jednou z nejčastějších příčin, proč server „najednou“ přestane fungovat: databáze se zastaví, aktualizace selžou, někdy se dokonce nemůžete ani přihlásit. Viníkem bývají často logy.

Journal se omezuje sám. Ve výchozím nastavení zabere nejvýše 10 % souborového systému, maximálně 4 GB (SystemMaxUse=). Kolik teď zabírá a jak ho promazat:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # smazat starší než 30 dní
anna@web1:~$ sudo journalctl --vacuum-size=500M    # až 500 MB

Chcete-li pevný limit, nastavte v drop-in souboru /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

a restartujte journald příkazem sudo systemctl restart systemd-journald.

Textové soubory v /var/log spravuje logrotate: každý den nebo týden se soubor přejmenuje (error.log.1), starší verze se zabalí (.gz) a ty nejstarší se smažou. Pravidla pro jednotlivé programy jsou v /etc/logrotate.d/. Balíčky z distribuce si přinášejí vlastní pravidlo. Pokud Váš vlastní program nebo skript zapisuje do vlastního logovacího souboru, vytvořte pravidlo sami, jinak bude soubor růst donekonečna.

Jak zjistit, co zabírá místo:

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

Logy a ochrana soukromí

Logy obsahují IP adresy, uživatelská jména a někdy e-mailové adresy: to jsou osobní údaje. Neuchovávejte je déle, než je nutné (pro malý server je obvyklých několik týdnů až několik měsíců), nenechávejte je veřejně přístupné (adresář /logs ve webrootu je známá chyba) a nekopírujte je bez rozmyslu do služeb třetích stran.

Na AlmaLinuxu a Rocky Linuxu

journalctl funguje stejně. Tam je rsyslog stále standardně zapnutý, se soubory jako /var/log/messages a /var/log/secure (obdoba auth.log). Zprávy SELinuxu jsou v /var/log/audit/audit.log; ausearch -m avc -ts recent zobrazí nedávná zamítnutí.

Shrnutí

• journald shromažďuje všechny zprávy do journalu; čtěte ho pomocí journalctl, filtrovaného podle služby (-u), priority (-p), času (--since) a spuštění (-b).
• Ověřte, že je journal trvalý (/var/log/journal existuje), jinak o logy po restartu přijdete.
• Debian 12 a novější nemají standardně rsyslog, a tedy ani /var/log/auth.log a /var/log/syslog; vše je v journalu.
• Hledejte první chybu a zjistěte, co se kolem té doby změnilo.
• Hlídejte velikost: journal se omezuje sám (--disk-usage, --vacuum-*), textové soubory obstarává logrotate.

Kvíz

Úkol

Úkol Z6.2: Rozbor padající služby. Ve vzorovém souboru journal-crash-1.txt je výstup systemctl status a journalctl služby, která se opakovaně restartuje a pak to vzdá. Odpovězte: jak se služba jmenuje, kolikrát se ji systemd pokusil spustit, s jakým návratovým kódem skončila, jaká je příčina podle první chybové zprávy a v kolik hodin to systemd vzdal? Program Vaše odpovědi porovná s pevným klíčem. Potom se na svém serveru podívejte, zda journalctl -p err -b ukazuje chyby a zda je Váš journal trvalý.

Doporučujeme k přečtení

• Manuál journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Manuál journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, poznámky k vydání 5.1.7 (rsyslog už není standardně instalován): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html