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