Jak na Ubuntu/Debianu rychle najít chyby v logách (praktický postup + příkazy)

Doba čtení: 5 minut

Logy jsou na Linuxu nejrychlejší cesta, jak zjistit „co se stalo“ a „proč se to stalo“.

Na moderních Ubuntu/Debian systémech je primární zdroj logů systemd-journald (čteš přes journalctl), a paralelně často existují i klasické log soubory v /var/log (podle konfigurace rsyslogu a aplikací). Standardní umístění logů v /var/log vychází z Filesystem Hierarchy Standard. documentation.ubuntu.com

Nejefektivnější je držet se vždy stejného postupu: zúžit časové okno, určit komponentu (kernel vs služba vs aplikace), vyfiltrovat prioritu (warning/error), a teprve potom řešit detail.

1. Rychlá diagnostika „co teď nefunguje“
   Když něco nejde nastartovat nebo padá, nezačínej grepováním po disku. Začni jednotkou systemd a jejími logy.

Základní trojice:

• systemctl status ti dá aktuální stav, poslední řádky a často i důvod (exit code, signal, config path). digitalocean.com

• journalctl -u … je přesně to, co hledáš, protože filtruje jen danou službu.

Tip: když řešíš „služba po rebootu nenaběhla“, používej -b (logy jen z aktuálního bootu) a -e (skočí na konec).

2. Najdi chyby v konkrétním bootu (aktuální / předchozí)
   Velmi častý scénář: „ráno po restartu to nejede“. Pak tě zajímá konkrétní boot.

• --list-boots ukáže seznam bootů (ID a čas).

• -p err..alert filtruje jen závažnosti od error výš (error/critical/alert/emergency).

Pokud potřebuješ časové okno:

3. Kernel, ovladače, hardware: kde to najdeš nejrychleji
   Jestli máš podezření na disk, ovladač, kernel panic, I/O chyby, firmware, síťovku, USB apod., zúž se na kernel logy:

• journalctl -k = jen kernelové zprávy (v praxi nejrychlejší).

• dmesg -T je dobrý doplněk, hlavně když chceš „poslední kus“ a rychlý kontext.

4. Klasické log soubory v /var/log: co typicky stojí za to projít
   Na Debian/Ubuntu se často setkáš s těmito soubory (podle systému a nastavení):

• /var/log/syslog – obecné systémové zprávy (pokud je rsyslog aktivní)

• /var/log/auth.log – přihlášení, sudo, ssh, PAM

• /var/log/kern.log – kernelové zprávy (někdy zvlášť)

• /var/log/dpkg.log – instalace/aktualizace balíčků přes dpkg

• /var/log/apt/history.log a /var/log/apt/term.log – historie a výstupy APT

Přehled typických logů na Ubuntu serveru uvádí Ubuntu Community Help. manpages.ubuntu.com+1

Praktické příkazy:

Poznámka: část systémů dnes loguje primárně do journald a syslog soubor může být prázdný nebo chybět. Chování journald (včetně perzistence na disk) definuje systemd-journald a jeho konfigurace. wiki.ubuntu.com+1

5. Bezpečnostní a přístupové problémy (ssh, sudo, zamykání účtů)
   Když řešíš „nejde přihlášení“, „někdo zkouší brute-force“, „něco se zamyká“, dívej se do auth logů nebo do journald podle jednotky:

U ssh se obvykle rychle chytíš na „Failed password“, „Invalid user“, „Accepted“, „PAM“ apod.

6. Co se měnilo: aktualizace a instalace balíčků
   Velmi častá příčina incidentů na serverech: „něco se aktualizovalo“ (kernel, libc, webserver, PHP modul).

Tím si dáš do korelace: čas změny vs čas, kdy se rozbil provoz.

7. Když systém padá: crash reporty a OOM
   Na Ubuntu může do hry vstoupit Apport (crash reporting) a adresář /var/crash (pokud je povolený). wiki.debian.org
   Na „umírání pod zátěží“ hledej OOM (Out Of Memory) typicky v kernel logu:

8. Pomalý boot, timeouts, služba čeká na síť/disk
   Tady je nejrychlejší systemd-analyze:

9. Jak logy exportovat pro analýzu (a přitom se nezastřelit)
   Na sdílení do ticketu/AI analýzy je praktické vypsat relevantní výřez a držet se času a jednotky:

Doporučení: před odesláním logů počítej s tím, že mohou obsahovat osobní údaje, tokeny, URL s parametry, e-maily, IP adresy. Minimálně je vizuálně zkontroluj a citlivé věci začerň.