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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
