On 11/25/14 23:27, Miroslav Lachman:
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.
Vsechny se spusti na pozadi. Spousteci sekvence by nemohla pokracovat,
kdyby se spousteny proces nedaemonizoval a nevratil ji rizeni (si to
zkus - nastav OpenVPN at se pri svem startu pta na jmeno a heslo k
tunelu nebo nekteremu certifikatu a uvidis, jak se ti na tom celej boot
zadre a nedokonci se dokud to nezadas)
A spis vyjimecne se sluzba daemonizuej uz v plne funkcnim stavu -
vetsinou je to naopak a po daemon() teprve vykonava rady "pripravnych"
praci ...
Jo, v nekterejch pripadech je "pripravna" faze natolik kratka, ze to
vypada, jako by to bylo okamzite.
Napriklad to, jestli se nahodou rc.local nevola az po zpracovani vsech
/etc/rc.d/ a /usr/local/etc/rc.d/ :)
Ne, rc.local je startovan jako servis /etc/rc.d/local a ten je
# REQUIRE: DAEMON
# BEFORE: LOGIN
Takze rada aplikacnich serveru se spousti naopak az po nem (ty, ktere
maji REQUIRE: LOGIN), nektere se spousteji soucasne s nim (bez presne
definovaneho vzajemneho poradi).
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
Sice ty strategii rozumim, ale ono by to nebylo ruzove i kdyby to slo.
Pokud se nektera z tech sluzeb z nejakeho duvodu nespusti vubec, pak by
se nespustil vubec ani ten tvuj monitor (nesplnene predpoklady,
konkretne predpoklad "spusteno vsechno").
Takze ty to sice na jednu stranu chces spustit s odstupem, ale nikoliv
neomezene velkym ...
Asi to nakonec udelam klasickym rc scriptem s dlouhym timeoutem pri
spusteni.
Nebude osamocen. bgfsck je taky sluzba s odlozenym startem.
Ty ovsem budes muset vyresit jeste drobnosti, kterou bgfsck resit nemusi
- pripadny manualni (re)start monitoringu, kde odlozeny start spis chtit
nebudes.
Nastesti, tady se da inspirovat z fsck, ktere taky interne resi, jestli
je spustenej rucne nebo v ramci bootu:
if [ "$autoboot" = yes ]; then
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
