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

30.6.2006 17:15 | Přečteno: 1862× | Python | poslední úprava: 30.6.2006 17:25

Zkusil jsem (v souvislosti se včerejším zápisem do blogu) napsat takovou ptákovinku. Řekněme, že máme při bootu nastartovat služby, které jsou specifikované takto:
services.py

#!/usr/bin/env python
services = {
    'service1':{
        'description':'This is service 1',
        'start':'sleep 1',
        'runs_forever':False,
        'depends_on':[]
    },

    'service2':{
        'description':'This is service 2',
        'start':'sleep 2',
        'runs_forever':True,
        'depends_on':['service1']
    },

    'service3':{
        'description':'This is service 3',
        'start':'sleep 4',
        'runs_forever':True,
        'depends_on':['service2']
    },
    
    'service4':{
        'description':'This is service 4',
        'start':'sleep 8',
        'runs_forever':True,
        'depends_on':['service1', 'service2', 'service3']
    }
}

U každé služby je jméno (service1 až service4), popisek, startovací příkaz, dále příznak 'runs_forever' a závislosti na jiných službách. Ten příznak 'runs_forever' říká, že nemá smysl čekat na ukončení dané služby. Je to například služba sshd, apache, mysql a tak. Jestliže je na takovou službu vázána nějaká závislost jiné služby, pak se nečeká na ukončení, nýbrž na start. Opakem je situace, kdy runs_forever je nepravda. To jsou zpravidla jednorázové akce, u kterých se musí čekat na ukončení (třeba fsck, natahování jaderných modulů, mountování filesystémů atd.).
Závislosti jsou dány seznamem služeb, na které je nutno počkat (než se spustí nebo než skončí). Pro začátek jsem spouštěcí příkazy nastavil na 'sleep něco'.
No a jestliže takto vytvořený soubor importuju do tohoto skriptíku

#!/usr/bin/env python
import threading, subprocess
from services import services

events = {}

class Serv(threading.Thread):
    def __init__(self, services, name):
        events[name] = threading.Event()
        threading.Thread.__init__(self)
        
        self.service = services[name]
        self.name = name

    def run(self):
        print self.name, 'is about to start'
        for name_dep in services[self.name]['depends_on']:
            print self.name, 'is waiting for', name_dep
            events[name_dep].wait()
        print 'starting', self.name
        cmd = self.service['start'].split()
        
        proc = subprocess.Popen(cmd)
        if not self.service['runs_forever']:
            proc.wait()
            print self.name, 'is finished (DONE)'
        else:
            print self.name, 'runs as daemon (DONE)'
        events[self.name].set()

all_serv = [Serv(services, name) for name in services]

for serv in all_serv:
    serv.start()

Tak se začnou dít věci
Proces se rozdělí do vláken, přičemž každé vlákno má na starosti start jedné služby a má k dispozici zamykací mechanismus v podobě instance třídy threading.Event (na začátku je zamčeno). Každé vlákno si před spuštěním služby počká na splnění všech závislostí. Vše se děje "paralelně". Výstup může vypadat třeba takto:

service3 is about to start
service3 is waiting for service2
service2 is about to start
service2 is waiting for service1
service1 is about to start
starting service1
service4 is about to start
service4 is waiting for service1
service1 is finished (DONE)
starting service2
service2 runs as daemon (DONE)
service4 is waiting for service2
service4 is waiting for service3
starting service3
service3 runs as daemon (DONE)
starting service4
service4 runs as daemon (DONE)

Je fakt psina si s tím trochu pohrát. Zvlášť s cyklickými závislostmi V tomto konkrétním případě jsou po ukončení programu spuštěné tři procesy (ale během pár sekund vyhnijí). Takže základní idea byla hotová během pár hodin, takže zbývá ještě asi tak rok práce        

Komentáře

[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)