PHP 4.4.0 session.so + (httpd), uid 80: exited on signal 11

[Miroslav Lachman]

Dan Lukes wrote:

> Miroslav Lachman wrote:
> 
>> extension=session.so a Apache zase exituje. Tenkrat ovsem exitoval 
>> jenom na strankach v PHP, ktere pouzivaji session, ted exituje pri 
>> jakemkoliv requestu. Tenkrat jsem s tim zapasil skoro cely den, 
>> nekolikrat jsem rekompiloval PHP, Apache a extension php4-session az 
>> to najednou zaclo fungovat. Zkusil jsem to i tady, ale zatim nic 
>> nezabira.
> 
> 
>> Jul 17 12:16:12 velvet kernel: pid 52607 (httpd), uid 80: exited on 
>> signal 11
> 
> 
>> Napada nekoho, jak se dopatrat "zavady" a jak ji odstranit? Je to 
>> nastesti stroj ve zkusebnim provozu, takze to neni zadny velky 
>> prusvih, ze to ted nejede, ale precejen bych to rad vyresil uz kvuli 
>> tomu, ze mi neni jasne, proc to na jednom stroji funguje a na druhem ne.
> 
> 
>     Tohle muze byt nasledek vadneho prekladu. Pokud se pri nejakych 
> upgradech nedela preklad uplne kompletne cely znova, muze se stat, ze 
> spatne napsany Makefile umozni, aby nejaky *.o nebo nejaka knihovna 
> zustala nerekompilovana (nebot' make nespravne usoudi, ze je stale 
> aktualni). A jelikoz PHP souvisi s Apachem a ten zase se systemem, muze 
> to byt v kterekoliv z techto komponent ( u systemu pravda asi jen v 
> pripade, ze si ho sam prekladas).
> 
>     Druha moznost je, ze nejaky (datumove aktualni) objekt ci knihovna 
> jsou poskozene. To se muze stat pri jakemkoliv padu stroje. Zrovna vcera 
> jsem po panicu mel velmi nahodny obsah rc.conf, ktery pred panicem byl v 
> poradku. Jenze, kdyz je soubor poskozeny hodne, vetsinou se na to prijde 
> rychle. Pokud dojde k poskozeni pouze jednoho sektoru, muze se to 
> projevit jen ve specificke situaci. Podobna chyba se navic muze ruznym 
> zpusobem zavlekat jinam a celkovy nasledek je zcela neodhadnutelny.
> 
>     Co je jeste horsi, ke zminenemu poskozeni obsahu souboru nemusi 
> dojit jen pri abendu systemu, ale, bohuzel, za urcitych okolnosti (ktere 
> nastesti nenastavaji casto) i na systemu s ATA disky, ktery byl ukoncen 
> naprosto regulerne.
> 
>     Takovy problem se podari "zahadne" vyresit proste ve chvili, kdy pri 
> pokusovani a novem prekladani a instalacich se podari poskozeny soubor 
> nahradit neposkozenym.
> 
>     Takze jedna z moznosti jak vec resit je preinstalovat (pripadne 
> znovu prelozit a nainstalovat, pokud se primo na onom stroji preklada) 
> vsechny zucastnene komponenty, pocinaje systemem (u toho lze udelat 
> pomerne jednoduse upgrade na stejnou verzi, pokud ma pocitac rozumnou 
> konektivitu, nebo mas instalacni CD).
> 
>     Tim nerikam, ze problem nemuze byt uplne nekde jinde, nicmene, s 
> ohledem na popsane projevy bych ja hledal z tohoto konce.
> 
>     Smutnou vlastnosti popsane metody je, ze pokud zabere, nikdy se 
> nedozvis, jaka komponenta byla poskozena, ani co a proc ji poskodilo - 
> takze se toho priste nevyvarujes ...
> 
>                         Dan
> 

Tak to je snad ten nejhorsi scenar, ktereho jsem se obaval, protoze i 
system jsem si kompiloval sam. Tudiz chyba je kdekoliv od urovne OS, 
pres Apache az po posledni kousek PHP (v podstate kterykoliv modul). Ze 
by se mi zrovna chtelo do kompletni rekompilace se rict neda, jelikoz 
jsem ted na 14 dni mimo Prahu a stroj je v Casablance, takze kdyby se 
nedejboze neco stalo se systemem (treba ze by po rebootu nenabehnul), 
dost spatne bych to resil :(

Zkusim tedy jeste parkrat prekompilovat Apache + PHP + extensions a 
uvidime, co bude dal. :(

-- 
Miroslav Lachman
Webapplication Developer