apache - VYRIESENE

[Dan Lukes]

Jozef Babjak wrote:

>>4) make deinstall apache (APACHA NEVYPINAT ON BEZI DALEJ, ASPON KED MATE 
>>FAST_CGI!)
> 
> 
>   ^-- No, on sice bezi, ale len do momentu, kym proces apaca nepotrebuje 
> operacny system odstrankovat'/odswapova't, co v pohode moze, lebo 
> spustitel'ny subor sluzi ako swapovy priestor pre odswapovanie pamate 
> kodu... V pripade, ze mu medzi tym make deinstall tento subor zmaze, tak 
> pri opa:tovnom nacitani procesu bude mat jadro pravdepodobne znacne 
> problemy (nakesovany ten subor nemoze byt', lebo keby bol nakesovany, tak 
> jadro uvolni pama:t' v prvom rade uvol'nenim kese, nie swapovanim). 
> 
> [Pre vysvetlenie: stranky obsahujuce v pama:ti kod procesu nie je potrebne 
> pri odswapovavani odkladat' do swapaku (t.j. na disk), pretoze uz na disku 
> raz su, v subore, odkial' sa proces spustil. Preto sa v tomto pripade 
> "odswapovanie" deje tak, ze sa stranky oznacia za odswapovane, ale nie v 
> na swap particii, ale v povodnom subore, odkial boli nacitane.]
> 
> I tak sa mi zda pravdepodobne, ze make deinstall pri spustenom apaci bud'
> zlyha (nemoze zmazat' subor httpd, pretoze jadro ho ma namapovany pre
> vyssie uvedeny pripad potreby odswapovania kodu procesu, a teda ho zmazat'
> vo vlastnom zaujme nedovoli), alebo make deinstall sa pokusi zmazat' subor 
> httpd a nepodari sa mu to, ale tuto chybu skryje/odignoruje, a tudiz 
> neprevedie deinstall. 

	Vyjimecne ponecham dopis (skoro) cely, protoze budu reagovat postupen 
na (skoro) vsechny odstavce.

	Zacnu od posledniho a mirne zesiroka. Na UFS (a mnohych dalsich 
UNIXovych filesystemech) existuji dve ruzne operace - "smazani jmena 
souboru" a "smazani souboru". V soucasnych verzich vetsiny systemu 
pritom ta druha funkce (smazani souboru) neni uzivateli VUBEC pristupna. 
Soubor jest smazan systemem automaticky tehdy, pokdu na nej neexistuje 
odkaz. Za odkaz se jednak povazuje "jmeno souboru" (kdyz ma soubor vice 
jmen, hovoriem o (hard-)lincich), jednak descriptor procesu drzici 
"otevreny" takovy soubor.

	Uzivateli jsou dostupne pouze funkce jako "remove (3)" respektive 
"unlink (2)". Soubor sam, pokud ma jeste jine jmeno - a nebo - a to je 
varianta, ktera nas ted zajima vice - je otevren nejakym procesem a 
pouzivan, ani pouzitim techto funkco nezanikne (vsimnete si, ze 
napriklad muzete klidne za behu Apache smazat jeho LOG soubor - ale 
misto na disku se uvolni teprve tehdy, kdyz beh Apache skonci - do te 
doby soubor existoval a Apache do nej stale zapisoval).

	To, co se rika v predposlednim odstavci je pravda, ale nikoli uplna. 
System, v okamziku, kdy soubor spusti, ho "otevre" - a po dobu behu 
prislusneho procesu ho nejen drzi otevreny, ale take zamknuty na zapis 
(zkuste pustit treba 'echo "" >jmeno_souboru' kdyz kod tohoto souboru 
zrovna "bezi" - dozvite se, ze "text file busy"). Takze zapis do TOHOTO 
souboru je vyloucen.

	Smazat jeho jmeno ale zakazano neni. Pokud jmeno souboru smazeme, 
soubor nezanikne - ale otevre se nam tim prostor pro vytvoreni noveho 
souboru, se stejnym jmenem, jake puvodne nosil ten puvodni.

	Upgradovat tedy bezici proces neni nemozne. Problem dokonce nenastava 
ani se soubeznym behem obou "verzi" tohoto souboru - je pravda, ze kdyz 
spoustim (novy) proces, ktery uz je v jedne instanci pritomen v pameti, 
tak se kod do pameti nenatahuje znovu, ale "shodnost" se nezjistuje 
porovnanim jmen souboru, ale "dev+inode" - a to je u noveho souboru 
urcite jine (vzhledem k tomu, ze puvodni soubor jeste nezanikl).

	Jasne, ze pri "in-place" uprade muze vzniknout problem - pokud se cely 
produkt sklada z vice souboru, ktere se pouzivaji "on-demand", pak se 
skutecne muze "stare" verzi stat, ze po provedeni upgrade otevre a 
pouzije obsah souboru nove verze - a to nemusi skoncit dobre. Nicmene, 
pokud se program takto nechova, problem by nastat nemel ...

	No, slo to napsat i jednou vetou - snazani souboru by popsane problemy 
skutecne prineslo, ale ani deninstall ani cokoliv jineho soubory nemaze 
- jen jejich jmena.

						Dan