On Monday 20 June 2005 11:44, Hristo Chernev wrote: > Здравей, > Имам подобен проблем отпреди година поне, > също като теб пуснах до листата > описание на проблема но явно никой не се > беше сблъсквал и така си и остана. > Ето линк за постинга ми: > http://linux-bulgaria.org/webarchive/2004/Dec/32198.html > Този (д)ефект ( или напълно изчезване на > машината - краш ) се получава горе > долу веднъж в месеца. Повечето случаи има > Treason Uncloaked съобщения в > лога. Разликата е че аз съм с апаче 1. > Затова с голям интерес чаках някой да ти > отговори , но уви... > Понеже почнах да подозирам драйверите на > мрежовата карта или самата карта > искам да те питам с каква карта си? И има ли > някакви нови разкрития при > теб?
Сега се сетих ;-) Тогава го оприличих по-скоро на SYN атака, но май не е. Не трябва да подозираш драйвера на картата, а TCP кода (в лога пише ли, че идва от kernel: TCP:...?) който се бори с това некоректно или нападателно поведение на отсрещната страна (дето си свива tcp window [1] волно или неволно). Щом принти Treason Uncloaked, значи ядрото е заловило нарушението по свиване на tcp джама (което нарушава и TCP RFC btw) и взима мерки. Ето някои обяснения на google: http://www.linuxprinting.org/pipermail/general-list/2003q2/003945.html http://lists.debian.org/debian-isp/2002/04/msg00192.html Не съм решавал такъв проблем, но *според мен* това което се случва е: отсрещната страна казва (s tcp window-a) прати ми много малко или нула data octets обратно, при което ядрото не затваря сокета веднага, а изчаква по определена схема (в коментарите в сорса пише), съответно това може да влияе на инстансите на апаха / а и не само /. Т.е. опит да те постави в положение да изчакваш ангажирайки си собствените ресурси за колкото се може по-дълго време. Отсрещната страна може да прави това и неволно ако е с бъгав TCP code, но всеки трябва да реагира подходящо. Евентуално може да се събере малко инфо с tcpdump, да се прочетат внимателно коментарите в /usr/src/linux/net/ipv4/tcp_timer.c и може би да се добие по-добра представа за промяна на съответните tcp* променливите (tcp orphans ли да се намалят, по-бързо да таймаутва connection-a ли ? ) от /proc/sys/net/ipv4 или друго което е хич не е тривиално... промяна в кода на ядрото които се бори с това ( тук ask lkml ). NOTE: не знам точното решение, а просто предлагам в каква посока да търсите. [1] http://www.protocols.com/pbook/tcpip2.htm#TCP -- pub 4096R/0E4BD0AB 2003-03-18 <danchev.fccf.net/key pgp.mit.edu> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
