Názory k článku Inicializace aneb Od Initu k Runitu (3)

Nemáte někdo zkušenosti s runitem na Debianovi? Nechce se mi moc zasahovat do defaultni konfigurace debianiho runitu, ale zarazilo me, ze runit rovnou nenahradil sysvinit jako balík nebo alespon jako init, ale pouze spousti oba inity. Nebylo by lepsi instalovat runit|sysvinit?

No zkusil sem to na notebooku. Jen tak letmo, jelo to, ale nevypinalo mi ho to pri ukonceni a spoustu sluzeb bych musel prepisovat aby se pod tim spousteli a proste by s tim byla spousta nastavovani a odladovani. Nemyslim tedy, ze by to bylo obtizne, ale protoze bylo rychlejsi se apt-em vratit zpet, tak jsme si rekli, dobra, jede to, a ted se vratime zpet a kouknem se na to, az budem mit vice casu.

Kazdopadne kdyz uz to ma debinan v baliccich (sid) a ma to neco spolecneho s DJB, tak to urcite stoji za to to pouzivat, si myslim. (zatim to musim vydrzet s daemontools)

ad PM:Zkousel jsem runit na Debianu. Co se tyce toho, ze to nenahradilo sysvinit, myslim ze v deb jsou 2 balicky, runit a runit-run. Sysvinit jsem ponechal kvuli tomu, ze runit teprve zkousim, ale take kvuli kompatibilite s balicky, ktere instaluji skripty do init.d.

V defaultni konfiguraci runitu mi však vadí to, že se málo drží standardu filesystému. Adresář /etc by měl obsahovat statické soubory aby mohl být / připojen jen pro čtení. A chmod stopit reboot, nebo změny symlinků v /etc/runit/runsvdir mi na ro / nefungují. Ale tyto problémy se dají zásahem do skriptů opravit.

Řešení závislostí tím, že jiná služba musela běžet nějaký pevný čas, ve mě nějak nebudí důvěru. Ano kdyžtak se závislá služba znovu restartuje, ale nějak mi to přijde plýtvání časem CPU, no nic.

Jinak by mě zajímalo, umožnil by runit nějak, aby ve startovací části se paralelně provedly console-tools a nastavení sítě a poté připojení NFS, které by bylo závislé na dokončení nastavení sítě? (tj. paralelismus a závislosti u jednorázových skriptů)

>Adresář /etc by měl obsahovat statické soubory aby mohl být / připojen jen pro čtení.

Ano, to je pravda, tak celý /etc/runit symlinkujte treba do /var :-)

>Řešení závislostí tím, že jiná služba musela běžet >nějaký pevný čas, ve mě nějak nebudí důvěru.

Nemusíte svwaitup používat (já ho mám jen na jednom místě a zbytek vyřeší chaos; nemám problém :-)), ale fakt, že je něco spuštěno dvě sekundy ještě neznamená, že to ve třetí sekundě nespadne. Bohužel tohle asi těžko vyřeší jakákoli jiná metoda.

>Ano kdyžtak se závislá služba znovu restartuje, ale nějak mi to přijde plýtvání časem CPU, no nic.

Napsal jsem proto skript checkrespawn, který po desátém restartu v určitém časovém rozmezí udělá sleep 60. Pak se to zase zkusí znovu.
Asi bych ho zkombinoval se svwaitup a minimálním časem 1 s. Když se to startuje paralelně, stejně rozdíl nepoznáte.

>console-tools a nastavení sítě a poté připojení NFS
Tyhle jednorázové akce nejsou de faco službami v pojetí runitu/daemontools. Přesto je možné udělat službu s názvem "console-tools" a na začátek skriptu run přidat řádek

svc -o `dirname $PWD`

kterým se zaručí, že runsv skript nebude restartovat (zakáže respawn).

Pak na začátek skriptů run všech služeb, které závisejí na console-fonts přidáte

svwaitup console-fonts

Alespoň tak bych to řešil. Nerespawnující skript používám jeden, pojmenoval jsem si tu službu "local".

oprava: toto platí pro daemontools, v runitu je zápis

runsvctrl once `dirname $PWD`

ale pokud máte nainstalované i daemontools, jsou kompatibilní, takže i svc bude fungovat.

>Ano, to je pravda, tak celý /etc/runit symlinkujte treba do /var :-)

Tak nejak to delam, ale zase /etc/runit/runsvdir/all
by zas podle me do toho /etc patrit melo, ale samozrejme vim, ze neni problem si ty adresare prestehovat a zmenit cesty v tech skriptech, ale praci to pridela.

>Nemusíte svwaitup používat (já ho mám jen na jednom místě a zbytek vyřeší chaos; nemám problém :-)), ale fakt, že je něco spuštěno dvě sekundy ještě neznamená, že to ve třetí sekundě nespadne. Bohužel tohle asi těžko vyřeší jakákoli jiná metoda.

Tady bych řekl, že u sysvinitu většinou skript vrátí
řízení (démon se odforkuje do pozadí) až tehdy, když už je vše důležité provedeno (ať už to bylo za 1ms nebo 30s), a mohou být spuštěny závislé služby bez zbytečných restartů zatěžujících CPU.

Taky me napadlo, ze pri vyuziti runitu by se zavislosti mohly trochu resit tim, ze by sluzby po svem startu pridavaly symlinky na zavisle sluzby do adresare runsvdir/runlevel/

Jinak díky za článek a za odpovědi.

Ale runit si asi stejne necham "vedle" sysvinitu :-). Je na něm perfektní, že to jde.

> Tady bych řekl, že u sysvinitu většinou skript vrátí řízení (démon se odforkuje do pozadí) až tehdy, když už je vše důležité provedeno (ať už to bylo za 1ms nebo 30s), a mohou být spuštěny závislé služby bez zbytečných restartů zatěžujících CPU.

To je pravděpodobné, na druhou stranu s tím ale nejde počítat. Chtít po všech programátorech, aby to tak dělali, je nemožné.

Domnívám se, že když se vše spouští paralelně, tak stejně ani sekunda prodlevy nehraje roli, neboť hardisk mi v tu chvíli jede tak naplno, že vůbec nevadí, když se nebude startovat úplně vše naráz, ale třeba jen tři služby.

Právě jsem s tím zkusil laborovat. Přidal jsem náhodně tam tři sekundy, tam čtyři, tam nic. A výsledek? Nepociťuji skoro žádný rozdíl, dokonce je to podle předpokladu snad i rychlejší, protože se nemusí číst z deseti míst najednou. Dvě až tři sekundy zdají se být optimální.

>Taky me napadlo, ze pri vyuziti runitu by se zavislosti mohly trochu resit tim, ze by sluzby po svem startu pridavaly symlinky na zavisle sluzby do adresare runsvdir/runlevel/

Určitě existuje mnoho zlepšení. Je to extrémní programování - proč to implementovat, když to vlastně nikdo nepotřebuje, a v nouzi si vždycky nějak pomůže? :-)
Stejně tak si myslím, že je trochu divné, jak svc se supervise komunikuje (Pape v rámci kompatibility s tím už nic neudělá). svc do roury posílá písmeno, které service přemapuje na signál. Proč se rourou nemůže poslat rovnou číslo signálu?

Určitě by šlo vyjít z daemontools a runitu, poučit se z nedostatků a napsat vše od nuly. Vůbec se divím, že už to někdo neudělal, protože by na to stačil jeden programátor a trocha času (neumím C do té míry, abych se za výsledné dílo nestyděl :-))
A ještě víc se divím, že to neudělalo třeba SuSE, RH,..., jako alternativní balíček k sysvinitu. Jasně že jde o dodržování standardů, ale naproti tomu stojí zvýšení spolehlivosti.

Jinak o LSB si myslím své, například moc nechápu účel adresářů /media a /srv. Snáz pochopím Bernsteinův /command, kde se snaží sloučit /bin a /sbin.

>Jinak o LSB si myslím své, například moc nechápu účel adresářů /media a /srv. Snáz pochopím Bernsteinův /command, kde se snaží sloučit /bin a /sbin.

Doufám, že adresář /srv se neujme, to patří třeba do /var/services, nebo něčeho takového, tvůrci FHS asi potřebovali vykázat činnost. Ale základ (už v Unixech, žádný výmysl horlivých v LSB, nebo FHS) - že vše, co se bez explicitního zásahu admina mění (a musí být připojeno rw), je ve /var, /tmp a /home by se podle mě držet měla.

Co se týče /media, podle mě je to zbytečnost, ale motivace měla být snad ta, že /mnt byl někde sám přípojným bodem, a jinde obsahoval podadresáře jako floppy/, cdrom/, atd. Ale je to nic proti ničemu udělat media->mnt.

/bin a /sbin je dle meho dobre sloucit ala bin/->sbin/, ale kdyby to mělo jiný název, kompatibilita (např. #/bin/sh ve skriptech) by byla v )(.

Podle me, pokud budou sluzby stale psane jen pro sysvinit tak nemelo cenu do deba pridavat runit. Jen nevim jak zajistit podporu obou. deb zavislost sysvinit|runit by se musela resit tak ze se do vsech baliku s init-scripty pridaji ke skriptum sysvinit jeste skripty pro runit a spoustet se budou v zavislosti na nainstalovanem, nebo se vsechny skrypty presunou primo do baliku se sysvinit. prvni me prijde rozumejsi ale toho se asi dlouho nedockame, obzvlast kdyz nektere sluzby neprinutime fungovat na popredi :(