rc script, ktery se musi spustit posledni

Dan Lukes dan at obluda.cz
Wed Nov 26 00:51:20 CET 2014


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



More information about the Users-l mailing list