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

Mam takovy pocit, ze na zacatku bylo napsano, ze stavajici system je spatny, protoze (mimojine) potrebuje spoustu ruznych hacku... A pritom autor u daemontools musel pouzit 4 pomocne skripty...
A kdyz jsme u te modularity, proc neni logovani a rotace logu rozdelena do nejmene 5 programu?
Ale jinak proti DJB nic nemam :)

Tyto skripty ale nejsou hacky. Za hack povazuji, kdyz je nutne nejakym zpusobem obejit puvodni funkci programu. Tohle chapu jako rozsireni funkcnosti :-)

V tom pripade jsem na "klasicky" init jeste nikdy nepotreboval zadny hack a to i prestoze jsem mu docela "rozsiroval funkcnost".... :)

DJB ruleZ - pouzivam od nej napriklad webserver publicfile a jsem _naprosto_spokojen_

heh .. pri instalaci qmailu me drobet mrzelo ze tam cpu nejaky daemontools, nejaky ucspi-tcp, nejaky djbdns (a chtel jsem to nekdy v budoucnu nahradit tradicnim init spustenim). Avsak jeste jsem s tim za 3 roky nemel jediny problem, tak jsem to nechal plavat.. ale uz me parkrat napadlo nejaky sluzby nastrkat pod supervise..

hezky clanek, jen bych chtel nastinit dalsi alternativu, muj /sbin/init zacina asi takto:
#!/bin/sh -v
..
a funguje to 5 let bez problemu ;-)

Moc sa do toho nevyznam, ale SuSE ma vo svojom konfiguracnom programe Yast nastroj na spravu runlevelov (skriptov /etc/init.d). Celkom sa mi zda dobry. Pri spustani sluzby spusta aj dalsi sluzby ktore tato sluzba vyzaduje. Po spustani vypise info/log o spustenom demone ..

To je ovšem jen uživatelská nadstavba nad systémem SysV init skriptů, který byl v prvním dílu zkritizován coby naprosto nesmyslný, složitý a nepoužitelný. V dalších dílech sice zjistíme, že DJB varianta s sebou přináší zcela nové problémy, které vyžadují své vlastní berličky a workaroundy. To je navíc okořeněno faktem, že autor odmítá chyby považovat za chyby, takže je k jeho nástrojům třeba armáda dobrovolníků, kteří je doplní do jakž takž prakticky použitelné podoby. Ve výsledku je je pak systém ještě složitější a nepřehlednější než ten, který byl původně za totéž kritizován. Přesto se ale najde dost nadšenců, kteří na DJB-nástroje nedají dopustit.

Děkuji za dobrý vtip k odpolední kávě :-))
Používám daemontools (runit) ke vší spokojenosti už přes půlrok. Můžu napsat "sv restart apache postgresql" třeba stokrát za sebou a nestane se, že by něco zůstalo "viset v paměti".
Mám jeden run skript, který je sdílen skoro všemi službami (kromě mysql). Tento univerzální skript nasourcuje nezbytné údaje ze souborů, takže abych nastartoval apache, nepotřebuji celý init.d ani apachectl balast, ale stačí mi soubor:

EXE=/usr/sbin/apache2
OPTIONS="-D NO_DETACH -D SSL -D PHP4 -D RUBY"
MAX_FILES=1200
MAX_PROCESSES=1200

a vsftpd se od toho liší:

EXE=/usr/sbin/vsftpd
MAX_FILES=100
MAX_PROCESSES=100

atd.

Souhlasím s Vámi v tom, že DJB je v mnoha ohledech příliš radikální, a nepovažuji ho za nedotknutelnou modlu, viz závěr článku.
Je skvělé, že v Linuxu existuje možnost volby. Zvolil jsem pro mne jednodušší a efektivnější způsob, byť za cenu menších počátečních nesnází, než jsem zjistil, kde má která služba binárku a jak docílit, aby se nedetachovala ;-)

A btw: v systému mi běží tři bashoví daemoni. Kdybych měl pro ně psát init.d skript a řešit jejich detachování, děkuju nechci; s daemontools je to hračka :-)

"Detachovat shell skript"? Na to snad staci:

nohup /path/script >/dev/null 2>&1 &

Nebo se mylim?

>Podle mého názoru je běžný inicializační systém <br>
>přesložitělý. Člověk se utápí v záplavě skriptů,<br>
>které v zájmu co největší podobnosti s MS Windows<br>
>obsahují konstrukce typu "zde zapni splashscreen,<br>
>když je proměnná a rovna b a zároveň existuje soubor >/a/b/c a xz | grep gh | sed klmn...".

Tak toto tedy povazuju za VELICE ODVAZNE tvrzeni.Nechcete "podobnost" s MS Windows ? Neni nic snazsiho nez prislusne scripty vyradit (!!).
Klasicky system rc scriptu je STANDARD a z toho je treba vychazet. Ja sice chvalim snahy o nekonvencni reseni, ale obavam se, ze v tomto pripade by s tim bylo vice problemu nez uzitku.Mozna se ale trochu mylim - jsem totiz velmi konzervativni a vzdy uprednostnim klasicke reseni pred experimenty :-)
Co vidim jako velky problem klasickeho reseni - rychlost startu systemu - to priznavam, je nekdy docela vopruz cekat nez treba nabehne SuSE.

A je to problém klasického řešení, nebo konkrétní distribuce? Takový Debian přece používá tentýž init a rychlost startu má přitom velmi uspokojivou. Přiznávám, SuSE jsem viděl naposledy někdy předloni...

Nejsem Debianista, ale u Redhatu ci Fedory bych rekl, ze je to zhruba stejne. Zalezi samozrejme take na tom, kolik a jake sluzby startujete a co povazujete subjektivne za pomale.Pro me je treba etalonem start Windows 2000 - ne ze bych je pouzival kdyz nemusim, ale kdyz ziskavam nekoho treba Pro SuSE Linux na desktopu, byva toto jedna z prvnich otazek - "proc to startuje tak pomalu ?" :-)..Koneckoncu je to asi problem i u komercnich Unixu - tam to ale temer nevadi, protoze ty jedou hlavne na serverech a ty clovek startuje malokdy.

No, já už taky nejsem debianista, stal se ze mně genooista. ;-) Nicméně dovolím si zkopírovat úryvek z článku na http://www.root.cz/clanek/2250:

============================
Na závěr malé subjektivní porovnání doby startu systémů po instalaci na stejném HW. Do konzole Debian testing startuje 22 s, FC2 cca 60 s (do Xek s rhgb je schopna FC2 startovat více než dvojnásobnou dobu - přes 120 s).
============================

Takže asi tak...

Odkaz má samozřejmě být http://www.root.cz/clanek/2250, dvojtečku si to tam přibralo jaksi navíc.

>Neni nic snazsiho nez prislusne scripty vyradit (!!).

Až nebudu mít za dlouhých zimních večerů co dělat, možná se do toho pustím; zkusím pochopit všechny rc skripty a otestovat, zda i po úpravě fungují, jinými slovy ztrávím celý den rebootováním :-)
Snažil jsem se zjednodušit /sbin/rc v Gentoo, které je, myslím, stále ještě "čisté". Nakonec jsem to vzdal a počáteční fázi inicializace nechávám na něm, jen služby startuji s daemontools.

Mozna stoji za to zkusit Monit (www.tildeslash.com/monit) - oproti daemontools nabizi vice moznosti a konfigurace je celkem jednoducha.

Jedna se o otevreny stale se rozvijejici projekt, stal se uz soucasti rady distribuci (vcetne napr. Suse ;)

Nasledujici dil ma byt o runitu, na monit se podivam a pokud bude k veci, urcite ho prizpusobim. Diky za tip!

Uz podle prvnich vet je jasne, ze monit nesupervizuje procesy, ale vyuziva jejich pid souboru. Vybrano z FAQ:

1. Q: Monit watches processes by a pid file, so if a program crashes without removing its pid file, then monit won't recognize it, right?
A: Monit will always check that a pid in a pid file belongs to a
*running* process.
Dodavam: Jak monit pozna, ze proces tohoto pid je stejny jako puvodni? Co kdyz program spadl a mezitim byl spusten proces se stejnym pid?

2. Q: I have a program that does not create its own pid file. Since monit requires all programs to have a pid file, what do I do?
A: Create a wrapper script and have the script ...
Dodavam: To je presne ten pripad mysql, kdy to nebude fungovat, protoze prvni mysql proces, ktery je rodicem ostatnich nebyva tim, ktery vypina mysql. Mozna uz se to zmenilo, ale toto chovani neni jednoznacne.

Jinymi slovy, monit je neco jako nadstavba init.d skriptu, ale neresi to, co resi daemontools, protoze je zde onen zakladni rozdil - daemontools nepousteji sluzby na pozadi.

Monit resi, ze kdyz sluzba prestane byt dostupna, zrestartuje ji. Hmm. Ale proc by to mel resit init system? Na tohle mam vlastni VELMI jednoduchy checkalive skript napsany v Ruby, cca tricet radku, ktery se zkousi zalogovat na ftp a stahnout odsud soubor, stahnout stranku pres http a vylistovat mysql tabulku. Spoustim ho kazdou minutu z cronu. Ale neni problem skript obalit nekonecnou smyckou, a udelat z nej udelat daemona + spoustet ho daemontools a testovat to i v kratsich intervalech.

A o tom je prave DJBware - neresit neco programem, kdyz to jde jednoduse vyresit v "userspace" pomoci primitivnich skriptu.

ad. 1) pokud proces umre a opet se nastartuje se stejnym pid (coz je malo pravdepodobne vzhledem k tomu ze pid se pro nove procesy roste) v okne kratsim nez je sonda schopna zjistit, nemusi to znamenat nutne problem - pokud by proces po takovem restartu nefungoval , sonda to stejne zjistit a provede akci, pokud by fungoval, neni treba nic podnikat.

Vyuziti pid ma take nektere vyhody - umoznuje to zacit monitorovat jiz bezici proces (sluzba nemusi byt nastartovana pod kontrolou monitu).

Souhlasim ze pro nektere ucely se zavislost na pid nehodi - jedna z planovanych vlastnosti monitu je rozsireni o moznost kontroly procesu bez zavislosti na pidfile(shodou okolnosti na toto tema probehla nedavno na mailinglistu monitu diskuze).

Ve srovnani se skripty je to dle meho nazoru mnohem kompaktnejsi reseni - umoznuje sledovat u procesu vyuziti CPU, pameti, podporuje zavislosti mezi monitorovanymi sluzbami, umoznuje sledovat obsazeni disku, vlastnosti souboru, adresaru a vzdalenych hostitelu/sluzeb. Stav je mozne sledovat a procesy/sluzby ovladat pres webove rozhranni. Skripty to jde samozrejme take, toto je ale hotove reseni, rudiz to da mene prace a vzhledem k tomu ze je monit psan v C je ve srovnani se skripty take mene narocny. Je toho pomerne dost, asi nema cenu to rezebirat, kdo ma chut, necht si to zkusi ...

Uvedl jse monit jenom jako alternativu - netvrdim ze monit je jedine reseni, kazdemu muze vyhovovat neco jineho ;)

v qmail uz bol ;-)

"Je mnoho lidí, kteří si uvědomují, že na špatných základech nejde vystavět spolehlivý systém. Jde, ale za cenu obrovského úsilí a vloženého času. Jedním z těchto lidí je Daniel J. Bernstein."

Nezda se to nekomu slohove ponekud hmm...neucesane?

Většina návštěvníků této stránky se asi jazykem moc nezabývá :-)

taky muze byt problem s tim, ze drtiva vetsina balicku obsahuje i svoje startup skripty, takhle bych to musel pri kazdy instalaci/updatu porad upravovat? a navic, kdyz k takto upravenymu systemu prijde jiny clovek, bude zmateny, /etc/rc.d/ znaji vsichni. takze i z techto duvodu bych se spis snazil drzet zazitych "standardu"

Ne, daemontools /etc/init.d ignoruji. Run skript se nachazi mimo /etc/init.d. Protoze vetsina sluzeb ma sve binarky porad na stejnych mistech (/usr/sbin), nemam s updaty zadny problem. Staci udelat prvni run skript a od te doby to bude fungovat.
Co se tyce jinych lidi, samozrejme je nutne zdokumentovat, jak system pouzivat. Osobne si ale myslim, ze "sv start apache" pochopi kazdy :-)

Není špatný se taky mrknout na LFS (http://www.linuxfromscratch.org). Ten používá sysvinit taky s kupou skriptů, ale ty jsou poměrně jednoduchý. Woknům se to nepodobá naprosto v ničem. A proč zmiňuju LFS? Protože aspoň jednou nainstalovat Linux ze zdrojových textů nikomu neuškodí. Přitom k tomu není potřeba mít kdovíjaké znalosti, stačí většinou postupovat podle návodu. A ten se věnuje samozřejmě i náběhu systému (pomocí již zminěného sysvinitu).

ruzne veci jsou velmi prijemne na praci. djbware, linux a bsd pouzivam a nemenil bych. jenom je skoda, ze jejich popularizace se skoro vzdycky ujme nekriticky a ponekud nedovzdelany fanatik.

Ja teda neviem, ale mne gentoo nabehne ovela rychlejsie ako W2000. Samozrejme zavisi to od poctu spustanych sluzieb. Ale aj keby som vo win spustal milion veci (spomenme napr. len antivirus) tak to velmi pekne predlzi start. Takze co sa tyka rychlosti, nemaju sa rc skripty za co hanbit.
Mimochodom prave w2000 startuje pekelne dlho.
U XPciek si zatial uvarim caj kym sa vypnu ...

no tak ted se musim teda XPcek zastat, protoze aspon co se tyce startu, tak najedou velmi rychle (a to pominu fakt super featurku jakou je hibernace), w2k jsou pomalejsi, linux, bohuzel, startuje z tech tri nejpomaleji, a pokud by to melo byt treba s KDE, tak to si fakt muzu jit postavit na ten caj, a proto pouzivam fvwm2 (Celeron-M 450, 128MB)

ano XP startuju rychlo. Je to zrejme preto, ze nemaju startovacie SKRIPTY ale BINARKY. Aj okenny system je vo windowse rychlejsi. Ide vsak o to, ci chcete rychlost alebo modularitu. Ak chcete rychlost, pouzivajte windows.
Ked napr. moj brat robi vo windowse, tak ja uz z druheho pocitaca jeho vykon nevyuzijem, hoci brat na nom iba chatuje. Ked tam ma linux mozem sa vzdialene prihlasit a vyuzivat jeho vykon tiez.
A ci startuje o minutu rychlejsie alebo pomalsie mi je uplne ......,dolezite je ze ten pocitac mozeme potom pouzivat obaja, co v super rychlom windowse sa mi moze len snivat.
Mimochodom UNIXy neboli stavane na to, aby ich startovali 5x denne.

jen jsem reagoval na poznamku, ze win starujou proti linuxu dlouho, ja mam totiz opacny poznatek
vubec se nehadam proc to tak je, pouze konstatuju.
btw, diky terminal services je moznost mit i ve win vzdaleny desktop pro spousteni aplikaci ;-)

Linux startuje dlouho, když ho blbě nainstalujete. (Třeba když se zapnou všechny služby, který lze z CD nainstalovat :-) Hlavní je, že je možný dát ty služby v Linuxu pryč, ale to u woken jde dost těžko (a tím nechci říci, že to nelze zvládnout). M$ totiž připravil uživatelům do cesty moc a moc překážek (třeba divnou dokumentaci). Wokna se obvykle pouští rychle (zejména XP), ale jsou citlivý na ovladače (stalo se mi s jedním UDMA/100 řadičem Kouwell, že se ty wokna pouštěly snad 5 minut, ale nový ovladače to spravily). Když jedou pomalu, nejde s tím moc dělat, ale s linuxem jo - a to je hlavní. Navíc se schopnost woken fungovat liší počítač od počítače, a to i u dvou PC s totožnou konfigurací :-).

Hm, ano terminal services alebo take daco. Prvy problem - musim to zase niekde zhanat. Vo windowse totiz musim vsetko zhanat. Druhy problem - uz som sa dostal do windowsu, ale nemam tam kompilator, qt kniznicu, poriadny editor.... A snad len nechcem kradnute visualC alebo Cbuider. Ano mozem pouzit cygwin. A co dalsie kniznice (xxxSQL, xml ...)? Vsetko aby som zhanal po internete. Kym to cele dam dohromady aby to fungovalo, zatial si napisem dalsiu distribuciu.