Dan Lukes wrote on 11/25/2014 17:26:
On 11/25/14 15:53, Miroslav Lachman:
[...]
Pak rcorder nelze, co by hotove reseni, pouzit. Popravde receno, on stejne nejde pouzit. Z pozadavku soudim, ze se snazis vyhnout "falesnym poplachym", kdy bude ohlasena zavada sluzby, protoze uz (jeste) nebezi.
Ano, presne o to jde.
V takovem pripade ale nepotrebujes monitorujici proces nastartovat pote, co nastarujes vsechny monitorovane sluzby, nybrz pote, co vsechny monitorovane sluzby zacnou bezet. Coz neni totez.
I o tomhle problemu vim, protoze treba MySQL, nebo OpenVPN se spousti na pozadi, zatim co rc script uz vrati dal rizeni rc ke spousteni dalsich scriptu.
[...]
Staci, kdyz ji nastartujes ldykoliv - a ona nejprve po svem startu pocka nez vsechny monitorovane sluzby nastartuji (tim nemyslim pasivni cekani na timeout, ale aktivni cekani s jejich testovanim) behem ktereho nehlasi, ze ta-ktera sluzba nefunguje (protoze to je pri spousteni sluzby normalni) a teprve kdyz vsechno nastartuje prejde na normalni provoz.
Cele je to v podstate tak jak rikas. O rc scriptech neco malo nastudovano mam, parkrat jsem i nejaky napsal. Takze primarne mi slo o to, jestli neprehlizim neco, co zna nekdo jiny a me to jen nejak uniklo. Napriklad to, jestli se nahodou rc.local nevola az po zpracovani vsech /etc/rc.d/ a /usr/local/etc/rc.d/ :)
Tim, ze bych svuj monitoring spoustel az jako posledni, abych mohl alespon nejak "sofistikovane odhadnout" ten potrebny timeout, kdy zacit opravdu sledovat sluzby. Protoze nekdy se muze stat, ze nejaka sluzba nabiha dele nez obvykle (treba kvuli DNS timeoutu, nebo nejakem recovery po padu systemu) a to zdrzi i dalsi sluzby. Proto jsem chtel svuj script spustit vzdy opravdu jako posledni a pak mit nejaky ten timeout, ve kterem jeste nebudu sluzby skutecne monitorovat.
Prislo by mi to lepsi, nez spustit ten monitoring nekde uprostred spousteni ostatnich sluzeb s nejakym "odhadnutym" timeoutem, ktery uz ale nemuze vzit v potaz spousteni jinych sluzeb.
Ale cele to resim spis z nejakeho teoretickeho pohledu na vec. V praxi to proste muzu spustit klidne tim @restart sleep 120 z cronu a holt se nekdy stane, ze to zahlasi falesny problem po rebootu. Zas tak casto servery nerebootuju.
2 Pavel Baculak - no s tim cronem, to je to, co jsem psal hned v tom prvnim mailu = @reboot je v cronu "Run once, at startup of cron". Coz muze mit zase vedlejsi efekt toho, ze "service cron restart" spusti i tuhle udalost. A bohuzel tam nema udalost pro shutdown, kde bych zase ten monitoring potreboval vypnout jako prvni sluzbu ze vsech vypinanych.
Asi to nakonec udelam klasickym rc scriptem s dlouhym timeoutem pri spusteni.
Mirek -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
