Úvod

Nedávno se u Workstation SIG objevil návrh odstranit z GNOME nástroj pro hlášení pádů aplikací jménem ABRT. Přiznám se, že mě to trochu zamrazilo. ABRT totiž patřil k věcem, které ve Fedoře fungovaly až podezřele pohodlně. Když aplikace spadla, stačilo pár kliknutí a nástroj sám prozkoumal coredump, vytvořil backtrace a připravil hlášení do Bugzilly.

ABRT byl zkrátka takový bagrt. Stačilo mávnout na řidiče, bagrt hrábl lžící, nabral všechno potřebné a odvezl to rovnou k vývojářům. Jenže teď je bagrt pryč.

Možná se porouchal, možná na něj už nikdo nemá čas, možná se jen nevešel do nových plánů. Ať tak nebo tak, když dneska chceme zjistit, proč aplikace spadla, nezbývá než si plivnout do dlaní a vzít do ruky lopatu. Naštěstí je to docela dobrá lopata a jmenuje se coredumpctl. V tomto článku si ukážeme, jak se s ní správně rozmáchnout, abychom mohli nahlásit pád aplikace stejně dobře, jako dříve s ABRTem.

Co je coredumpctl a co dělá?

coredumpctl je nástroj v linuxových distribucích, který slouží ke správě a analýze záznamů o pádech aplikací (core dump). Je součástí ekosystému systemd a pracuje nad službou systemd-coredump, která automaticky zachycuje pády programů.

Když aplikace v Linuxu havaruje, například kvůli segmentation fault, může systém vytvořit core dump. To je soubor obsahující snímek paměti procesu v okamžiku pádu. Tento soubor je velmi užitečný pro vývojáře, protože umožňuje zpětně analyzovat, co program dělal těsně předtím, než definitivně vypustil duši. Coredumpctl nám umožňuje tyto záznamy:

  • zobrazit seznam všech zaznamenaných pádů aplikací
  • zobrazit informace o konkrétním pádu (PID, čas, program, signál)
  • uložit core dump do souboru
  • automaticky otevřít dump v debuggeru gdb

Ověříme, že záznam o pádu vznikl

Po pádu aplikace, máme-li štěstí, se uloží záznam o pádu aplikace. Tyto záznamy si můžeme vypsat a zjistit, zdali se uložil i ten, který nás zajímá:

coredumpctl list

Tento seznam může vypadat třeba nějak takto.

TIME                           PID  UID  GID SIG     COREFILE EXE                     SIZE
Thu 2025-11-13 09:50:10 CET   5341 1000 1000 SIGABRT missing  /usr/bin/gnome-shell       -
Thu 2025-12-18 23:15:51 CET   5238 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -
Mon 2025-12-29 23:20:13 CET   4867 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -
Wed 2025-12-31 09:30:18 CET  13705 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -
Wed 2025-12-31 18:36:36 CET   5907 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -
Sat 2026-01-03 17:53:33 CET   4888 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -

Když by byl seznam příliš dlouhý a pokud víme, jak se jmenuje aplikace, která spadla, můžeme výstup omezit příkazem:

coredumpctl list <nazev_binarky>

Pokud znáte přibližný čas pádu, pomůže filtr „od“:

coredumpctl list --since "2026-02-16 13:00:00"

Nás budou v získaném seznamu zajímat především tyto čtyři sloupce: TIME, PID, COREFILE a EXE. Čas je samozřejmě jasný a můžeme se podle něj snadno orientovat, PID je identifikátor spadnutého procesu a je pro nás nejdůležitější. COREFILE ukazuje, zda máme k záznamu nějaká data. V našem případě vidíme, že všechna jsou missing, tedy pro tyto pády žádná data nemáme a už nebude možné core dump ze systému získat.

Core dumpy jsou mnohdy veliké soubory, a proto je systém po nějaké době odstraňuje. V defaultním nastavení se core dumpy odstraní, jakmile zabírají 10 % diskového prostoru nebo maximálně 4 GB. V konfiguračním souboru coredump.conf si můžeme nastavit proměnnou MaxUse=20GB a v tom případě se core dumpy v systému udrží déle, protože jim dovolíme zabrat až 20 GB. Více se dočtete v manuálových stránkách, tedy man coredump.conf. Budeme si pamatovat, že když nám aplikace spadne a my chceme pád ohlásit, musíme core dump zpracovat co nejdříve. Pokud sloupeček obsahuje hodnotu present, máme vyhráno.

Sloupec EXE pak ukazuje název spustitelného souboru procesu, který spadl, a právě tam můžeme zjistit jméno aplikace pro filtrování daného seznamu, o kterém jsme se zmínili výše.

Prohlédneme detaily záznamu

Z výpisu si vezměte PID nebo ID, které coredumpctl zobrazuje, a vypište detaily:

coredumpctl info <PID>

Zkontrolujte hlavně EXE, Command Line a Timestamp. Pokud nesedí, vraťte se a vyberte jiný záznam.

Informace z tohoto příkazu jsou také jediné informace, které o pádu dostanete, pokud už systém stačil záznamy odklidit. Nemáte-li však k dispozici nic lepšího, nahlašte bug tak jako tak a přiložte alespoň výpis tohoto příkazu. I to může leckdy stačit.

Ukládáme coredump do souboru

Systemd-coredump ukládá dump interně, ale vy ho snadno vyexportujete do souboru:

coredumpctl dump <PID> -o core.<PID>

Ověřte velikost, protože coredumpy bývají velké:

ls -lh core.<PID>

Pozor však na bezpečnost. Coredump je paměť procesu, ve které se mohou nacházet hesla, tokeny, cookies, části dokumentů, URL s parametry nebo další osobní data. Nenahrávejte tedy coredump nikdy na veřejná úložiště, pokud si nejste absolutně jistí tím, že je vše v pořádku. Přikládejte coredump teprve tehdy, když si ho vývojáři vyžádají, a i tak jen přes soukromé kanály. K nahrání do Bugzilly slouží tzv. backtrace či stacktrace.

Komprimujeme coredump a šetříme naše lesy

Pro issue tracker je praktické coredump komprimovat. Například nástroj xz mívá výborný poměr komprese:

xz -T0 -9 core.<PID>

Pokud chcete rychlejší kompresi za cenu většího souboru:

xz -T0 -3 core.<PID>

Získáváme textový backtrace

Vývojáře často zajímá backtrace víc než samotný coredump a také jsme si řekli, že je bezpečnější posílat právě ten. Získáme jej tak, že zapneme debugger pro proces, ze kterého chceme backtrace vygenerovat:

coredumpctl debug <PID>

Tento příkaz spustí gdb. Hned po startu se nás debugger zeptá, jestli chceme použít debuginfod, což umožní debuggeru stahovat metadata pro debugovací proces automaticky z databáze, a nemusíte tak instalovat mnoho debugovacích balíčků. Stažené symboly se ukládají do ~/.cache/debuginfod_client/ a časem se tam může nashromáždit docela hodně dat, takže je vhodné ten adresář občas promazat.

Proces debugování spustíme pomocí následujících příkazů:

set pagination off
thread apply all bt full
quit

Pokud chceme backtrace uložit přímo do souboru, nastavíme přesměrování do onoho souboru příkazem set logging a pak teprve provedeme samotné debugování:

set pagination off
set logging file backtrace.<PID>.txt
set logging on
thread apply all bt full
set logging off
quit

Když se coredump neobjeví

Někdy aplikace spadne, ale coredump se ve výpisu neobjeví a není tak co prozkoumávat. Mezi nejčastější důvody patří:

  1. Aplikace neskončila tzv. signálem. Pokud proces nespadl signálem typu SIGSEGV nebo SIGABRT, nebo pokud byl takový pád ošetřený v samotné aplikaci, nemusí se coredump vytvořit.
  2. Vytváření coredumpů je vypnuté limitem. Zkontrolujte ulimit -c.Hodnota 0 znamená nulový prostor pro coredump, a tak jej kernel vůbec nevytvoří. Dočasně lze pro aktuální shell zapnout: ulimit -c unlimited,případně nastavte limit systémově v souboru /etc/security/limits.conf.
  3. Limity a úložiště v systemd-coredump. Podívejte se docat /etc/systemd/coredump.conf

Důležité bývá Storage a velikostní limity, například ProcessSizeMax, ExternalSizeMax a MaxUse.

Co přiložit k reportu?

Minimum, které téměř vždy urychlí řešení:

  • Backtrace všech vláken: thread apply all bt full
  • Verze balíčku: rpm -q nazev_balicku
  • Verze Fedory: obsah /etc/os-release
  • Reprodukční kroky: co přesně jste spustili nebo klikli, případně vstupní data

Coredump jako soubor přikládejte až tehdy, když je to nezbytně nutné, ideálně po domluvě s maintainery.

Závěr

V tomto článku jsme si ukázali, jak je možné pokračovat ve sbírání informací o pádech aplikací i poté, co ABRT z Fedory zmizí. A že to vlastně není ani tak moc těžké.

Nezbývá než doufat, že lidé i přes menší pohodlí nepřestanou problémy hlásit, protože open source je tradičně věcí nás všech a jak víme, více hlav víc ví a více rukou více udělá. Koneckonců se ještě pořád může najít šikovný mechanik, který ten bagr opraví a namaže k všeobecné spokojenosti.

Publikováno pro mojefedora.cz. Tip: Pokud používáte debuginfod a cache narostla, typicky ji najdete v ~/.cache/debuginfod_client/ a můžete ji bezpečně smazat.