Co se to spouští?

7.11.2006 20:46 | Přečteno: 1671× | Ze života |

V rámci průběžného testování systému incron mám na počítači trvale spuštěn démon incrond. Tabulka obsahuje pravidla, která monitorují přístup k souborům v adresářích /bin, /sbin, /usr/bin a /usr/sbin. Je zajímavé pozorovat, jaké programy se bezděčně spouští.

Unixovská filosofie, jak známo, říká, že by mělo být mnoho malých jednoúčelových programů. A realita v GNU/Linuxu skutečně vypadá tak, že si mnohé větší aplikace spouští pro své účely spoustu malých prográmků. Je to opravdu správná cesta?

Většinou se v takových případech objevují stále tytéž nástroje. Podívejme se, které programy patří k těm notoricky spouštěným:

• file - program ke zjištění (spíše "odhadu") typu souboru
• id - zjišťuje reálné a efektivní UID a GID
• iconv - převod mezi různými druhy kódování textu
• rm - mazání souborů
• mktemp - vytváření dočasných souborů
• gunzip - rozbalování souborů komprimovaných pomocí GZIP

Podobně často se spouští ještě řada dalších programů. Například u programu file to naprosto chápu - jeho význam je nezpochybnitelný (a nelze ho v podstatě nijak nahradit). Ale čemu nerozumím, je spouštění takových programů, které mají buď své obdoby ve formě knihovních funkcí (např. zmíněný gunzip, iconv apod.), nebo dokonce funkcí ve standardní knihovně GNU C (rm, mktemp a mnohé další). Zvláštní kapitolou jsou programy, které spouští (nebo otvírají ke čtení) samy sebe - některé jen několikrát (např. OpenOffice.org, KEdit), ale některé i mnohokrát (KWrite někdy i víc než 40x).

Nemohu si neklást otázku, proč to tvůrci různých programů (např. man, Midnight Commander, Mozilla, Cinelerra a mnohých jiných) vlastně dělají. Jaké výhody přináší to, že se místo zavolání knihovní funkce spouští samostatný program? Rozumím tomu, když taková funkce neexistuje - pak není nic jednoduššího, než si spustit potřebný program. Chápu také případy, že je třeba knihovna pod licencí nekompatibilní s příslušným programem. Ale ve výše uvedených případech se o nic takového nejedná.

Je důležité o tomto začít hovořit, a to hlavně kvůli problematice výkonu/rychlosti. Spuštění malého prográmku je sice záležitost maximálně stovek milisekund. Jenže to jsou leckdy právě ta malá zpoždění, která dokáží uživatele pořádně otrávit a ten pak říká, jak je ten Linux pomalý. Proto si myslím, že je na čase přezkoumat často používané programy a odstranit z nich spouštění utilit ve všech případech, kdy je takové řešení zbytečné a lze nahradit prostým voláním funkcí. Odměnou za toto nepříliš velké úsilí by bylo celkové zrychlení systému a eliminace části stížností na nízký výkon (které jsou v tomto případě zcela oprávněné).

       

Anketa

Komentáře

[David Watzke]

file má obdobu ve formě funkce, nebo ne (libmagic)?

[Luk]

Asi ano. Jen si nejsem jistý, jestli file nedělá o něco víc než jen analýzu podle souboru magic.

[David Watzke]

To asi ne, Googlem jsem našel: "file is now split (thanks to upstream changes) into libmagic and file (as a tiny wrapper executable around the library)"

[Luk]

Pak by bylo skutečně lepší používat knihovnu (libmagic) i v tomto případě.

[happy barney]

knižnice používať v prípade, že daná funkcionalita je nevyhnutná pre správnu funkčnosť programu.

Príklad: web-browser. Môže fungovať aj bez prítomnosti napr gunzip či libz.

Hranica či áno alebo nie, tá je iná ako 1/0.

[Luk]

Samozřejmě nelze spouštění programů zcela zatracovat, u málo využívaných funkcionalit (bez kterých se aplikace obejde) je to v pořádku.

Ale zrovna ZLIB (libz) je příklad toho, kde je zbytečné něco spouštět externě. Je krajně nepravděpodobné, že by v systému byly konzolové utility, ale nebyla tam příslušná sdílená knihovna.

Navíc (k té robustnosti) - při kompilaci lze zjistit, jaké knihovny jsou k dispozici, a když nejsou, tak se příslušná funkcionalita prostě nezakompiluje. A u binárních distribučních balíků se to dá zajistit pomocí závislostí.

Ale znovu opakuji - jde mi hlavně o ty věci, které jsou ve standardních knihovnách (zejména když jsou POSIX-kompatibilní) a jsou tedy k dispozici všude.

[Kníže Ignor]

This program is the "inotify cron" system. It consist of a daemon and a table manipulator. You can use it a similar way as the regular cron. The difference is that the inotify cron handles filesystem events rather than time periods.

LOL. Bezvadně zvolené jméno

[Luk]

Dobré jitro! Pokud jsi trochu sledoval můj blog, tak víš, že na začátku bylo tohle. Takže to jméno jsem v podstatě nevymýšlel, vzniklo jaksi samo.

[Kníže Ignor]

Dobré jitro!

Přesně to jsem měl namysli.

Ostatně nejdůležitější je, že jste s ním spokojen vy

[Luk]

Vzhledem k tomu, že se nejedná o program pro BFU, je tento název velice logický. Asi stejně, jako je logický sám název inotify

[Ladicek]

Rozhodně by se měly vždycky používat knihovní funkce. Pokud neexistují, pak je to chyba návrhu. Přijde mi jako pěkná zhůvěřilost pouštět kvůli nějaké elementární činnosti jiný program a nedej bože pak ještě parsovat jeho výstup.

[wake]

no, zrovna u OOo jde o normalni multithreading, afaik.

[Luk]

To je možné, nezkoumal jsem to, beru to jenom podle toho, co se zaznamenalo do logu. Ale těch zhruba 41-45 spuštění/otevření (nelze rozlišit) kwrite je mi pořádnou záhadou. Tím spíš, že se to stane jen někdy.

[deda.jabko]

btw. jake pouzivate jadro a knihovnu pro praci s vlakny? pod linuxthreads by se kazde vlakno opravdu mohlo hlasit jako spusteni sebe sama...

btw. kdyz aplikace spousti sebe sama tak to nebude zase tak hruza, protoze uz jednou v pameti je takze vetsina veci se nebude nacitat a bude bezet v rezimu copyonwrite.

[Luk]

No, protože používám FC 4-6, je to samozřejmě NPTL (a už hezky dlouho). On někdo dnes ještě používá LinuxThreads?

kdyz aplikace spousti sebe sama tak to nebude zase tak hruza, protoze uz jednou v pameti je takze vetsina veci se nebude nacitat a bude bezet v rezimu copyonwrite.

To sice ano, ale mě to zajímá čistě z principu, proč se tak děje.

[deda.jabko]

ale jiste, stabilni debiani a ze jich je! ted delam jeden projekt, ktery hrube vyuziva vlakna a multiprocessing a kdyz jsem to hodil na test na server se sargem nastacil jsem se divit, jak hrube dokaze propadnout vykon diky linuxthreads. ale za mesic dva tu bude stabilni etch (nebo windows vista ;-]) , takze aj tito mohykani skonci....

[cynik]

Ja se jim vubec nedivim, delam to taky:

*) Pri prekladu daneho programu nemusim mit 150 dalsich knihoven prilinkovanych kvuli jedne funkci, nehlede na to, ze funkce mohou byt v ruznych knihovnach, mit jine parametry atd.

*) Vetsina programku typu rm neni jen obalem nejakeho unlinku, ale umi spoustu veci navic, kterych se da sikovne vyuzit a opet jsou vice nezavisle na prostredi kde se spousti.

*) Navic se tak dosahuje velke robustnosti jednak pri chybach a jednak kdyz nevyhovuje standardni utilitka, napiseme si vlastni a dame ji do cesty aby se hledala driv.

Zkoumal jsem efektivitu tohoto zpusobu volani a rozhodne se na rychlosti nebo pameti projevi jen opravdu malo.. pokud tedy jde o externi programy psane v prekladanem jazyku.

[thingie]

První problém lze obejít tím, že si tu knihovnu nahraju programově. Třetí důvod je celkem to samé jako LD_PRELOAD. No, nevím, nepřijde mi volání externích programů jako nějaké velké zlo. Pokud vůbec.

[xvasek]

Moje řeč. Přidal bych, že voláním externího programu je umožněno míchat 32 a 64 bit kód, možná to jde formulovat i obecněji.

Navíc UNIX byl takto stavěný od začátku a IMHO kvůli této "skládačkovitosti" přežil dodnes. Pokud bych chtěl něco optimalizovat na rychlost, tak má smysl používat knihovní funkce, ale jinak ne. Teď jsem třeba dělal v Perlu nějaký import, který probíhá někde v noci a potřeboval jsem pro string data (datumu) v ISO formátu funkci "o den později". Sáhnul jsem po date a je mi úplně šumák, že se volá v průběhu importu asi 1500krát.

[happy barney]

Hint:

use Class::Date qw(date);

my $o_den_pozdeji = date ('2006-11-08 12:03:00') + '1D';

print $o_den_pozdeji, "\n";

[xvasek]

Dík, za tip. Každopádně my $o_den_pozdeji=`date -I -d $date +1 day` je o jeden řádek a půl hodiny hledání knihovny kratší.

[Jakub Hájek]

Když už se to zde řeší, mohu se zeptat jakým způsobem lze ten externí program zavolat například v C? Dík.

[Luk]

Jsou v zásadě dvě možnosti:

1. system()
2. fork + exec* (execve(), execvp(), execle()...)

První způsob je jednodušší - program se spouští přes shell, stačí předat celou příkazovou řádku jako při interaktivním spouštění. Nevýhodou je jednak právě (zbytečné) spouštění shellu, dále zablokování procesu/vlákna do skončení podřízeného procesu, nemožnost rozumné komunikace s procesem atd.

Druhý způsob je složitější. Prostě se "forkne" (duplikuje) proces a pak se (v potomkovi) zavolá některá z funkcí pro spuštění programu. Původní proces běží dál, může buď čekat na skončení potomka (wait(), waitpid() apod.) nebo zatím něco dělat a občas se podívat, jestli potomek neskončil (příp. reagovat na signál SIGCLD). S podřízeným procesem lze komunikovat přes roury nebo jiným způsobem.

[..]

Lehce poopravim pro ty co by si to chteli hledat: SIGCHLD

[Luk]

Ano, moje chyba, častější (a podle POSIXu) je SIGCHLD, ale SIGCLD lze použít též.

[Jakub Hájek]

Díky, už čtu many těch funkcí. Myslím, že už se konečně pustím do patche pro SIM, aby mi nastavoval away messages pomocí fortunky

[Josef Kufner]

3. popen()

Je to ještě hezčí hračka, když je potřeba přečíst výstup nějakého programu (nebo mu něco předhodit).

[Luk]

No jo, na ten jsem úplně zapomněl. Je někde uprostřed mezi prvním a druhým přístupem (snadná komunikace přes rouru a současně jednodušší práce než přes fork a exec).