nginx segfault

[Gena Makhomed]

On Tuesday, June 3, 2008 at 19:46:36, cray wrote:

c> Jun  3 16:55:56 xserv kernel: nginx[12535]: segfault at 00000014 eip 0805e6d5 esp bfa37b60 error 6
c> Jun  3 19:18:04 xserv kernel: nginx[13458]: segfault at 000001a4 eip 08079f87 esp bfa37ba0 error 4
c> Jun  3 20:09:48 xserv kernel: nginx[13456]: segfault at 00000000 eip 0804ce5f esp bfa37ab0 error 4

здесь, наверное, помог бы отладочный лог и backtrace
по core dump. автор nginx вернется из отпуска 12.06.

c> 2008/06/03 20:09:48 [error] 13456#0: *21890783 upstream sent too
c> big header while reading response header from upstream, client:
c> xxx.xxx.xxx.xxx server: blablabla.org, request: "GET
c> /parse.php?sid=d7b6c21f351510c5910af54f2bc7e083 HTTP/1.1",

в этой ситуации возможно поможет увеличение fastcgi_buffer_size,
или уменьшение размера заголовков, отправляемых backend`ом.

c> upstream: "fastcgi://unix:/tmp/php.sock:", host: "blablabla.org"
c> 2008/06/03 20:09:48 [alert] 13456#0: *21890783 recv() failed
c> (95: Operation not supported) while reading response header from upstream

==========================================================================
On Thursday, May 8, 2008 at 12:43:37, Igor Sysoev wrote:
IS> А EOPNOTSUPP при работе с unix socket'ами - это бага в ядре, когда
IS> размер буфера для чтения равен нулю. TCP выдаёт 0, хотя, возможно,
IS> правильнее бы выдавать EINVAL.
==========================================================================

c> насколько я понимаю проблема не критическая, но интересует почему
c> nginx не может нормально обработать ошибку с парсингом больших хидеров?

наверное потому, что размеры буферов в nginx динамически не изменяются,
а владелец backend-сервера может управлять размером заголовков ответов.

-- 
Best regards,
 Gena