Tracer

14.7.2014 21:05 | Přečteno: 1395× | | poslední úprava: 15.7.2014 11:21

Nástroj, který vyhledá neaktuální spuštěné aplikace

Rád bych vám představil svou bakalářskou práci. Začal jsem předčasně, neobhajoval jsem ji tedy v tomto školním roce, ale čeká mě to (snad) až v následujícím, což znamená, že nemám hotový produkt, ale něco, co doposud vidělo jen pár lidí. Nyní bych vám rád ukázal o co jde.

Problém

Když spustíme aplikaci, do paměti se načtou knihovny a soubory potřebné k jejímu běhu. Pokud je některá z knihoven, nebo samotná aplikace po dobu jejího běhu aktualizována, v paměti stále zůstanou původní soubory, přestože na disku už nemusí existovat (mohou být smazány, nebo nahrazeny novějšími verzemi). Pro uživatele není zrovna jednoduché zjistit, které aplikace mohla aktualizace systému ovlivnit. Můj prográmek, který jsem pojmenoval tracer, se snaží tento problém řešit - nalezne totiž takto ovlivněné aplikace, uživateli je vypíše a doporučí jejich restartování.

Myslím si, že to může být užitečné především u rolling distribucí, kde si uživatelé vlastně nemohou být na 100% jisti, zda jim aplikace/služba po rebootu opravdu naběhne, ale věřím, že tracer využije i spousta uživatelů klasických distribucí.

Funkcionalita

Zatím mám implementováno:

• Vyhledání neaktuálních spuštěných aplikací
• Zobrazení informací o dané aplikaci a způsobu jak ji restartovat
• Integraci s balíčkovacím systémem DNF
• Interaktivní mód
• Možnost specifikovat seznam aplikací, které chceme zkontrolovat

viz User Guide pro konkrétní ukázky použití a ukázky výstupů z programu. Veškeré návrhy na rozšíření funkcionality jsou vítány.

Podpora distribucí

Dle zadání práce je primární podporovanou distribucí Fedora, ale nevidím důvod, proč by to nemohlo fungovat i jinde. Aktuálně program běží i na Gentoo a Debianu. Naportovat jej na jiné distribuce je samozřejmě možné a záleží spíše na tom, zda o to bude zájem.

Instalace

Program je zatím řádně zabalíčkován pouze pro Fedoru. Pro Gentoo pak mám ebuild, ale ten ve skutečnosti udělá jen git clone aktuální verze z gitu, jediná přidaná hodnota je tedy to, že si pohlídá a nainstaluje závislosti. Všichni ostatní mají možnosti použít verzi z gitu bez balíčku, případně si to zabalíčkovat pro svou distribuci. Koukněte na Get Tracer.

Feedback

Proč to sem píši? Kromě toho, že bych vám rád představil svůj projekt, rád bych zjistil, zda je o něco takového vůbec zájem a zda si najde své uživatele. Dále bych vás chtěl požádat o připomínky a feedback, který by mi pomohl přiblížit mou představu toho, jak by to mohlo vypadat, tomu, jak by chtěli uživatele, aby to vypadalo. Mohli jste si všimnout, že podporovaných distribucí zatím není mnoho. Určitě není v mých silách podporovat všechny sám, proto bych chtěl požádat vás, komunitu, abyste se v případě zájmu, zapojili. Ať už pouhým napsáním "Chtěl bych tento program používat na XY", nebo přímo zabalíčkováním a správou balíčku pro danou distribuci. V obou případech budu mít radost.

Tracer při své činnosti přistupuje (samozřejmě pouze čtením) k databázi balíčkovacího systému a zjišťuje určité informace. Při portaci na novou distribuci je potřeba dané funkce poskytnout. Vzhledem k tomu, že existuje podpora pro Debian, portovat tracer na cokoliv s dpkg by mohlo být otázkou pár řádků. Ovšem pro distribuce mající specifický balíčkovací systém, bude potřeba implementovat celý modul. Pokud by někdo měl zájem i o tohle, nechť mě libovolným způsobem kontaktuje. Vysvětlím a pomůžu se vším co bude potřeba. Předesílám, že opravdu nejde o raketovou vědu, ale o implementaci pár jednoduchých funkcí.

Nakonec, každý program je jiný a já nemůžu otestovat všech nekonečně mnoho, zda jej tracer opravdu najde. Proto pokud se vám stane, že ve výstupu bude nějaká aplikace chybět, nebo naopak přebývat, dejte prosím vědět.

Za každý přínosný komentář předem děkuji.

Odkazy

• GitHub
• Wiki
• User Guide
• Zadání BP

       

Komentáře

[D-Evil]

Čím se to liší od checkrestart?

[FrostyX]

Jednak jsem o checkrestart nikdy neslyšel, takže děkuji. Určitě se na něj podívám, zkusím prozkoumat, jak to řeší oni.

Potom, BP pochází z RedHatu a jejich požadavkem bylo, aby ten nástroj byl funkční i na Fedoře. Což checkrestart nejspíš nesplňuje.

PS: Zrovna jsem to nainstaloval, vyzkoušel a subjektivně si myslím, že nemají příliš user-friendly výstup.

[FrostyX]

Navíc v současné době mám funkční plugin pro fedoří balíčkovací systém DNF, v budoucnu bych rád udělal něco podobného i pro ostatní balíčkovací systémy (pokud budou podporovat nějakou obdobu pluginů)

[karel]

Soucasti balicku yum-utils je prikaz needs-restarting, ktery dela totez. Muzes to vyuzit minimalne pro otestovani/srovani funkcionality (jen pozor, v kvetnu jsem v nem opravovalo par vyznamnych chyb, tak se ujisti, ze mas opravenou verzi) A taky jsem nedavno narazil na blog, kde se autor zminuje o svem skriptu, ktery snad pracuje jeste o stupen lepe nez needs-restarting, ale hloubeji jsem to nezkoumal.. Treba z toho neco vyctes a muzes v BP programy vzajemne porovnat. http://ingvar.blog.redpill-linpro.com/tag/needs-restarting/

[karel]

...v kvetnu jsem v nem opravovalo...

Melo to byt "v kvetu se v nem opravovalo...", ja sam je neopravoval, jen jsem na jednu z nich narazil.

[FrostyX]

Děkuji, o needs-restarting vím. Jako problém vidím to, že není user-friendly (stejně tak jako checkrestart pro debian, zmíněný výše. Už jen první pohled

[frostyx@localhost ~]$ sudo needs-restarting
1385 : gvim -f 
961 : xfce4-terminal --geometry=80x24 --display :0.0 --role=xfce4-terminal-1404752667-2093205702 --show-menubar --show-borders --hide-toolbar --working-directory /home/frostyx --window --geometry=135x32 --display :0.0 --role=xfce4-terminal-1404680775--1537418211 --show-menubar --show-borders --hide-toolbar --working-directory /home/frostyx/dotfiles --tab --working-directory /home/frostyx/dotfiles/.vim/bundle/YouCompleteMe --sm-client-id 2163acf15-c689-4f32-b713-6d1b1c824234 

Oproti

[frostyx@localhost ~]$ sudo tracer
gvim
xfce4-terminal

Navíc tracer umožňuje definovat pravidla pro konkrétní procesy. Takže mu můžu říci, že mě s nějakými polkit, udisks a gvfs procesy nemá otravovat, protože je stejně nemůžu restartovat. To je samozřejmě řízeno daty, takže v současné době existuje systémový soubor, který bude brzy obohacen o uživatelsky definovaný soubor někde v /etc případně /home.

Taky si hlídám to, že nějaký proces spustil jiný a měl by být restartován za pomocí toho nadřazeného. Například jsem aktualizoval flash player, tak nechci aby se vypsal flash player, protože je ve skutečnosti potřeba restartovat chromium, aby se změna projevila.

[kouzer]

Na openSUSE je 'zypper ps', který vypíše seznam programů a knihoven, jež se dotkl upgrade/dist-upgrade a je dobré je restartovat.

[marbu]

Tohle je naportovane i pro yum (balik yum-plugin-ps) a pouzivat se stejne: yum ps

[xkucf03]

1. Změnil bych název – „tracer“ je příliš obecné slovo, nevím, co si pod tím představit, když to někde uvidím + když to budu někde hledat, tak najdu milion jiných věcí. To už radějí nějaký „old library killer“ nebo zkus vymyslet nějakou zkratku (ideálně rekurzivní jako GNU nebo Wine), která bude relativně jedinečná.
2. VŠ práce by měla obsahovat teoretickou část – před psaním kódu by to chtělo udělat pořádnou rešerši, jaké nástroje existují, v čem mají chyby a co bys dělal jinak. Pak zhodnotit, zda je lepší psát nový program nebo raději vylepšit stávající (nebo k němu udělat přívětivé uživatelské rozhraní) a podpořit to argumenty.
3. Hlášky „You should restart“ a „Nothing needs to be restarted“ jsou specifické pro DNF? Neměly by být spíš někde v jádře programu?

[FrostyX]

Díky za podměty k přemýšlení.

1. Rozhodně na tom něco bude.
2. V minulosti jsem program podobného typu hledal (pro Arch) a nic jsem nenašel. Potom jsem udělal menší průzkum i v ostatních distribucích a taky jsem nic nenašel. Nejspíš jsem hledal blbě. Až v průběhu programování jsem na ně postupně začal narážet. Každopádně tohle zadání BP se mi hodně líbilo, takže bych se do toho pustil i kdybych o nich věděl dříve.
3. Pokud je tracer explicitně spuštěný uživatelem a nic nenajde, nechtěl jsem aby říkal, že nic nenašel. Protože Rule of Silence: When a program has nothing surprising to say, it should say nothing.
   Ale když je spuštěný z DNF pluginu, je potřeba aby se nějak ozval. Máš ale pravdu, že by text hlášky mohl být v jazykovém souboru a v pluginu bych se na něj mohl jen odkazovat. Napravím ...

[Josef Kufner]

Najdi si něco, čím ho odlišíš od ostatních. Při obhajobě se ti to bude hodit.

[wamba]

No používám Manjaro (Archlinux), tak nemůžu ozkoušet, ale co pro tento proces: /usr/bin/python2 /usr/share/system-config-printer/applet.py upozorní mě to při povýšení system-config-printer, že mám restartovat system-config-printer-applet?

[FrostyX]

Vyzkouším. Jestli neupozorní teď, tak v budoucnu určitě

[FrostyX]

Díky za dotaz. Hezky jsi poukázal na to, že mi to nenajde pythonní aplikace. Nějaký hloupý bug, protože wicd mi to normálně nacházelo. Určitě to brzo opravím.

Btw oproti konkurenci na tom nejsem úplně špatně, needs-restarting ho taky nenašel

[mess]

A co Ruby, Perl, shellové skripty, ...? Detekuje je to taky? Ať už při aktualizaci skriptu nebo interpretu (či nějaké jeho části). Jinak zajímavý počin

[FrostyX]

No, co tu mam uložené nějaké staré výstupy, tak se tam wicd normálně objevoval. A to jsem to nedělal konkrétně pro python, takže by to mělo fungovat i pro jiné interpretry. Až najdu tu chybu, tak vyzkouším.

[Petr Tomášek]

Pokud je některá z knihoven, nebo samotná aplikace po dobu jejího běhu aktualizována...

Eeeee?

[FrostyX]

Když spustíme aplikaci, do paměti se načtou knihovny a soubory potřebné k jejímu běhu. Pokud je některá z knihoven, nebo samotná aplikace po dobu jejího běhu aktualizována, ...

Po dobu běhu té aplikace ... nevím, mě to zní normálně. Je to špatně?

[Kvakor]

Neřekl bych špatně, jen nejednoznačně. Lepší by to bylo třeba takto:

Pokud jsou soubory některé z knihoven nebo samotné aplikace po dobu jejího běhu aktualizovány, ...

Jde o to, že ty staré soubory mohou stále být na disku dokud jsou otevřené (platí automaticky pro binárku i knihovny běžícího procesu), protože soubor je smazaný až tehdy, když počet referencí na něj klesne na nulu. Běžící proces může s takovým souborem víceméně normálně pracovat, ale pro ostatní procesy je normálnímy prostředky nedostupný.

PS: Je možné udělat takovýto program i bez podpory balíčkovacího systému, pokud by prolezl všechny procesy v /proc a kouknul se, jesli některý nemá smazanou binárku nebo knihovnu (skrz soubor exe a maps), případně jestli nedrží otevřené soubory, které jsou smazané (symlinky v adresáři fd). Jen je třeba dát pozor na vlákna jádra, protože ty žádnou binárku nemají, ale není problém je poznat, protože nemají nic namapovaného a nemají nastavené prostředí. Jediná nevýhoda by byla, že by vypsal jen procesy, ale ne aplikace/služby. nicméně pokročilému uživateli by to nejspíš nevadilo ...

[FrostyX]

Díky za velmi zajímavý komentář.

Jde o to, že ty staré soubory mohou stále být na disku dokud jsou otevřené (platí automaticky pro binárku i knihovny běžícího procesu), protože soubor je smazaný až tehdy, když počet referencí na něj klesne na nulu. Běžící proces může s takovým souborem víceméně normálně pracovat, ale pro ostatní procesy je normálnímy prostředky nedostupný.

Já myslel, že ten proces má všechny soubory potřebné k běhu načtené v paměti a přistupuje k nim do paměti, ne na disk. Z hlediska implementace na tom stejně nezáleží, ale až budu psát dokumentaci k BP, tak si k tomu rozhodně něco přečtu, ať tam nenapíšu hlouposti. Díky.

Je možné udělat takovýto program i bez podpory balíčkovacího systému, pokud by prolezl všechny procesy v /proc a kouknul se, jesli některý nemá smazanou binárku nebo knihovnu

Takže vlastně lsof |grep deleted, najít cesty do souborového systému a ty procesy vypsat? To zní až moc jednoduše . Zkusím to.

[FrostyX]

Tak jsem napsal takový snippet https://gist.github.com/FrostyX/95822fa5ce34ead7b140 který projde všechny procesy a všechny soubory které používají. Když je u některého napsané "(deleted)" proces vypíše.

Vypadá to funkčně. Ty tedy myslíš, že vůbec nebude potřeba zjišťovat z package manageru informaci o aktualizovaných balíčcích?

[xkucf03]

IMHO bude potřeba zkombinovat oba přístupy – předmětem aktualizace můžou být i datové soubory nebo třeba skript, který se jednou načte a pak už se jako otevřený soubor nedrží.

[GEDIK]

jednoduše:

alias vyhnite='lsof | grep '\''DEL.*lib'\'' | cut -f 1 -d '\'' '\'' | sort -u'

[FrostyX]

Tohle mi ve skutečnosti nenašlo vůbec nic.

[GEDIK]

zajimave, me to opravdu po aktualizaci knihoven opravdu ukaze binarky, ktere mam restartovat.