Hello!

On Fri, Dec 24, 2010 at 10:02:09PM +0300, Alexandre Snarskii wrote:

> On Fri, Dec 17, 2010 at 05:45:42PM +0300, Maxim Dounin wrote:
> > > > CLOSE_WAIT - со стороны fcgi? Если при этом fcgi приложение
> > > > заблокировалось в read() (а не ест процессор, пытаясь звать read()
> > > > снова и снова), то это видимо race в ядре. Ибо CLOSE_WAIT
> > > > означает, что ядро в курсе, что сокет с той стороны закрыли, и из
> > > > него больше ничего не прочитать, read() должен вернуться как
> > > > только выгребет всё из буфера.
> > >
> > > Да, CLOSE_WAIT со стороны fcgi. Да, fcgi именно заблокировалось
> > > в read() а не поллит его. Да, read() в такой ситуации должен вернуть
> > > EOF или error, но, блин, не возвращает...
> >
> > Я бы ещё проверил, что дескриптор передаваемый в read() правильный
> > (соответствует исследуемому соединению). А дальше - изучать ядро
> > (т.к. ядро не последнее, то видимо начать имеет смысл с
> > changelog'ов).
>
> Воспроизводится на всех ядрах up to 2.6.32 (debian lenny + ядро из
> backports), правда, в основном воспроизводится как ESTABLISHED
> соединение "без пары"[1], типа вот такого:
>
> root@debian-snar:~# lsof -anni | grep 48624
> rcecho 5117 root 8u IPv4 36259261 TCP 127.0.0.1:1025->127.0.0.1:48624 (ESTABLISHED)
> root@debian-snar:~#

Ну вот такое вполне можно объяснить firewall'ом на loopback'е, а
равно и другими причинами для потерь пакетов (кончились буфера и
т.п.).

Maxim DOunin

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru