Init skripty v Pythonu (nesmělé krůčky) (diskuse)

[Michal Vyskočil]

Thready v Pythonu jsem nějak přestal sledovat, ale jak je na tom teď? Pokud si pamatuji, tak tam byl zámek interpreteru.

[Jan Martinek]

No, našel jsem kolem toho v několika diskusích nějaké rozbroje, ale přiznám se, že jsem z toho moc moudrý nebyl.
Většinou se hašteřili, co je bug a co je feature.

[David Watzke]

Může mi někdo prosím vysvětlit jaký to bude mít výhody oproti stávajícím initskriptům? (No offense!)

[Michal Kubeček]

To navazuje na předchozí diskuse: první a druhá.

[David Watzke]

No nevím, znám jen Gentoo a tam máme init skripty třeba takový (vixie-cron):

depend() {
        use clock logger
        need localmount
        provide cron
}

start() {
        ebegin "Starting vixie-cron"
        start-stop-daemon --start --quiet --exec /usr/sbin/cron
        eend $?
}

stop() {
        ebegin "Stopping vixie-cron"
        start-stop-daemon --stop --quiet --pidfile /var/run/cron.pid
        eend $?
}

a myslím, že to o moc líp ani nejde. Paralelní spouštění? Není problém, RC_PARALLEL_STARTUP="yes". Nepřehledný? Neřekl bych. V Pythonu by to bylo rychlejší? Těžko, když:

amd64 ~ # time python -c exit # a to není první "start", ale druhý!

real    0m0.052s
user    0m0.013s
sys     0m0.002s

amd64 ~ # time bash -c exit

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

a spustit musí v podstatě totéž...

[Martin]

No, to je sice všechno možný, ale je něco špatnýho na tom, pohrát si s init skriptama v Pythonu? Vy lidi děláte, jak kdyby vás to pak měl někdo nutit používat ;o)

[David Watzke]

Co? Psal jsem něco o tom, že je to špatný? Ptám se na výhody! Vy lidi děláte, jak kdybyste ty komentáře vůbec nečetli

[happy barney]

nechaj ich tiez si myslim, ze riesia <>vinu, bud na to prijdu sami, alebo vymyslia nieco uzitocne )

[Martin]

Nepsal, jenom mám z některých komentářů k tomuhle tématu pocit, jakoby si někteří mysleli, že když je podle nich něco zbytečný, tak nemá smysl se tím vůbec zabývat. I kdyby jenom ze zvědavosti.

Vy lidi berete všechno strašně doslova ;o)

[Michal Kubeček]

Ale o tom už se tady dlouze debatovalo. Někteří si myslí, že to bude výrazný přínos, někteří že ne. Já patřím mezi ty druhé, tak si prostě počkám, jestli z toho něco bude a jestli jsem měl pravdu.

[Daniel Kvasnička ml.]

Co se tyka porovnavani startu interpretu, to uz se resilo v minulym threadu, takhle to porovnavat nemuzes, je tam plno dalsich faktoru. Python nic dalsiho nespousti a zustava v pameti, nesaha tolik na disk atd...pokud si pamatuju.

[Jan Martinek]

No nevím, znám jen Gentoo a tam máme init skripty třeba takový (vixie-cron):

Takhle to vypadá pěkně. Ale když se člověk trochu podívá pod pokličku, tak už to taková radost být nemusí.

a myslím, že to o moc líp ani nejde.

Všechno jde zlepšit! Nebo taky pokazit ...

Paralelní spouštění? Není problém

No, ve Fedoře to zatím problém je. Proto jsem se do toho pustil.

V Pythonu by to bylo rychlejší? Těžko, když:

amd64 ~ # time python -c exit # a to není první "start", ale druhý!
real    0m0.052s
amd64 ~ # time bash -c exit
real    0m0.003s

Ech, takových benchmarků už jsem viděl ...
Jak si je mám přebrat? Že bash dokáže nad Pythonem zvítězit o úctyhodných padesát milisekund? Nebo že Bash neudělá nic sedmnáctkrát rychleji než Python?
A vůbec - nijak se netajím tím, že si chci především pohrát, pochopit jak funguje bootovací proces, naučit se v Pythonu a zrychlit nabíhání počítače zejména tím, že hromadu věcí zjednoduším, odstraním (a pravděpodobně i znefunkčním, hehe). A jestli bude můj výplod používat všeho všudy pět lidí, tak si budu gratulovat.
A Python s Bashem nehodlám dále srovnávat - myslím, že vše již bylo řečeno. Jestliže se někdo domnívá, že Bash je rychlejší, tak mu to už vyvracet nebudu. Ale ten dotyčný si ke své škodě lže do kapsy.

[David Watzke]

No, ve Fedoře to zatím problém je. Proto jsem se do toho pustil.

Aha

A Python s Bashem nehodlám dále srovnávat - myslím, že vše již bylo řečeno. Jestliže se někdo domnívá, že Bash je rychlejší, tak mu to už vyvracet nebudu. Ale ten dotyčný si ke své škodě lže do kapsy.

Ne, to netvrdím... tvrdím, že Python i Bash spustí externí prográmky stejně rychle a o ty jde především.

Teď mě napadlo, že by ty init-skripty mohly být v C, to by to nabootovalo ještě rychleji

[Michal Vyskočil]

Teď mě napadlo, že by ty init-skripty mohly být v C, to by to nabootovalo ještě rychleji

Tím chceš říct, že ještě nemáš na Gentoo Init-NG?

[David Watzke]

Chci. Na druhej pokus to sice už spustilo KDE, ale furt tam nějak failovala síť a já na to neměl náladu.

[python2]

V Pythonu by to bylo rychlejší? Těžko, když:

amd64 ~ # time python -c exit # a to není první "start", ale druhý!

real    0m0.052s
user    0m0.013s
sys     0m0.002s

amd64 ~ # time bash -c exit

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

a spustit musí v podstatě totéž... 

Omyl, Python se spouští jednou, bash cca 200-500x. To už je rozdíl, že? Python skripty budou kompilované a nebudou se muset opakovaně znova a znova parsovat. Běh programu v Pythonu je mnohem rychlejší než v Bashi. Z bash scriptů se nepočítaněkrát spouští další procesy typu sed, u pythonu to jede v rámci binárky. Udělejte si skript, kde se stokrát vyhodnocuje regulární výraz, jednou v bashi+sedu jednou v pythonu a hoďte sem výsledek, pak se pobavíme, co je rychlejší.

[David Watzke]

Dík, tohle jsem chtěl slyšet.

[Kníže Ignor]

Python je moc vobyč. Až to někdo přepíše do Shakespeara, tak mi dejte vědět.

[Dunric]

Najdou se i takoví milovníci Pythonu, kteří v něm píší rovnou celý operační systém

[happy barney]

technicke poznamky:
- ako chcete zabranit, aby sa thready neovplyvnovali (fork je fork)?
- ako to bude fungovat napr nie pre "sleep 1", ale pre "apachectl start" (pricom samozrejme vyzadujem, aby sa sluzba restartla po pripadnom pad, okrem situacie, ked ju rucne zhodim?

ad zavislosti, mozno by neskodilo definovat, co ta ktora sluzba ovplyvnuje. Myslim, ze by stacilo definovat, ci ovplyvnuje nastavenie systemu (napr "network") a najprv spustit vsetky ovplyvnujuce a potom neovplyvnujuce. Napr (moj oblubeny) ntpd nastavenie ovplyvnuje, ale vyzaduje funkcnu siet, ale napr sshd ci apache nan nepotrebuju explicitnu zavislost. Takych moze byt viac, specifickych pre ten ktory stroj.

[Jan Martinek]

technicke poznamky:
- ako chcete zabranit, aby sa thready neovplyvnovali (fork je fork)?

Já ve skutečnosti potřebuju, aby se thready ovlivňovaly. Ale musí to být kontrolovaně, jinak se z toho stane splašené stádo. K tomu účelu existuje řada synchronizačních mechanismů. V Pythonu je přímá podpora zámků, reentrantních zámků, podmínkových objektů, semaforů a událostí. Já jsem použil ty události.
Fork se pro tuto situaci nehodí, protože při něm vznikne nový proces a pak už bych velmi těžko měnil jeho běh a chování a zjišťoval z něj různé informace. Komunikace mezi procesy je vždy dost těžkopádná.

- ako to bude fungovat napr nie pre "sleep 1", ale pre "apachectl start" (pricom samozrejme vyzadujem, aby sa sluzba restartla po pripadnom pad, okrem situacie, ked ju rucne zhodim?

Apachectl hodlám přepsat, protože se mi nelíbí
Ale k věci - v nastartování apache nevidím problém, je to démon jako každý jiný. A když spadne? Automatické restarty vyžadují, aby celý startovací proces zůstal napořád běžet jako démon. Ne každému to tak vyhovuje, takže si ještě rozmyslím, jak to udělat.

ad zavislosti, mozno by neskodilo definovat, co ta ktora sluzba ovplyvnuje. Myslim, ze by stacilo definovat, ci ovplyvnuje nastavenie systemu (napr "network") a najprv spustit vsetky ovplyvnujuce a potom neovplyvnujuce. Napr (moj oblubeny) ntpd nastavenie ovplyvnuje, ale vyzaduje funkcnu siet, ale napr sshd ci apache nan nepotrebuju explicitnu zavislost. Takych moze byt viac, specifickych pre ten ktory stroj.

Jojo, taky myslím, že je to rozumná věc, bez které by to byla hrůza. Jinak by se u všech služeb musela explicitně psát závislost např. na fsck, raidu apod. a jistě by se na něco zapomnělo.
Nebude však problém tyto "samozřejmosti" shrnout pod jednu fiktivní službu (nebude mít definovaný příkaz ke spouštění), která bude záviset na všech běžných věcech, zatímco všechny ostatní se už mohou v závislostech odkazovat jen na ni.

[happy barney]

aha, takze ak bude uzivatel chciet miesto apache pouzivat iny http daemon, bude musiet pockat, az k nemu niekto (vy) napise vas plugin miesto spustenia skriptu dodaneho s produktom?

odporucam vam rozmyslat o 0..n v odpovedi na nasledovne:
- kolko je distribucii ?
- kolko je sposobov nasadenia ?
- kolko produktov poskytuje dany typ sluzby ?
- kolko instancii sluzby je mozne spustit ?
- kolko produktov bude na cielovom stroji nainstalovanych ?

dobre by bolo zobrat vsetky existujuce daemony (freshmeat.net pomoze), popisat si ich zavislosti, nakreslit si ich postupnost a potom si uvedomit, ze lubovolna cast moze byt (dokoncia viac krat), ale i nemusi

otazka navyse nesmerovala priamo k apachectl, ale k sposobu, ako mienite "kontrolovat" proces, od ktoreho nedostanete SIGCHLD.

[python2]

Tak jsem se zamyslel a došel k závěru, že se měl zamyslet už kdysi linus a vůbec s linuxem nezačínat, bylo přece předem jasné, že nemá šanci .

[Jan Martinek]

Myslím, že netřeba situaci zbytečně dramatizovat. Kdyby na tom někdo trval, tak si může startovací příkaz nastavit na '/etc/init.d/httpd start' a nic se pro něj nezmění (kromě paralelního spouštění). Počáteční testovací verze budou s největší pravděpodobností fungovat právě takto.

odporucam vam rozmyslat o 0..n v odpovedi na nasledovne:
- kolko je distribucii ?
- kolko je sposobov nasadenia ?
- kolko produktov poskytuje dany typ sluzby ?
- kolko instancii sluzby je mozne spustit ?
- kolko produktov bude na cielovom stroji nainstalovanych ?

- Distribucí je spousta. Každá to dělá po svém.
- ???
- spousta. Jestliže se někdo rozhodne změnit sendmail na exim, tak deaktivuje jedno a aktivuje druhé. Nevidím problém.
- kolik instancí? Jednu. Kdo jich chce víc, tak to bude muset ručně zařídit úplně stejně jako v jakémkoli jiném systému.
- kolik produktů nainstalovaných? Na disku jich můžete mít kolik chcete. Důležité je, kolik jich bude aktivovaných.

dobre by bolo zobrat vsetky existujuce daemony (freshmeat.net pomoze), popisat si ich zavislosti, nakreslit si ich postupnost a potom si uvedomit, ze lubovolna cast moze byt (dokoncia viac krat), ale i nemusi

Ale no ták ...
Považujete za tak hrozný rozdíl, jestli stanovíte pořadí startování (tak jak je to dosud) nebo závislosti? Jestliže si něco dáte do systému, tak stejně musíte vědět, kdy se to má spouštět. Ty závislosti budou ve skutečnosti celkem jednoduché.

otazka navyse nesmerovala priamo k apachectl, ale k sposobu, ako mienite "kontrolovat" proces, od ktoreho nedostanete SIGCHLD.

Tak teď nevím, o čem mluvíte. apachectl nijak nereaguje na SIGCHLD - je mu to úplně jedno. Co myslíte tím "kontrolováním"? Jestliže nějakého démona pustím přímo, tak se přece snadno dozvím, že skončil. Jestliže ho pustím přes wrapper, tak mám prostě smůlu a musím zjišťovat existenci PIDu nebo se dívat na otevřené porty nebo tak něco.

Nepřipadá vám, že děláte z komára velblouda (alias ťavu)