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

[Alexandre Snarskii]

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:~#

и понятно, что read на таком соединении будет ждать чего-нибудь до 
бесконечности :(

На FreeBSD (7.3-stable, 8.2-prerelease) не воспроизводится. 

Workaround для Linux: использовать fastcgi over unix sockets, в таком 
сетапе на том же коде и том же nginx'е воспроизвести не удается. 

[1]: нормальное tcp-соединение через localhost - это две строки
в lsof'е, принадлежащие разным процессам. Например

ssh       9642        snar    3u  IPv4 36281870       TCP 127.0.0.1:57162->127.0.0.1:ssh (ESTABLISHED)
sshd      9643        root    3r  IPv4 36281871       TCP 127.0.0.1:ssh->127.0.0.1:57162 (ESTABLISHED)

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is.