Jak jsme pomocí ABRTu vychytali chyby ve Fedoře

Nedávno se oficiální účet Fedory na sociálních sítích ptal, proč uživatelé tuto distribuci používají. Asi nejčastější odpovědí bylo, že je to distro s nejlepší podporou GNOME, což mě potěšilo, ale možná ještě více mě u srdce zahřálo, když jsem tam našel hodně odpovědí typu „Nebudete tomu věřit, ale Fedoru používám kvůli stabilitě“. Stabilita Fedory se od doby, kdy jsem ji začal používat, opravdu hodně zvedla a to především v posledních vydáních. Jak se nám to povedlo?

Důvodů, proč je dnes Fedora stabilnější, než kdy dříve, je hned několik. Do značné míry je to dáno tím, že si podstatné změny takzvaně sedly. GNOME 3 zraje jako víno, systemd už má také divoké začátky za sebou a o instalátoru Anaconda ani nemluvím. Dalším důvodem je tým Fedora QA, který má dnes už 10 lidí, kteří Fedoru testují na plný úvazek. To nemá žádná jiná komunitní distribuce. Připočítejte k tomu další testery z řad dobrovolníků a také to, že se rozjíždí automatizované testování. Myslím si, že pomohlo také zaměření, kdy se jsme určili tři hlavní edice – Workstation, Server, Cloud, čímž se určilo to, co musíme mít dobré (tyto tři) a co můžeme mít dobré (všechno ostatní).

Nicméně dnes bych se chtěl věnovat jinému faktoru – ABRT, což je zkratka pro Automatic Bug Reporting Tool. To je nátroj, který pomáhá uživatelům hlásit problémy. Základním problém, který v této oblasti musíte vyřešit, je, aby vám uživatel nahlásil problém v softwaru tak, že jej můžete identifikovat a opravit. Pokud v bugzille najdete hlášení, které říká: „Klikl jsem na čudlík v tabulce a okno zmizelo“, tak vám to při hledání problému moc nepomůže a chyba se s největší pravděpodobností neopraví. Pokud k tomu ale uživatel doplní backtrace a hromadu logů, tak se ta šance výrazně zvyšuje. To byla také první meta ABRTu – posbírat v systému všechny relevantní informace o pádu a umožnit uživateli jej jednoduše nahlásit.

Dopadlo to ale tak, že bugzillu zahltilo obrovské množství hlášení z ABRTu. V možnostech vývojářů prostě nebylo je všechny procházet a analyzovat. Často to tedy dopadalo tak, že vývojáři hlášení z ABRTu rovnou filtrovali pryč. Následovala tedy druhá meta ABRTu – vytvořit na základě hlášení statistiky, které by dokázaly vývojářům říct, které problémy se týkají velkého množství uživatelů (a měly by se tedy opravit) a které problémy jsou okrajové. A pravdě díky tomuto se stal ABRT pro vývojáře Fedory velmi zajímavým nástrojem.

Statistiky pro Fedoru lze najít na Retrace Serveru. Statistiky jsou to opravdu obsáhlé. Nejenže zjistíte, kolik pádů ona chyba způsobila, což je z pohledu prioritizace nejdůležitější informace, ale dozvíte se také, v jaké verzi Fedory, na jaké architektuře, jak se četnost vyvíjela v čase atd. Velmi užitečnou věcí je také to, že ABRT dokáže sdružovat pády na základě podobnosti dohromady, takže je pěkně odhalitelné, že třeba pády v deseti různých komponentách způsobuje chyba v jedné knihovně, kterou tyto komponenty společně používají. Množství hlášení v bugzille se také výrazně snížilo, protože se začaly odhalovat duplikáty a hlášení v bugzille vytvářet pouze, pokud bylo sesbíráno dostatek informací o pádu.

abrt-hlaseni
Ukázka hlášení.

V desktop týmu jsme začali ABRT intenzivně používat před rokem a půl. Vývojářům je kladeno na srdce, aby statistiky pravidelně procházeli a kontrolovali, jestli se náhodou jejich komponenty nenacházejí ve statistikách častých pádů. Pravidelně to procházím i já a pokud narazím na něco, co má na starosti můj tým, daného vývojáře na to upozorním. Nicméně v poslední době je to spíše nuda. Když se podíváte na statistiky ze stabilních verzí, budete tam komponenty z desktopu dlouze hledat. A když na něco narazíte, tak už to je většinou označené jako opravené.

Přitom dřív tomu tak nebylo. Fedora je stále primárně využívaná na desktopu, takže desktopové komponenty jsou dost exponované a dříve se ve statistikách objevovaly vysoko. ABRT nám ale umožnil efektivně prioritizovat a zaměřit se na opravdu exponované chyby. A jde to vidět i v reálném použití. Na pády v GNOME nebo výchozích aplikacích dnes narážím zcela výjimečně.

Po dobrých zkušenostech v GNOME, jsem řekl také klukům, kteří se starají o KDE, aby ABRT více využívali. Když statistiky procházeli, narazili na pády, které měly původně někde na úrovni X nebo ovladačů, takže mimo jejich dosah, ale také tam bylo plno chyb, které byly triviální „onelinery“ a přitom otravovaly život tisícům uživatelů. Statistiky ABRTu dnes používají také někteří naši partneři. Vím, že Intel je používá na sledování problémů v jejich grafickém ovladači (problémů v kernelu je ve statistikách zdaleka nejvíce, ale nejedná se o klasické pády, ale v drtivé většině případů hlášení problémového chování, kterého si uživatel ani nevšimne). ABRT nasadili také v CentOS, jehož statistiky se hodí při hledání chyb, které nás trápí v Red Hat Enterprise Linuxu.

ABRT je také velmi užitečný z pohledu uživatele. Nejenže za vás posbírá všechny relevantní informace o pádu a nabídne vám jejich nahlášení do bugzilly, ale pokud tyto věci nechcete řešit, můžete povolit jen automatické zkrácené hlášení, které bude posílat otisky pádů do statistik, čímž nám minimálně dáte vědět, že se vás daný problém taky týká. Toto zkrácené hlášení lze posílat také na pozadí. To zapínám u těch lidí, které nějaké hlášení problémů nezajímá a ani o pádech nechtějí být informovaní, přesto ale můžou svým dílem přispívat ke kvalitě Fedory. ABRT využívám také u pádů, které se týkají cizího softwaru, který není v repozitářích Fedory. Pokud totiž chci nějaký problém vývojářům takového softwaru nahlásit, ABRT mi nabídne o pádu ucelené informace, z kterých si můžu vyzobnout potřebné informace, a nebo je rovnou všechny jako jeden balík vývojářům poslat.

ABRT opravdu velkou měrou přispěl ke zkvalitnění Fedory, minimálně v oblasti desktopu. A za to abrťákům patří velký dík.

9 komentářů: „Jak jsme pomocí ABRTu vychytali chyby ve Fedoře“

  1. Kolemjdouci avatar
    Kolemjdouci

    Mé zkušenosti s Fedorou jsou opačné – padá čím dál více a stále je naprosto nevhodná na nasazení v produkčním prostředí a hlavně mi na některých strojích kompletně zamrzá což je u Linuxového systému naprosto nepřípustné. Proto jsem se vratil k Debianu, který je etalonem kvality a stability.

    1. sesivany avatar

      Pokud máte ten pocit, tak vám ho vymlouvat nebudu. Nicméně data od tisíců uživatelů minimálně v případě desktopu mluví o něčem jiném. Pokud vám systém kompletně zamrzává, tak je s největší pravděpodobností problém s ovladači. Ano, to je momentálně největší slabina Fedory. Nicméně je to slabina prakticky každé distribuce. Dokud se do nich nebude více investovat, tak se to nezlepší. Že nějaká hardwarová sestava funguje v jiné distribuci lépe, je pěkné, ale na jiné sestavě to může být přesně naopak. Když jsem dřív používal Debian, tak jsem si na několika počítačích vylámal zuby taky, především kvůli starým ovladačům.

  2. lukaskotek avatar
    lukaskotek

    Moje zkušenosti jsou podobné. Ještě u F20 bych dokázal popsat pár nepříjemných potíží, kdy i následná hlášení ABRTu byla častá až iritující, ale poslední dvě vydání cítím výrazný pokrok vpřed. Vlastně si teď nevybavuji, kdy naposledy jsem na něco narazil, takže za mě dobré 🙂

  3. capvi avatar
    capvi

    Fedoru vyuzivam denne na pracovnim stroji a naprosto bez problemu a bez padu. Sice misto gnome jedu na xfce (kvuli trhani pri nahledu workspacu na 2-monitorovem setupu a naprosto, omlouvam se za to slovo, dementni vysouvaci liste; ne ze by minule reseni bylo nejak povedene), ale s distribuci jsem naprosto spokojeny! Nemam problem se dostat na uptime 80 a vice dnu, ale kvuli updatum kernelu restart udelam. Takze diky za skvele odvedenou praci!

    1. noxmail avatar
      noxmail

      Spodna vysuvacia lista v gnome 3.16 uz nie je. A nie je problem pouzivat gnome classic, kde je bezny panel so spustenymi aplikaciami apod. Ale xfce mam tiez rad na slabsom pc idealne.

      1. capvi avatar
        capvi

        Vysouvaci listou jsem mel prave na mysli tu listu, ktera se vysouva z dolniho leveho okraje a vzdy zabira nekolik pixelu (vadilo mi to zejmena v terminalu). Gnome classic je divne reseni, chvili jsem pouzival Centos7 a nezvykl jsem si. Takze pouzivam xfce(bohuzel zatim jine prostredi mi nedokazalo nahradit rychlost, stabilitu a intuitivni ovladani).

    2. eischmann avatar

      U té lišty bychom měli zablokovat aspoň to automatické vysouvání po najetí do rohu. Mám dva monitory, primární napravo a při přejíždění myší tu lištu v jednom kuse vysunuju. Mám v týmu člověka, který pracuje na GNOME Shellu, a má za úkol to automatické vysouvání zrušit. Akorát doteď řešil podstatnější problémy v Nautilu, tak se k tomu ještě nedostal. V 3.18 a F23 by to ale mělo být změněné.
      Jinak dá se toho úplně zbavit tak, že člověk použije rozšíření Top Icons, které ty zástupce přesune na horní lištu.
      To trhání se mi na jednom slabším počítači podařilo vyřešit rozšířením, které ty efekty výrazně zrychluje nebo úplně zakáže. Pak se to tak netrhá.

  4. antonin avatar
    antonin

    Fedora se zlepšuje. Je vidět, že tam jsou lidi, kteří na tom dělají. Jejich práce má smysl a je vidět. Dík.

  5. Pavel Ruzicka avatar

    Asi budu muset ABRT zapnout. Zatim nejlepsi zkusenosti mam s Fedorou 19. Fedora 22 mi behem prace v KDE neustale problikavala obrazem, vzdy na chvili zcernal, coz jsem prekvapive vyresil zapnutim Framebufferu v kernelu pri bootovani.
    Bohuzel stale pada Plasma v KDE mnohokrat denne. Kdyz jsem mel window decoration „Plastik“, ktery je muj oblibeny, tak se po nejakych updatech zacal zasekavat cely desktop.
    Slo se jen prepnout do konzole a killnout Xka. Prepnuti na Breeze dela jen to padani Plazmy. Pocitac je stolni HP Compaq Elite 8300 MT a grafika asi v procesoru: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09).
    Bohuzel neni ta situace ohledne KDE desktopu moc dobra. Uznavam, ze za to nejspis muzou ovladace grafiky, pripadne kernel 4.0, ale chapu, ze to pak bezneho uzivatele odradi od pouzivani Linuxoveho desktopu.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *