Logy a journald

Když něco spadne, nespustí se nebo se chová divně, odpověď je skoro vždycky v logu. Log je záznam toho, co systém a jeho služby dělaly — kdy se co stalo, jaká přišla chyba, proč se něco nepovedlo. První reflex sysadmina není přeinstalace ani restart naslepo, ale podívat se do logu. V moderním Linuxu jsou dva světy: journald (systemd, binární žurnál, čteš ho přes journalctl) a klasické textové logy v /var/log. Až se v obou naučíš hledat cíleně, přestaneš tápat.

Pár pojmů na úvod

• Log = časová stopa událostí. Řádek s razítkem (timestamp), jménem služby, PID a zprávou. Když se chceš dozvědět „co se dělo v 14:32", jdeš sem.
• journald = logovací služba systemd (systemd-journald). Sbírá zprávy ze všech služeb, kernelu i aplikací do jednoho binárního žurnálu. Nečteš ho textovým editorem — používáš journalctl.
• journalctl = nástroj na čtení žurnálu. Filtruje podle služby, času, priority, bootu. Tvůj hlavní nástroj v téhle kapitole.
• /var/log = klasické textové logy. Soubory jako /var/log/messages, /var/log/secure, a logy jednotlivých aplikací (/var/log/nginx/, /var/log/httpd/…). Čteš je běžnými nástroji (less, grep, tail).
• Priorita = jak vážná zpráva je — od emerg (systém umírá) po debug (detailní ladění). Podle ní se dá filtrovat, ať vidíš jen to důležité.
• Perzistence = jestli žurnál přežije reboot. Volatile = jen v RAM (po restartu pryč), persistent = uložený na disku v /var/log/journal.

Proč logy: první reflex, ne poslední

Přijdeš k tomu, že web neběží, služba se nespustila, nebo se něco záhadně restartuje. Máš dvě možnosti:

1. Hádat a zkoušet — restartovat, přeinstalovat, měnit náhodně konfiguraci. Windows reflex. Většinou nic nevyřeší a jen zameteš stopy.
2. Přečíst si log — otevřít žurnál dané služby, najít chybovou hlášku a timestamp. Odpověď tam skoro vždycky je: „port už používá jiný proces", „chybí soubor", „špatné heslo k databázi".

Sysadmin dělá to druhé. Log ti řekne proč to spadlo — a bez „proč" opravuješ naslepo. Cílem téhle kapitoly je, aby ses při každém problému nejdřív zeptal: „co je v logu?"

Dva světy logů

journald — binární žurnál systemd

Většina moderních služeb (všechno, co běží pod systemd) loguje do journaldu. Není to textový soubor — je to strukturovaný binární žurnál, ke kterému se dostaneš přes journalctl. Výhoda: každá zpráva má metadata (která služba, jaký PID, jaká priorita, přesný čas), takže se dá přesně filtrovat.

journalctl                 # celý žurnál (od nejstaršího), otevře se v less
journalctl -e              # skoč rovnou na konec (nejnovější zprávy)
journalctl -n 50           # posledních 50 řádků

/var/log — klasické textové soubory

Vedle toho pořád existují textové logy v /var/log. Některé aplikace (nginx, Apache, PostgreSQL…) si logují po svém do vlastních souborů, nezávisle na journaldu. A tradiční systémové logy:

ls /var/log                       # co všechno se tu loguje
less /var/log/messages            # obecné systémové zprávy (na Fedoře/RHEL)
less /var/log/secure              # přihlášení, sudo, SSH, auth (RHEL/Fedora)
sudo less /var/log/nginx/error.log   # chyby konkrétní aplikace

💡 Na Debianu/Ubuntu se tradiční logy jmenují jinak — /var/log/syslog místo messages, /var/log/auth.log místo secure. Koncept je stejný, jen jiná jména.

Klíčové zjištění: když appka loguje do journaldu, hledat v /var/log je marné — a naopak. Vždy si napřed ujasni, kam daná služba loguje. Nová služba pod systemd → skoro jistě journald. Klasický webserver nebo databáze → často vlastní soubor v /var/log.

journalctl prakticky

Tady je jádro celé kapitoly. Tyhle přepínače používáš pořád.

Jen jedna služba: -u

Nejdůležitější přepínač. Bez něj se v žurnálu utopíš — vidíš zprávy ze všeho najednou.

journalctl -u nginx              # jen služba nginx
journalctl -u sshd               # jen SSH démon
journalctl -u nginx -n 100       # posledních 100 řádků nginx

Sleduj živě: -f

Jako tail -f — necháš okno otevřené a díváš se, jak zprávy přibývají v reálném čase. Ideální, když zkoušíš reprodukovat problém: spustíš -f, provedeš akci, koukáš, co se objeví.

journalctl -f                    # sleduj celý žurnál živě
journalctl -u nginx -f           # sleduj živě jen nginx

Podle bootu: -b

-b = jen tento boot (od posledního startu). -b -1 = minulý boot. Skvělé, když se ptáš „co se dělo, než to spadlo a restartovalo se".

journalctl -b                    # od posledního startu systému
journalctl -b -1                 # předchozí boot (co bylo před restartem)
journalctl --list-boots          # seznam všech bootů, které žurnál pamatuje

Podle priority: -p

Filtruj podle vážnosti. -p err = chyby a horší (error, critical, alert, emerg). Odfiltruje ti šum a necháš jen to, co bolí.

journalctl -p err                # jen chyby a horší
journalctl -p warning            # varování a horší
journalctl -u nginx -p err       # chyby konkrétní služby

Podle času: --since / --until

journalctl --since "10 min ago"          # posledních 10 minut
journalctl --since today                 # od půlnoci
journalctl --since "2026-07-12 14:00"    # od konkrétního času
journalctl --since "1 hour ago" --until "30 min ago"   # časové okno

Kombo na incident

Přepínače se skládají. Když ladíš konkrétní průšvih, kombinuj službu + čas + prioritu:

journalctl -u nginx -b --since "1 hour ago" -p warning

Přeloženo: ukaž mi ze služby nginx, jen z tohohle bootu, jen za poslední hodinu, jen varování a horší. Z tisíců řádků zbyde pár, které opravdu čteš. Tohle je rozdíl mezi „hledám hodinu" a „našel jsem za 30 sekund".

Perzistence: přežije žurnál reboot?

Dřív býval žurnál často volatile — žil jen v RAM (/run/log/journal) a po rebootu byl pryč. Dnes je ale výchozí Storage=auto: pokud složka /var/log/journal existuje (moderní distra — Fedora, Debian 12, novější Ubuntu — ji mají out-of-the-box), je žurnál persistent. Ověř si to příkazem journalctl --list-boots: když vidíš jen boot 0, jsi na volatile a pomůže návod níž. Volatile je totiž pekelně nepříjemné: stroj spadl, restartoval se, a historie zmizela s restartem.

Zapnutí persistent žurnálu = stačí vytvořit adresář:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal   # nastaví práva
sudo systemctl restart systemd-journald

Od té chvíle se žurnál ukládá na disk a journalctl -b -1 (minulý boot) skutečně něco vrátí. Ověříš:

journalctl --list-boots          # když je persistent, uvidíš víc než jeden boot

🚩 Volatile žurnál je klasická past: řešíš, proč se server v noci restartoval, ale žurnál z té doby neexistuje, protože nebyl perzistentní. Na produkčním stroji chceš vždy persistent.

Rotace a velikost: ať ti logy nesežerou disk

Žurnál i textové logy rostou. Když se o to nikdo nestará, můžou zaplnit disk — a plný disk je sám o sobě zdroj dalších pádů (služby nemůžou zapisovat). Kolik místa žurnál zabírá:

journalctl --disk-usage          # kolik místa žere žurnál

Uklidit ho můžeš podle velikosti nebo stáří:

sudo journalctl --vacuum-size=500M    # nech maximálně 500 MB, zbytek smaž
sudo journalctl --vacuum-time=2weeks  # smaž vše starší než 2 týdny

Natrvalo se limity nastavují v /etc/systemd/journald.conf (např. SystemMaxUse=500M). Textové logy v /var/log řeší nástroj logrotate — automaticky je krájí, komprimuje (.gz) a maže staré. Proto v /var/log vidíš soubory jako messages-20260701.gz.

Priority: od emerg po debug

Každá zpráva má prioritu (severity). Od nejvážnější po nejmíň:

Když dáš -p err, dostaneš prioritu 3 a horší (tedy 0–3). Čím níž na tabulce jdeš, tím víc šumu — -p debug ti vysype úplně všechno. Praktický postup: začni od -p err, a když nic, povol -p warning a -p info.

Correlation: propojit stopy přes službu, PID a čas

Skutečný problém se málokdy pozná z jednoho řádku. Umění je propojit zprávy do příběhu:

• Přes službu (-u) — vidíš celou linku jedné služby: nastartovala, běžela, dostala chybu, spadla.
• Přes čas (--since/--until) — co se dělo ve stejnou chvíli v jiných službách? Často jedna věc shodí druhou (databáze umřela → aplikace hlásí chyby o vteřinu později).
• Přes PID — když víš číslo procesu, dohledáš jen jeho zprávy:

journalctl _PID=1234             # jen zprávy procesu s PID 1234
journalctl _UID=1000             # jen zprávy konkrétního uživatele

Typický postup u „služba se nespustila": journalctl -u sluzba -e → najdeš chybovou hlášku a její timestamp → přepneš na --since kolem toho času bez -u → zjistíš, co jiného se ve stejnou chvíli dělo.

Co v logu vlastně hledat

Když otevřeš žurnál, nečti ho odshora dolů celý. Hledej cíleně:

• Chybovou hlášku — slova jako error, failed, refused, denied, cannot, timeout.
• Timestamp — kdy se to stalo. Sedí to s dobou, kdy uživatel hlásil problém? Sedí to s restartem?
• „Proč se to nespustilo" — u služby hledej řádky kolem Failed to start / Main process exited. Systemd tam většinou napíše i důvod (exit code, „address already in use", „permission denied").

journalctl -u nginx -p err -e            # rovnou na konec, jen chyby nginx
journalctl -u nginx | grep -i "address"  # hledej konkrétní frázi

Failure modes — jak si to zbytečně ztížíš

• Hledání naslepo bez -u a --since. Pustíš holé journalctl a topíš se v tisících řádků ze všech služeb. Vždy zúž na službu a čas — jinak hledáš jehlu v kupce sena, kterou sám sypeš.
• Žurnál není perzistentní. Řešíš noční pád, ale journalctl -b -1 nic nevrátí, protože žurnál žil jen v RAM a s restartem zmizel. Na produkci zapni /var/log/journal.
• Plný disk od logů. Nikdo nehlídal velikost, žurnál nebo /var/log nabobtnal a zaplnil disk — a plný disk shodí další služby. Hlídej journalctl --disk-usage a df -h, nastav limity.
• Čteš /var/log, když appka loguje do journaldu (a naopak). Půl hodiny grepuješ prázdný soubor, protože zprávy jsou úplně jinde. Napřed zjisti, kam služba loguje.

🛠️ Cvičení

1. Jen jedna služba. Vyber si nějakou běžící službu (třeba sshd nebo NetworkManager) a vypiš jen její posledních 30 řádků žurnálu. Jaký přepínač omezí výstup na jednu službu a jaký na počet řádků?
2. Co se dělo teď. Vypiš jen chyby (a horší) za posledních 10 minut ze všech služeb. Poskládej dva přepínače: priorita + čas. Kolik řádků ti zbylo oproti holému journalctl?
3. Přežil žurnál reboot? Zjisti, jestli máš perzistentní žurnál. (Nápověda: journalctl --list-boots a existence /var/log/journal.) Kdyby ne, jak bys ho zapnul a proč je to na serveru důležité?
4. Kolik místa a jak uklidit. Zjisti, kolik místa žurnál zabírá, a napiš (nespouštěj naslepo!) příkaz, který by nechal jen posledních 200 MB. Kde by se dal limit nastavit natrvalo?
5. Kam appka loguje. Najdi jednu službu, která loguje do journaldu, a jednu, která si píše do vlastního souboru v /var/log. Jak poznáš rozdíl a proč je to důležité vědět dřív, než začneš hledat?

🧠 Otázky & odpovědi