Re: залипший сокет между nginx и fastcgi ?

Maxim Dounin mdounin на mdounin.ru
Пт Дек 24 22:51:25 MSK 2010


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 at 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 at debian-snar:~#

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

Maxim DOunin 



Подробная информация о списке рассылки nginx-ru