Názory k článku
Na démony bez init skriptů

Ahoj Adame, v dnešní době a za dnešních okolností by každý takový nástroj kromě sysv initskriptů zasloužil i srovnání se systemd.

Už Supervisor a sysv jsou navrženy pro různé věci, nepletl bych k tomu systemd.

Jenže systemd je přeci jen tomuto programu blíže, než sys5. Dovolil bych si tvrdit, že systemd může tenhle program zcela nahradit, včetně například automatického restartování a podobně. Umí toho podstatně více, jeho výhoda je, že se jedná o de-facto standard.

Přesně tak.

Systemd je mimojiné i nadmnožinou nástrojů jako inetd a xinetd, navíc poskytuje podobné nástroje nezávisle na typu síťového i lokálního komunikačního kanálu. A když se podíváš na ty INI-like fajly, co máš k článku, tak konfigurace systemd probíhá téměř totožně.

Spíše bych to srovnal s daemontools, které spokojeně používám už dlouho

„Spíše bych to srovnal s daemontools, které spokojeně používám už dlouho“

Vzhledem k zaměření na Linux a ne DJB OS, bych dal přednost srovnáním se standardní součástí systému před alternativní unilitou s mizivým zastoupením.

aptitude install daemontools … a je to standardní součástí stejně jako ve článku zmiňovaný supervisor ;-)

... proto většina mých démonu napsaných C++ dědí třídu ServiceApp, která sama umí zpracovat příkazy "start","stop","r­estart", "run" (foreground), takže aplikace je vlastně init scriptem. Navíc zvládne i spoustu dalších uživatelských příkazů, umí předat démonovi i další parametry na příkazové řádce a pokud něco démon vyplivne na stderr, tak se to přenese volajícímu do konzole (a nikoliv na stderr procesu init).

V tomhle ale Supervisor moc nepomůže.

A když spadne, tak se umí i restartovat? ;)

Ne... programy by neměly padat. Ani démoni. Pokud démon spadne, kontaktujte autora, ať to spraví.

Démoni padaly, padají a padat budou, protože je nevytvářejí kyborgové, nýbrž lidé z masa a kostí a ti dělají chyby. Normální stav je že v OS existuje něco jako správce daemonů, který je spouští, zastavuje, atd. a sleduje jejich stav a pokud si to uživatel přeje, tak je v případě pádu i znovu nahodí. Linux v tomto normální není.

No pozor, odlište pád a výjimku. Jelikož jsem C++ programátor, tak pro mne je výjimka ošetřitelný stav, zatímco pád nikoliv. A pokud démon padá, tak první opravou je na místě pádu udělat test a vyhodit výjimku.

Ano Linux normální není, to je pravda. Samozřejmě, že pro Linux je ta třída implementovaná tak, že démona pustí jako forknutý child, a když ten child skončí, tak ho naforkuje znova. Ale není to žádná výhra, protože takhle může forkovat do nekonečna.

Nehledě na to, že řešit pád restartem zakládá morální hazard. Autor pak většinou nemá motivaci problém řešit... ono se to zrestartuje, takže kde je problém?

>> Normální stav je že v OS existuje něco jako správce daemonů, který je spouští, zastavuje, atd.

Jasně - třeba ve Windows. Tam je to vymyšleno suprově - zatímco když mám nějaký problém s daemonem pod Unixy, tak si ho prostě spustím normálně ručně v terminálu na popředí, zapnu si volby jaké chci a debuguju jako každý jiný proces, na Windows udělám co? Nejspíš na to budu zase muset mít nějaký SuperDuperMicro­softServiceDe­bugger. Hurá.

Ale jinak hlavně, že je to "normální".

Naivko

...a kdyz ho zabije OOM killer, tak taky.

A nebo prikupte pamet.

A vubec!

Když začne řádit OOM Killer, tak je snad lepší restartovat celý stroj. Jaký to má význam, pokud OOM Killer zabije démona, který se následně hned znova spustí, aby jej OOM Killer zase zabil?

Na světě je moc lidí, náhodně některé popravíme...

OOM Killer je big fail linuxu. Kéž by konečně byl linux schopen pořešit swap + kvóty na alokovanou paměť. Už asi chápu, proč naši admini raději strkaj každou službu do virtuálu :-)

> Když začne řádit OOM Killer, tak je snad lepší restartovat celý stroj. Jaký to má význam, pokud OOM Killer zabije démona, který se následně hned znova spustí, aby jej OOM Killer zase zabil?

To má smysl v případech kdy ten démon zblbnul tak že naalokoval neobvykle moc paměti.

> Na světě je moc lidí, náhodně některé popravíme...

OOM Killer rozhodně nefunguje náhodně.

> OOM Killer je big fail linuxu. Kéž by konečně byl linux schopen pořešit swap + kvóty na alokovanou paměť. Už asi chápu, proč naši admini raději strkaj každou službu do virtuálu :-)

Cgroups?

"To má smysl v případech kdy ten démon zblbnul tak že naalokoval neobvykle moc paměti"

V tom případě je to v pořádku, protože to je chyba, která musí být opravena. Ale radši bych, kdyby jádro žravým procesům začalo utahovat limity včas, aby démonovi začali lítat vyjimky OutOfMemoryEx­ception, než že bude sestřelen. Možná opravdu změnit alokační strategii.

Pro memory leaky je nejlepší právě swap. Ty se tam vesele odloží a pak už nikomu nechybí paměť :-)

Nicméně jsem měl s OOM Killerem už zkušenost a to takovou, kdy mi žravý adobe flashplayer vyžral paměť tak, že mi OOM sestřelil Eclipse i s rozdělanou prací. Možná že eclipse zabíral víc paměti, nevím, ale rozhodně to nebylo dobré řešení.

>> Ale radši bych, kdyby jádro žravým procesům začalo utahovat limity včas

A jak by jádro poznalo proces korektně žravý a nekorektně žravý?

Ve Windows to poznám. Linux má holt problém :-D

Jo? A jak?

Třeba hodně pomůže to, že Windows nemá overcommit a autoři aplikací nepoužívají malloc na rezervaci adresového prostoru (fakt blbej nápad). Pak není problém vůbec řešit killování aplikací. Aplikace jednoduše dostane zamítnutý požadavek na další paměť. A jestli se kilne sama, nebo to vyřeší jinak je její problém.

Mimochodem, včera jsem si s tím hrál a na stroji bez swapu jsem vypnul overcommit. Výsledkem bylo, že mi nenaběhne ani Unity, protože si procesy rezervují stovky megabajtů a velice rychle tak vyčerpají volnou paměť, přestože ji nikdy nepoužijí.

Já jsem se ale ptal na něco jiného:

jak by jádro poznalo proces korektně žravý a nekorektně žravý?

No ptáš se nesmyslně, protože pokud není třeba zabíjet procesy kvůli nedostatku paměti, je zbytečný vědět, zda je proces žravý korektně či nekorektně.

Pokud máme v systému procesy, které sežerou většinu paměťi, že ostatní procesy už prakticky nemohou běžet, otázku, zda je to chyba nebo schválně musí zodpovědět člověk... Například nastavením limitů nebo vrácením programu autorovi k opravě.

Řešit to pomocí OOMK je blbost. Jak píšou na těchto stránkách:
¨
http://www.win.tue.nl/~aeb/linux/lk/lk-9.html

"Of course, the very existence of an OOM killer is a bug."

Takže tvoje "ve Windows to poznám" byl nesmysl. Ok.

Ale Linux to umí. Lze vypnout overcommiting (tím se prakticky vypne i OOM killer). Paměť lze omezit přes ulimit. Lze také snížit alokační jednotku nebo změnit alokační strategii mallocu. Akorát by to musel někdo nastavit.

Nejde to, protože autoři aplikací používají malloc pro rezervaci adresového prostoru, což není totéž jako rezervace paměti. Ve Windows se to rozlišuje. Stránky se buď rezervují (RESERVED), nebo commitují (COMMITED). V režimu RESERVED se sice vedou ve stránkovém registru procesu, ale nic v nich není, nelze do nich zapisovat, ani číst, fyzicky neexistují. Jakmile ji aplikace potřebuje, provede na kterékoliv rezervované stránce COMMIT a tím dostane přidělenou paměť. A nebo taky ne, pokud OS nemá kde brát.

Jenže aplikace třeba kolem UNIT po startu zarezervuji stovky megabajtů, které reálně nikdy nepoužijí. Pravděpodobně tedy používají malloc jen pro rezervaci adresového prostoru. Bohužel to operačnímu systému nehlásí, takže ten nemůže tušit, zda zabraná paměť opravdu může být v budoucnu reálně potřebná.

ULimit je fajn, ale neumí nastavovat limit nějak chytře, třeba na základě aktuálního stavu paměti. Třeba bych chtěl, aby limit každé aplikace byl vztažen k aktuálně volné paměti. Třeba pokud si nastavím limit 80%, budu schopen jeden jedním procesem využít celých 80% a dalším procesem 80% ze zbývajících 20%. Ale takovouhle logiku v linuxu nenajdu.

Dál jsem psal o Ubuntu Unity

Unity tu nemám, tak to nemůžu zkoušet. Tipuju, že si spíš vyrobí nějaké mmapy s MAP_NORESERVE (obdoba RESERVED ve Windows, ale s automatickým commitem), což se ale u vypnutého overcommitu ignoruje a stránky se stejně commitují.

Btw. pokud vypnete overcommit, je potřeba ještě poladit overcommit_ratio, protože ve výchozím nastavení aplikace mohou alokovat jenom 50 %. (Pokud nastavíte moc, může se spustit OOM killer, když dojde jaderná paměť nebo cache.)

U toho ratia jsem nepochopil, jestli jde o vuci celku nebo nad celek, tedy jestli 50% neznamená vlastně 150% (tj na 1GB systému lze overcommitnout na 1.5GB).

overcommit_ratio určuje počet procent RAM, která může být zabraná při overcommit_memory nastavené na 2 (overcommit_memory nastavené na 0 používá heuristiku, na 1 povoluje neomezený overcommit), tedy total_commit = swap_size + (ram_size * overcommit_ratio / 100) — stále to neznamená, že ta paměť bude při mallocu či mmapu opravdu zabrána jako ve Windows, může v ní být třeba cache nebo file-backed mmap (oboje lze kdykoliv snadno zahodit). Pokud je overcommit_ratio nastavené pod cca 80 (aby zůstalo dost místa na jádro a buffery), k overcommitu (a tedy na OOM killer) nemůže dojít.

Aha, díky Stene, zkusím si s tím pohrát :-) Škoda, že prostě jádro dopředu nerozezná rezervaci a alokaci paměti. Opravdu netuším, proč si Unity Panel musí rezervovat 350MB paměti a reálně využívat 20MB (čísla z topu)

No, jádro se o to snaží, když je zapnutá heuristika, ale už ze samotného principu alokace paměti není možné mít něco jako nealokovanou zaručenou rezervaci a nezaručená rezervace je (alespoň v Unixu) totožná se žádnou rezervací, takže je celkem zbytečné něco explicitně rezervovat (autoři Unity se asi chtěli vybodnout na kontroly mallocu).

Co se týče těch procent paměti, něco takového lze udělat pomocí systrace, ale otázka je, jak to bude rychlé.

Zdravim,

velmi pekny nastroj, hned by som ho nasadil, ale chyba tomu detail: mysleli autori na podobne elegantnu integraciu do existujuceho /etc/rc.d a podobnych frameworkov?

Niekedy sa prave hodi moznost pridania sa k davu.

To je pravda. Ve FreeBSD je integrace nekterych veci udelana velice jednoduse a pritom funkcnce - jeden init script je nasymlinkovany na ruzne nazvy.

Napr. openvpn se nasymlinkuje na openvpn_x, openvpn_y, ... a pomoci tech symlinku se potom ovladaji ruzne instance openvpn.

Tohle by Supervizoru taky sluselo.

P.S. mne osobne by se libilo, kdyby takhle bylo mozny ovladat vsechny kontrolovane procesy - bylo by to pro me lepsi nez nejaka silenost s RPC...

Opytam sa inac:

Kto startuje Supervisor?

:-)

Ve Fedoře (přes systemd) je na to normální rc.skript. Jinak řečeno, spouští se normálními prostředky běžnými pro danou distribuci. A pokud by vám to připadalo jako moc slepicovejčí problém, pak určitě půjde něco ve stylu init=supervisord :-)

Himbajs, čtu to po sobě a stějně nechám překlep: přes systemd->před systemd

Kdyz tam jsou ty priority, znamena to, ze se nedaji definovat zavislosti sluzeb (sluzba A vyzaduje, aby bezela sluzba B)?

Jestli je to tak, tak to je docela limitace...

ja ho pouzil pro svoje skripty. Potreboval jsem, abych mel na nejakym TCP portu vystup z shellu, z jinyho serveru netcatem dostupny (pro mrtg) . Je ale pravda, ze je zbytecny zabirat socket, kdyz neni potreba.
Chose.

Monit umi to same, ale navic kontroluje nejenom jestli proces bezi, ale jestli taky dela to co ma (reaguje na sitove requesty), nezere moc CPU (napr. zacykleni) ani pameti (napr. memory leak).

Napr. konfigurace pro Apache, ktera restartuje apache pokud spadne, kontroluje zda odpovida na requesty, kontroluje vyuziti CPU a pameti:

check process apache with pidfile /var/run/httpd.pid
start program = "/etc/init.d/httpd start"
stop program = "/etc/init.d/httpd stop"
if failed port 80 protocol http then restart # testovani http://127.0.0.1:80
if totalcpu usage > 75% then alert # soucet cpu usage vsech apache children
if totalmemory > 75% then alert # soucet memory usage vsech apache children

Hmm, to vypada i celkem zajimaveji nez Supervisor. Diky.

A co podle tebe je /etc/init.d/httpd ? No ja bych rekl, ze klasickej init-script. Monit neni nic jineho, nez wrapper, kterej pouziva init-scripty bez jakekoli modifikace. Supervizor se snazi init-scripty nahradit, monit ovsem nikoliv...

To je sice pravda, ale je pouziti scriptu pro start misto vlastniho fork+exec opravdu problem?

To jestli se pouzivaji pro start/stop sluzeb init scripty (nebo upstart/system­d/daemontools apod. start+stop metody) je celkem irelevantni - podstatne je jestli je monitorovaci system schopny detekovat ze dana sluzba nebezi a opravit ji - ne jestli ji nastartuje prostrednictvim nejakeho externiho scriptu nebo primo pomoci fork+exec.

Vyhodou Monitu je, ze krome situace kdy sluzba nebezi protoze daemon spadnul umi detekovat i stavy kdy bezi ale nechova se normalne. Umi tak predchazet vice chybam nez jina reseni.

Monit umi krome procesu hlidat dalsi veci - system load, system memory+swap usage, disk usage, atd. a provazat sluzby zavislostmi => napr. pokud se naplni filesystem kde jsou ulozena data dane sluzby a ta kvuli tomu prestane fungovat, umi na to upozornit , nebo spustit script ktery se pokusi filesystem vycistit - odstranit docasne soubory, apod. a sluzbu tak znovu rozbehnout. Pokud supervizor monitoruje jen existenci procesu a ten dal bezi i kdyz kvuli plnemu filesystemu nefunguje, supervizor nezahlasi zadnou chybu (Monit naproti tomu zjisti je proces nefunguje spravne i bez monitorovani filesystemu - diky protocol testu dane sluzby).

Dalsi vyhodou Monitu je, ze vyuziva minimum zdroju (je napsany v C) a ma minimum zavislosti - da se slinkovat staticky a pak potrebuje jen libc. Supervizor je napsany v python a stava se tak daleko vice pro vlastni funkci zavisly na externich knihovnach - pokud se napr. nektera z prerequisite knihoven nebo python "rozbije" (napr. nepovedeny upgrade, bug, apod.), pak supervizor sam muze byt problemem postizen a monitorovani se zastavi. Monit naproti tomu pobezi dokud se nerozpadne cely system (samozrejme pokud neni bug v samotnem Monit a z praxe je velmi stabilni).

Omlouvam se ze jsem s apache nedal zrovna nejlepsi priklad - Monit init scripty take nepotrebuje (v pripade apache se to byla celkem logicka volba).

Priklad pro Monit bez init scriptu:

check process django matching "manage.py"
start program = "/usr/bin/python /home/user/djan­goproject/mana­ge.py runserver" as uid cx and gid cx

Vždyť to, co píšeš přesně odpovídá tomu, co dělá initscript. V tomhle ohledu je mnohem elegantnější systemd, který ke zjištění, které procesy které službě patří využívá prostředky operačního systému. Ale je jasné, že základní funkcí Monit je úplně něco jiného.

v tejto suvislosti stoji za zmienku:
http://cr.yp.to/daemontools.html