lighttpd, uid 80: exited on signal 11

[Dan Lukes]

Miroslav Lachman wrote:
>> Poustej rovnou
>>
>> gdb --args /usr/local/sbin/lighttpd -D -f 
>> /usr/local/etc/lighttpd/lighttpd.conf
>>
>> pak
>>
>> break mod_status_handle_server_status
>>
>> (jenze to mozna bez prekladu s debugovacimi informacemi nepujde)
> 
> Ne jen ze to nejde (Function "mod_status_handle_server_status" not 
> defined.), ale navic to pri spusteni pres gdb nesegfaultuje a v poklidu 
> vraci spravnou status stranku

V kazdem malem problemu se skryva nejmene jedne dalsi podproblem, ktery 
je vetsi.

Z neceho, co vypadalo snadno debugovatelne se razem stalo neco 
debugovatelneho velmi obtizne.

Vilem Kebrt wrote:
> vidim: read(15,0x801874000,4095)                        ERR#35 'Resource temporarily unavailable'

35 je EAGAIN a to se u read() vyskytuje v jedinem pripade - deskriptor 
otevreny jako neblokujici a pokus o cteni v dobe, kdy nejsou pripravena 
zadna data.

Miroslav Lachman wrote:
> nevim, co je to za Resource, ktery tomu nejde precist

O deskriptoru 15 vime, ze se na nej volalo  getsockopt(15,IPPROTO_TCP 
...) coz ho umoznuje identifikovat s vysokou jistotou. Je to deskriptor, 
ktery reprezentuje sitove spojeni mezi klientem a serverem. Server se 
pokousi cist data, ktera jeste nedorazila - dorazi za chvili a on je 
normalne precte. Takze tohle skoro jiste nic zajimaveho neznamena.

Ani na vadu fyzicke pameti bych to pri takhle deterministickem chovani 
netypoval (i kdyby to nebezelo ve virtualu).

Jestli ale cekate, ze kdyz jsem vam pomluvil vsechny vase napady, ze se 
ted vytasim s nejakym vlastnim jednoduchym resenim, tak to nemuzu slouzit.

Program bez gdb pada, ale s gdb ne, takze problem je nedebugovatelny. To 
samo o sobe o pricine problemu sice neco rika, ale neni prilis jasne co 
presne. Lehce to favorizuje timing jako pricinu potizi, ale u 
single-threadoveho programu je timing spise mene pravdepodobnou pricinou 
potizi. Takze tezko rict.

Pokud pri abendu vznikne alespon coredump, mohli bychom se o analyzu 
pokusit alespon z nej. Ale to je docela hard task ...

Pokud problem uz jednou vyresila reinstalace, lze vyslovit hypotezu, ze 
to vyresi i podruhe. Pred tim bych vyuzil pkg info -l lighthttp k 
ziskani seznamu vsech souboru, ktere jsou soucasti balicku a k nim 
ziskal hashe:

sha1 $( pkg info -l lighttp )

Po reinstalaci, pokud tedy problem vyresi, udelat totez a zjistit jaky 
soubor se zmenil (mozna se neochodi puvodni verze zazalohovat at apk 
muzeme zjistit rovnou jak se zmenil).

Otevrene ale pripoustim moznost, ze reinstalace problem vyresi ANIZ se 
podari najit jakoukolvi zmenu. V takovem pripade zustane pricina 
problemu neznama - a protoze problem zmizi - nadale neanalyzovatelna ...

Dan