Přepsání init skriptů do Pythonu

29.6.2006 12:29 | Přečteno: 1837× | Python

Pokusil jsem se zformulovat některé myšlenky v souvislosti s reorganizováním initskriptů. Přejdu rovnou k věci:
Cíl:
-rychlejší boot
-přehlednější startovací skripty
-jasná koncepce
-vytvoření frameworku použitelného pro různé distribuce
-zlepšení diagnostiky (např. která služba spadla)
-možnost uživatelských démonů
-možnost nahrazení cron démona a at démona něčím obecnějším
-přímá integrace síťových (a jiných) profilů
-pokud to závislosti dovolí, login prompt na konzole bude dostupný i když se nějaká služba při bootu zakousne
-bude možné nastartovat Xka buď co nejdříve nebo co nejpozději (zastánci obou táborů si jen pozmění pravidla)

Zásady:
-minimální práce s diskem během bootu (prioritou je však modularita a přehlednost)
-minimální doba čekání (paralelní spouštění služeb)
-centralizované řešení (ale musí zůstat možnost jej zcela obejít)
-je nutné počítat s chybami, přičemž systém musí zůstat ovladatelný

Nutné prostředky:
-nějaký rozumný programovací jazyk (přikláním s k Pythonu)
-dostatek času (ajajaj...)
-znalosti, zkušenosti (takže to můžu rovnou zabalit)
-sehnat dostatečný počet dobrovolníků, vývojářů a testerů (ano, tohle píšu v češtině a dávám do blogu na abclinuxu, ale to je pouze začátek)

Některé vedlejší efekty:
-několik totálně rozhozených systémů
-deprese (spousta práce bez výsledku)
-velké množství klikacích nastavovátek přestane fungovat
-zatracené flamewary (Je to dost kontroverzní téma. Bude to chtít sepsat FAQ.)
-bude potřeba fušovat do řemesla autorům služeb a serverů (což jistě neuvítají)
-vznik či vzkříšení zajímavých modulů do Pythonu (alsa, IPC, práce s běžícími procesy atd.)

Základní představa:
Jádro spustí init, což bude naprosto minimalististický program, který bude mít dvě úlohy:
1) nikdy nespadnout
2) spustit startovací proces (nazvěme ho třeba pytinit)
Startovací proces bude jeden vícevláknový program, který začne spouštět služby. Službou se myslí nějaký spouštěný blok příkazů či programů, který již nemá valný význam dále štěpit. Každá služba bude mít svůj jasný identifikátor (jméno). Služeb bude pravděpodobně o trochu více než dosud. Asi by měl existovat makeraid, fsck, loopback, alsa, mingetty a další. Startovací proces tedy nastartuje vše co bude mít v seznamu, přičemž dá pozor, aby byly vždy splněny patřičné závislosti mezi službami.
Poté se zachová podle jedné ze dvou variant, podle konfigurace. Buď si uloží svůj stav (PIDy procesů atd.) a skončí. Druhá varianta (démonická) je, že zůstane i nadále běžet, otevře si socket a bude na něm poslouchat další povely, co má zastavit, spustit atd. Současně by pak hlídal běh služeb, logoval pády, spouštěl časované události atd.

Závislosti mezi službami:
Každá služba bude schopná zareagovat na tyto akce:
start
stop
a bude o sobě poskytovat tyto pravdivostní hodnoty:
is_running (jestliže běží)
has_finished (jestliže běžela a už skončila)
is_daemon (jestliže má smysl jí posílat akci "stop")
Závislosti budou specifikované pomocí pravidel mezi službami.

Manuální práce se službami
Poté, co systém nastartuje, bude stále možné ručně ovlivnit běh a chování služeb. Syntaxe by mohla vypadat například takto:
service služba start (spustí službu)
service služba stop (zastaví službu)
service služba restart (restartuje službu - pokud to nepodporuje, použije se stop+start)
service služba status (ten je zde kvůli zpětné kompatibilitě - vypíše "Running" nebo "Is not running")
service služba query (vypíše všechny pravdivostní hodnoty, PIDy, závislosti atd.)
service služba deactivate (zabrání, aby se služba aktivovala při bootu)
service služba activate (povolí start služby při bootu)
service služba remove (odstraní službu ze všech pravidel)
service [služba] --add modul.py (přidá službu a automaticky ji zaktivuje)
service [služba] --reload modul.py (znovu nahraje modul se službou)

Systém nesmí dovolit změny, které by vedly k cyklickým závislostem.
Je jasné, že spousta myšlenek je nedotažených. Spoustu věcí jsem taky ještě nepopsal (např. reboot, různé události s UPS atd.) Přesto bych rád znal vaše alternativní návrhy, jak dosáhnout stejných vymezených cílů. Ale hlavní důvod, proč to píšu je ten, že sháním dobrovolníky        

Komentáře

[Martin]

Jak už jsem řekl ve plamenné diskusi pod inkriminovanou novinkou, kdybych na to měl znalosti a zkušenosti, rád bych se přidal. Takhle budu každopádně fandit, držet palce a třeba se připojím s jedním totálně rozhozeným systémem, když bude zájem o nějaký ten testing. Moje knowledge roste den za dnem, tak až se začnou za nějakou blíže nespecifikovanou dobu věci dít, možná už bude na takové jakž takž úrovni, že se budu moct zapojit aktivněji :o)

Ta myšlenka se mi opravdu líbí. A podobná věc mě napadla už kdysi. Ale zůstalo to jenom u toho "napadnutí" :o)

[Jan Martinek]

Díky! Moc dobře si pamatuji, že jsi to řekl, ale nechtěl jsem zbytečně kazit tu uřvanou diskusi nějakými konstruktivními příspěvky
Takže beru tě za slovo. Znalosti a zkušenosti taky nemám, takže co. Minimálně to bude sranda s nejasným koncem

[Martin]

No, já nemám znalosti a zkušenosti prakticky žádné, ale razím heslo, že žádný učený z nebe nespadl ;o)

Určitě by to mohla být velká sranda a příležitost se toho naučit hodně o Linuxu a to i v případě, že bych se na tom případně podílel jenom jako pokusnej králík :o) Už to by za to z mého hlediska stálo.

A Python mám fakt rád. Přeju hodně štěstí. Průběžně informuj, jak se to vyvíjí. Jestli se to teda doopravdy rozjede.

[stativ]

žádný učený z nebe nespadl ;o)

A kdyby ano, tak by se zabil :)

[Kyosuke]

No moment, většina kosmonautů (nebo snad všichni) jsou, pokud vím, vysokoškolští absolventi?

[Martin]

Jenže on nespadne :o)

[stativ]

Prakticky je to tedy to same jako InitNG

[Jan Martinek]

Já vím, koukal jsem se na to (ale nezkoušel). Je to na velmi dobré cestě, ale ... je to napsané v céčku. Nic proti tomu, ale té práce je fakt strašně moc. Už toho mají sice hodně hotového, ale když se tam musí implementovat každá ptákovina, tak je to opravdu peklo. Takže bych vyvojářům přál, aby se jim dařilo, ale sám bych do toho nešel. Stačí se podívat do zdrojáků do adresáře plugins a představit si, jak by se to zjednodušilo ve vysokoúrovňovém jazyce.

[KS]

Taktéž se mi nápad velice líbí, ale potřeboval bych hodně věcí doštudovat, hlavně Python. Možná by se mohl pohledat už existující podobný projekt a dotáhnout ho.

[vlanav]

Existuje projekt m0n0wall (vice na http://m0n0.ch/wall), ktery ma svuj init napsany v PHP a konfiguraci ulozenou v XML souboru. Vubec jsem nestudoval jak to vlastne funguje, takze jde pouze o preklad oficialni informace ze stranek projektu. Ja jsem pouze uzivatelem tohoto skveleho a instantniho firewallu.

[happy barney]

uff, povodne som chcel komentovat bod po bode, ale nakoniec som zistil, ze autor vlastne chce objavit objavene. Takisto, pre slovicka typu "lepsi, rychlejsi" by neskodilo uviest vztazne body, uviest/najst dovody, preco tvrdi, ze nieco "je pomale".

provokacna otazka: ako bude urychleny start apache, ak ho budem spustat z pythonu a nie zo shell-u ?

[Jan Martinek]

Ne, díky, už jsem se kvůli tomu pohádal dost a vystačí mi to na dlouhou dobu dopředu. Hlavní důvod pro zrychlení vidím v paralelním spouštění. Jazyk samotný moc velký vliv nemá. Proto si myslím, že psát to v céčku je zbytečný masochismus. Na druhou stranu, když už to chci přepsat od nuly, tak by byla blbost zůstat u shellu.

[Heron]

To paralelní spouštění se ti taky může hodně prodloužit v případě, že se startuje více služeb součastně, které intenzivně načítají data z disku.

[Jan Martinek]

Kdyby se ukázalo, že nějaké dvě služby startují výrazně rychleji po sobě než současně, tak se tam dá přidat závislost. Ta ničemu dalšímu zavazet nebude. Budu na to pamatovat až při optimalizacích.

[pol128]

Asi myslel to, že sa apache bude spúšťať zároveň s mysql. Nechcem ani vidieť čo to spraví, ak budú na sebe závislé. Nakoniec ale predsa dostaneš prompt, ale keďže sa všetko ešte stále bude spúšťať, tak robiť nebudeš môcť nič. Viď Windows...

[Jan Martinek]

Asi myslel to, že sa apache bude spúšťať zároveň s mysql. Nechcem ani vidieť čo to spraví, ak budú na sebe závislé. Nakoniec ale predsa dostaneš prompt, ale keďže sa všetko ešte stále bude spúšťať, tak robiť nebudeš môcť nič. Viď Windows...

Když budou na sobě dvě služby závislé, tak se současně spustit nemohou. A jestliže dáváte přednost tomu, aby se prompt objevil až když se vše nahodí, tak není problém - závislosti to zařídí.

[happy barney]

aha, vy mate v umysle napisat v pythone program init. No, vela stastia. Prompt (konzolovy) ma na starosti prave tento programcek. Moze mat na starosti i spustanie xdm/gdm/kdm/*dm, to mi vsak pripada neprakticke.

[Jan Martinek]

aha, vy mate v umysle napisat v pythone program init. No, vela stastia. Prompt (konzolovy) ma na starosti prave tento programcek. Moze mat na starosti i spustanie xdm/gdm/kdm/*dm, to mi vsak pripada neprakticke.

Ne, stávající init bych zezačátku nechal plavat a navíc existují alternativy. V něm úzké hrdlo nevidím. Možná, až opravdu nebude nudou co dělat...

[happy barney]

ale kludne sa moze pytat, ak budem vediet (a vsimnem si otazku), odpoviem

[JiK]

to me taky vrta hlavou, ja myslel, ze prodlevy pri bootu jsou diky tem spoustenym programum (a jejich binarky jsou kompilovany z C nebo C++) a ne diky tomu ze je spousti bash, python, nebo trebas jakykoliv jiny shell...

Zajimalo by mne, zda se dosahne aspon 1% uspory casu ci to naopak bude jeste horsi...

[Heron]

Mno, když nějaká služba na něco čeká (třeba na odpověď ze sítě -- typicky ntpd a jeho počáteční synchronizace), tak se mezitím může spouštět jiná služba. Nebo se může "na pozadí" dělat fsck třeba /home partišny a mezitím se může spustit prakticky všechno ostatní.

[happy barney]

fsck na pozadi je pekna vec ... ale co v pripade, ze fsck bezi prave na particiu /var, vam nabehnu (alebo nenabehnu) vsetky sluzby, pid files, log files, atd sa otvoria na / particii (v adresari /var) a az potom sa primountuje fsck-nuty /var.

[msk]

Inymi slovami - zbytocne problemy. Zatial sa mi stalo len par krat, ze mi originalny init nevyhovoval - ked nesiel ntp server, voci ktoremu sa server synchronizoval (cakanie na timeout bez login prompt) a ked neslo dns a ja blbec som mal v konfigurakoch firewallu hostname (cakanie na timeout bez login prompt).

[Heron]

Tohle by bylo v závislostech. Je jasný, že /var bude mít jako závislost snad všechno.

[JiK]

Ano, kdyz budeme sluzby spoustet paralelne, mozna se neco usetri. Nicmene, nejde to i v Bashi? nebude cely (chabe otestovany) system daleko nachylnejsi ke kritickym chybam? A nebudou ty chyby mit zavaznejsi nasledky? Typicky napriklad kolaps aplikace, protoze potrebuje neco co se jeste nespustilo nebo uz zaseklo?

[Heron]

Jde to i v Bashi. Prakticky stačí v init skriptu na řádku, kde se spouští binárka daemona, dát znak '&'.

[Michal Kubeček]

Nemluvě o tom, že většina démonů se tak jako tak prakticky hned po spuštění odforkuje a původně spuštěný proces skončí…

[Heron]

Mno, to bych neřekl. Alespoň ve FC to tak není. Na něco (ntpd, nebo sendmail, když není dobře nastavenej a čeká na timeout DNS) se čeká hooodně dlouho.

[Michal Kubeček]

No, bývalo to dobrým zvykem. Ale časy se mění… S tím sendmailem máte pravdu, typicky s tím byly problémy, pokud nebyl schopen resolvovat vlastní hostname.

[Marián Kyral]

V Gentoo to už je (závislosti a paralelní spouštění služeb). Je to děláno přes shel skripty.

Ale třeba ten nápad s fsck na pozadí by se mi zamlouval.

[Jan Martinek]

Python versus Bash? No, nějak dnes nemám bojovnou náladu
Ale pro Python jasně mluví jeho možnost předkompilovaných modulů, objektový návrh, práce s vlákny (modul thread a threading), zámky, zacházení s datovými strukturami a vůbec hromada nativních vlastností, které _velmi_ usnadňují práci ve srovnání s bashem.

Pak jste zmínil tu náchylnost k chybám. Stávající stav je takový, že kterákoli služba dokáže zablokovat boot systému. Myslím, že nový návrh bude v tomto směru určitě krok k lepšímu. A pro případ, že totálně zhavaruje celý startovací proces zde zůstává možnost změnit runlevel a vrátit se ke starým shellovým initskriptům (není důvod je smazat z disku).

[happy barney]

preco nie python (a ani perl, atd):

- potrebujeme interpreter, ulozeny (aj s kniznicami) na filesysteme / (/usr niektore distribucie mountuju pocas boot-u).

- potrebujem zarucit, ze syntax jazyka (a ani api pouzitych kniznic) sa nezmeni pocas zivota init skriptov. takze potrebuje dva pythony, jeden system (v /bin), druhy pre ostatnych userov (v /usr/bin), dvoje kniznice, systemove (/lib) a uzivatelske (/usr/lib). Zaroven nam to zabezpeci krasne bugy medzi verziami.

[Jan Martinek]

preco nie python (a ani perl, atd):

- potrebujeme interpreter, ulozeny (aj s kniznicami) na filesysteme / (/usr niektore distribucie mountuju pocas boot-u).

Někde na disku ten interpret+příslušenství být musí. A je úplně jedno, jestli je to bash+sed+awk+find+fsck nebo Python+knihovna. Samozřejmě, že je to problém, ale je úplně stejný pro oba přístupy.

- potrebujem zarucit, ze syntax jazyka (a ani api pouzitych kniznic) sa nezmeni pocas zivota init skriptov. takze potrebuje dva pythony, jeden system (v /bin), druhy pre ostatnych userov (v /usr/bin), dvoje kniznice, systemove (/lib) a uzivatelske (/usr/lib). Zaroven nam to zabezpeci krasne bugy medzi verziami.

Totéž potřebujete zaručit i pro Bash a všechny externí programy (a jejich vstupy, výstupy a parametry), které se z něj spouští. V shellu bývá zvykem parsovat textový výstup z programů, přičemž ten nebývá _nikde_ specifikován. Cesty k programům jsou pokaždé jiné. Stačí napsat /sbin/ifconfig a na polovině systémů jsem ztracen. Různá GNU rozšíření také udělají své. Řekl bych, že Python je na tom nesrovnatelně lépe.

[Mikos]

Největší prodlevy zjevně nejsou způsobeny spouštěním samotných programů. Např. Arch Linux umožňuje paralelní spouštění daemonů (člověk si v /etc/rc.cionf nastaví které daemony se mají spouštět na pozadí a v jakém pořadí) a já sem pomocí toho ušetřil cca 10 sekund času (teď mi trvá boot až do KDM asi 31 sekund, dříve trval něco přes 40 sekund.... upozorňuju že mi startuje docela velké množství daemonů, Arch má naštěstí init skripty hodně rychlé ).

Stačí použít program bootchart a člověk může krásně vidět, kde ten boot vázne. Největší prodlevy jsou způsobeny načítáním dat z disku (seekování). Proto taky vznikl project fcache (viz moje nedávná zprávička Fcache - výrazné zrychlení bootu), který pomocí vytvoření diskové cache linearizuje čtení z disku a boot dokáže zrychlit někdy až o několik desítek sekund! V mém případě bych se dostal (podle bootchartu) něco pod 20 sekund (tzn. zlepšení o dalších 10 sekund, to není špatné ). Bohužel fcache zatím podporuje jen ext3 a já používám reiserfs, takže ho prozatím používat nemohu...

[Michal Kubeček]

Svůj názor na vliv overheadu na interpretaci skriptů jsem už řekl (předpokládám, že je naprosto zanedbatelný). Ale rád se nechám usvědčit z omylu. I když, učit se Python jen proto, abych si mohl provést drobnou modifikaci inicializačního skriptu systému, by se mi moc nechtělo…

[Daniel Kvasnička ml.]

Moc se v tomhle nevyznam (i kdyz subjektivne mi to zni pozitivne, ten napad), takze me kdyztak opravte...ale neni ta pomalost bashe nahodou zpusobena tim, ze pri svem behu pouziva (a musi spoustet binarky) dalsich nastroju jako je awk, sed a dalsi, zatimco python by v drtive vetsine zvladal vse sam?

Proste podobny duvod, proc je CGI pomalejsi nez mod_* reseni.

[msk]

Som hlboko presvedseny o tom, ze fakt, ze su init scripty pisane v shelli, nema na rychlost bootu takmer ziadny vplyv. Paralelne spustanie sluzieb teda zatial vidim ako jedinu vyhodu takehoto projektu. Takisto som extremne alergicky na kadejake wrappery typu service, takze centralizacia a nedajboze nejake socketovanie mi pride ako totalny nezmysel. Nehovoriac o tom, ze najrychlejsi boot je respawn a ze bootujem 2x za tyzden.

[Jan Martinek]

Nějaký wrapper vždycky existuje. Může mít různé podoby, ale bez něj se strašně duplikuje kód. Přiznávám, že ve Fedoře stále ještě píšu

/etc/init.d/network restart

a nikoli

service network restart

Ale to sem nepatří. A co se týče centralizace - musí přece existovat _jeden_ proces, který se postará o závislosti. Paralelní spouštění se bez tohoto neobejde. Leda by se příšerně hrkalo s diskem, což nechci.

[Heron]

Mno, myšlenka je to velmi chválihodná. S init skriptíkama jsem si také hrál. Sice nechápu, proč to musí být v pythonu (resp, co nabízí navíc proti bashu), ale proč ne.

Ale jako před každým velkým projektem je dobré si položit jednu otázku: má to vůbec smysl?

Tím chci ríct, že např rychlejší boot by mohl být až jako doplněk, rozhodně bych ho nedával na první místo. (Nebo bootujete každé 3 minuty?)

Pak by bylo dobrý udělat jednotný systém. Např Fedora má na to příkaz service, který nabízí přibližně to, co napsal autor blogu, ale třeba PID a zámky běžících služeb má na starosti initskrip dané služby. Tj. každý daemon to pak má jinde.

minimální práce s diskem během bootu

Tohle moc nechápu, to snad záleží na službách, které se spouští. Samotný PyInit toho stejně moc číst / zapisovat nebude.

-pokud to závislosti dovolí, login prompt na konzole bude dostupný i když se nějaká služba při bootu zakousne

Tomuhle bych dal PRIO=1

Ješte bych přidal runlevely.

[happy barney]

ad PRIO=1
v slackware by malo stacit zmeni /etc/inittab, v riadoku
rc:2345:wait:/etc/rc.d/rc.M
nahradit wait za once

nieco podobne budete mat aj v ostatnych distribuciach

[Heron]

Jdu to testnout.

[happy barney]

tiez som zvedavy
osobne ma ta otazka netrapi, moj priemerny uptime sa pohybuje vysoko nad hodnotou 100 dni

[Michal Vyskočil]

Sice jsem byl nejdřív proti, ale nakonec, proč ne. V podstatě jediným efektem bude to, že taková distribuce nepojede na embedded systémech, ale to by se mohlo s příchodem Parrotu taky vyřešit.

Nemyslel jsi na nějaké cachování konfiguráků? Že to místo do xy souborů hodíš do nějaké velké cache a při změně v nějakém souboru to prostě přegeneruješ?. V podstatě by se na tohle dala použít přímo serializace objektů v Pythonu.

Ze kterého z existujících init systémů by jsi si vzal příklad? Já můžu říct, že se mi asi nejlépe dělalo s Gentoo initem. Adresáře /etc/init.d a /etc/conf.d to byla paráda. Protipólem je potom CentOS se svým /etc/rc a /etc/sysconfig bordelem.

[msk]

Nemyslel jsi na nějaké cachování konfiguráků? Že to místo do xy souborů hodíš do nějaké velké cache a při změně v nějakém souboru to prostě přegeneruješ?
Nieco podobne sa teraz developi na urovni kernelu, nepamatam si, ako sa to vola. Vytvori sa tomu mala partition a tam si to sekvencne pri boote nasype vsetko v takom poradi, v akom to z disku precitalo. Pri dalsom boote sa to sekvencne cita z tej malej partisny a disk zbytocne neseekuje. Ale podla mna je to kravina.

[Mikos]

Jmenuje se to fcache - viz moje zprávička Fcache - výrazné zrychlení bootu. A něco co zrychlí boot až o několik desítek sekund opravdu za kravinu nepovažuju.

[Jan Martinek]

Při bootu to samozřejmě musí všechny ty konfiguráky načíst a tudíž hrkat s diskem. I když se mi to nelíbí, tak s tím nic nenadělám. Ty konfiguráky jsou příliš různorodé, takže jaderný přístup je asi jediná přímá možnost - což rád přenechám jiným

[Heron]

To mi silně připomíná prefetch techniku ve WinXP.

[Kyosuke]

Tohle je aspoň transparentní a mimo filesystém.

[happy barney]

ja osobne by som privital moznost dvojitej konfiguracie: balickovej a systemovej. Upgradnem balicek, zmeni sa mi default nastavenie (vratane pribudnutia novych, pre beh sluzby potrebnych parametrov) a neprepise moje. Priklad s php: ja by som si nastavil register_globals=on a vobec by ma netrapilo, ako sa casom tento parameter meni v balicku.

dalsie co by som uvital, je viacnasobne spustanie sluzby (s roznymi konfiguraciami, samozrejme).Priklad:

rc.httpd --service httpd-php4 start (config: /etc/httpd/httpd-php4.conf)
rc.httpd --service httpd-php5 start (config: /etc/httpd/httpd-php5.conf)

[Mikos]

Init skripty v Pythonu bych sám také uvítal, vzhledem k tomu že mám Python opravdu rád a shell mi příjde ve spoustě případů jako zbytečný přežitek (i když v jiné spoustě případů se zas hodí jakožto nejjednodušší prostředek k porvedení dané práce ).

Ale co se týče paralelního spouštění služeb, tak to všechny lepší distribuce umožňují nativně už teď Používal sem to jak v Gentoo, tak nyní v Arch Linuxu a boot to opravdu dosti výrazně zrychluje.

[Filip Jirsák]

K manuální práci se službami bych přidal ještě reload (znovunačtení konfigurace).

Jinak zajímavý koncept služeb používá také daemontools (od DJB). Umí to udělat službu téměř z čehokoliv, jednoduše se to konfiguruje. Vůbec to neřeší závislosti apod., ale pojetí unixové služby a jak se starat o její běh mi přijde dobře vymyšlené a přitom jednoduché.

[Lukáš Zapletal]

Opravte mne, jestli se mýlím, ale není největším problémem stávajícího řešení to, že se při bootu volá na 30x bash? Python interpret se přeci startuje stejně (pomalu), co na tomto řešení bude lepšího?

Pokud je mi známo, projekty jako init-ng jsou dneska již dosti daleko, myslím, že je to dokonce psané v jazyce C. Nebylo by lepší se třeba soustředit na tohle?

Jsou to jen moje domněnky, nikdy jsem se tím nezabýval, protože mi připadá bootování normálně rychlé Zastávám názor, že Windows XP se stejným počtem služeb, co mám já, nabootuje stejně rychle (když jsou Windows zasviněný, tak i pomaleji).

[Jan Martinek]

Opravte mne, jestli se mýlím, ale není největším problémem stávajícího řešení to, že se při bootu volá na 30x bash? Python interpret se přeci startuje stejně (pomalu), co na tomto řešení bude lepšího?

Mám v úmyslu pouštět interpret pythonu jednou jedinkrát. Není nejmenší důvod pouštět další, když mohu raději spustit další vlákno procesu. Zbytečně bych ztratil kontext. A budu-li chtít spustit další část kódu, tak prostě do stávajícího interpretu nahraju modul předkompilovaný do bajtkódu.

[happy barney]

no, fork tam treba tak ci tak (aby sa zarucilo, ze napr apache.py neovplyvni skor spustena samba.py). A po prvom natiahnuti je bash nacachehovany.

podla mna je najvacsi problem sucasnych rc skriptov ten, ze sa autori (debian/red hat/mandrake) snazia, aby vyzerali co najstrasnejsie.

v kazdom pripade, rychlost inicializacie ovplyvnuje jeden znak ... &

[Heron]

že se při bootu volá na 30x bash?

$time bash -c "exit"

real    0m0.002s
user    0m0.000s
sys     0m0.000s

Řekl bych, že tohle nezdržuje

[Kyosuke]

Bash startuje pomalu? Nikdy jsem si toho moc nevšiml... Zrovna tady vidím spíš marginální výhody...spíš by ten initproces mohl být třeba rovnou hostitelem síťových služeb, exportovat nějaké RPC (samozřejmě nějak zabezpečeně... ^_^), podporovat SNMP a podobné kraviny.

[happy barney]

sietove: ipv4? ipv6? ipv8? ...
rpc: xml-rpc nad https so zavislostami na libxml, libhttp, libssl, ... ?

radsej 100x jeden nastroj, co robi svoju vec, a robi ju poriadne, ako 1 nastroj co robi 100 veci s bugmi

[Mikos]

Jaky ipv8? Ti přeskočilo?

[Kyosuke]

No jen nemysli. Jednoho dne objevíme mnoho dalších vesmírů a co potom?

[Kyosuke]

Jenom gedankenexperiment...

[Jan Martinek]

sietove: ipv4? ipv6? ipv8? ...
rpc: xml-rpc nad https so zavislostami na libxml, libhttp, libssl, ... ?

Kdo se bojí závislostí, nesmí do lesa

radsej 100x jeden nastroj, co robi svoju vec, a robi ju poriadne, ako 1 nastroj co robi 100 veci s bugmi

Tohle je tak nesmyslné a otřepané klišé, že se nad tím už nikdo nezamýšlí. A co když _potřebuju_ udělat 100 různých věcí? Jak mám pospojovat ty jednoúčelové? Pajpou nebo raději funkčním voláním? A co je vlastně ten "nástroj", co dělá svou věc? Je to nějaký hotový program? Nebo knihovna? Nebo programovací jazyk?

[Dunric]

To co považujete za "otřepané klišé" jako dekompoziční princip funguje od věky věků Čím jednodušší mechanismus, tím méně náchylný k chybám a údržbě. Komunikace mezi objekty je pak jen jejich variace.

Já bych naopak považoval za klišé tvrzení, že Unixovská filozofie přežila bez výrazných změn 30 let díky spiknutí vousatých ultrakonzervativních nerdů místo uznání, že prostě obstála v evoluci

[Jan Martinek]

Jasně. Beru zpět svou horkokrevnou reakci a omlouvám se za ni. Jen jsem poněkud ostražitý při přejímání myšlenek, které ve výpočetní technice vznikly před těmi třiceti lety. Není to nic proti ničemu a nechci se o tom hádat.

[Mikos]

To že je init-ng napsaný v C je právě jeho největší nevýhoda Alespoň tedy z mého pohledu...

Mám milionkrát radši Python (nebo třeba i Ruby, které jinak zas tak moc nemusím), než Cčko. A zrovna na init skripty je C navíc naprosto zbytečné a přidělávající práci...

[happy barney]

je rozdiel medzi programom init (to je ten, co ma pid 1) a rc scriptami (vami nazvane init skripty), co su skripty spustajuce sluzby.

[Mikos]

Pokud vím tak init-ng se stará právě o rc skripty. I když možná obsahuje i nějakou obdobu initu? Je to možný, zas moc sem se o něj nezajímal Každopádně náhrad za init je spousta, ale věci okolo rc skriptů bych opravdu v Cčku mít řešeny nechtěl...

[happy barney]

o rc skripty sa stara aj init (old generation), niekto ich predsa spustit musi presnejsie, spusti sa jeden skript (rc.4 napr), a ten spusti dalsie skripty, potrebne/vyzadovane pre initlevel 4.

[stativ]

Je videt, ze jste neposkvrneni initNG .
InitNG pouziva vlastni dosti promakany system init scriptu. Jen pro ukazku asi nejjednodussi (pro nastaveni swapu):

#!/sbin/itype
# This is a i file, used by initng parsed by install_service

service system/swap {
	need = system/initial system/mountfs;
	exec start = /sbin/swapon -a;
	exec stop = /sbin/swapoff -a;
}

Je tu krasne videt, ze ma vyresene i zavislosti na jinych scriptech. Zaroven je to krasny priklad jeho modularity-pro kazdou vec je samostatny initscript.

[Jan Martinek]

Jsem pravděpodobně dost ovlivněný Fedorou, která (ač je to jinak docela fajn distribuce) je ukázkou příšernosti shellových skriptů. Po nabootování (které trvá asi minutu) má nejvyšší číslo procesu 2200, zatímco běžících procesů je 70. Toto jsou údaje, které opravdu nemíním s nikým konfrontovat - každý to bude mít jinak. Ale přece jen to svědčí o tom, jaké postupy se používají při psaní skriptů.

Zdůrazňuji, že si nemyslím, že je shell tak nepoužitelně pomalý, přestože je nechutné, jak musí tahat všechny berličky z disku. I kdyby ty skripty někdo pouze od nuly přepsal, tak se tím dosáhne slušného zlepšení. Jsou tam hrozní kostlivci ve skříni. Jenže když už to psát od nuly, tak Python vidím jako nejlepší volbu. Napsat v Bashi prosté paralelní spouštění věcí je hračka. Ale co to vyřešení závislostí, timeouty, zámky, thready, status, přidávání a odebírání služeb a vše co s tím souvisí? Jak by to asi vypadalo? V shellu by to bylo strašné a naprosto zbytečné násilí.

[happy barney]

najprv oprava ...
jaké postupy se používají při psaní skriptů ve Fedore. (snad sa nemylim v tom "ve")

zavislosti, timeouty, to nech si riesia sluzby samotne
zamky, thready, to v slusnom systeme ani nema co hladat
pridavanie/ubern takze podme na zavislosti, ako si predstavujete riesenie? spolahnut sa na uzivatela alebo ich dynamicky vyratavat?

navrhnite riesenie a ja vam zadam problem na vyriesenie

priklad: ntpd. je jeho spustenie je finalna akcia neblokujuca ine sluzby?

[Jan Martinek]

Fajn. Máme na věci jiný názor a neshodneme se. Svou představu o tom, jaké vidím řešení, jsem popsal v blogu.
Stávající boot je takový, že závislosti mezi službami jsou dány pouze pořadím při spouštění. To bych koneckonců úplně klidně mohl emulovat, takže se tím žádné dveře nezavírají. A nechcete říct, že paralelní spouštění je blbost, že ne?

[happy barney]

Fajn. Máme na věci jiný názor a neshodneme se. Svou představu o tom, jaké vidím řešení, jsem popsal v blogu.

Suhlasim s vasim nazorom ohladne sucasnej situacie, nesuhlasim s vasou vidinou riesenia. Zda sa mi, ze sa prilis zameriavate len na vam zname pouzitie (vasa distribucia/instalacia). Ako som uz pisal, kludne vam na odpoviem na otazky, kludne vas budem kritizovat (dufam ze konstruktivne)

A nechcete říct, že paralelní spouštění je blbost, že ne?

to nie, ale nie je jednoznacne jasne, ktora sluzba (a kedy) je, alebo nie je ta posledna (t.j. ta, ktora sa da spustat paralelne).

[Kyosuke]

Myslel bych, že závislosti budou obecný DAG a tak by s nimi mělo být i zacházeno, ne?

[happy barney]

Zavislosti su prilis komplikovane na management. Treba udrziavat zoznamy "vyzadujem-spustit-skor", napr apache vyzaduje network, a "musi-byt-spustene-skor", napr ntpd, ak je sluzba spustana, musi byt (mala by byt) spustana skor aka napr apache, ale az po network

jednoduchsie riesenie su urovne ... a tie napr vo ferodore su. Mozno by som skor rozmyslal nad sposobom, ako tieto urovne rozsirit (napr stromovo)

[happy barney]

kua, dnes uz druhy preklep ...
vo fedore, samozrejme

[Marián André]

Hm, niečo mi toto odhodlanie pripomenulo. InitNG spomenutý už bol, ja pridám ďalší projekt: runit.

[Josef Kufner]

Nechápu co řešíte. Jediný požadavek, který v podstatě máte je to, aby se login objevil co nejdříve. Tak proč si ho sakra nedáte na začátek?

Udělal jsem na stolním kompu to, že se kdm spustí tak brzo, jak jen je to možné. Naskočej Xka, automaticky se přihlásí, začne nabíhat KDE a na pozadí se dobootuje.

Vždyť je úplně putna, jestli proftpd a apache na desktopu naskočí o 10 sec dřív či později.

[Jan Martinek]

Nechápu co řešíte. Jediný požadavek, který v podstatě máte je to, aby se login objevil co nejdříve. Tak proč si ho sakra nedáte na začátek?

No to jsem opravdu nerad, jestli z těch cílů, které jsem vymezil, vyplynulo pouze toto. Ale nevadí. Nechte to plavat. Z nějakých prapodivných důvodů jsme my dva většinou v opozici, takže z dalšího rozebírání stejně nic konstruktivního nevyplyne.

[Josef Kufner]

A nebyla by to nuda, kdyby spolu všichni souhlasili?

[martink]

http://smarden.org/runit/

Malé, rychlé, spolehlivé, geniální. Je možné to použít i s normálním initem jen na spouštění služeb.

Spoustu řádků initscriptů často zabírají různé kontroly, jako jestli služba už běží, nebo už skončila, jestli existuje soubor s PID apod. Tyhle problémy runit nemá. Třeba můj skript na spouštění sshd vypadá nějak takhle:

#!/bin/sh
exec 2>&1
exec /usr/sbin/sshd -D

runit je spolehlivý a stabilní (pár řádků v C, ideálně slinkovaný s dietlibc...), služby spouští paralelně a řeší závislosti (geniálně jednoduše, viz dokumentace), služby monitoruje a případně restartuje, je možné služby ovládat příkazem sv (např. sv start sshd), ...