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

и понятно, что 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.

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