date:20161125

Re: Очередной вопрос nginx+php

2016-11-25 Пенетрантность Gena Makhomed


On 25.11.2016 10:55, IvanMiller wrote:


Вот в очередной раз принялся "конфигурировать". Обратился к офф.
документации, там четко сказанно

The problem section usually looks like this:

location ~* \.php$ {
fastcgi_pass backend;
# [...]
}

Хорошо, плохо так плохо, а хорошо вот так

location ~* (file_a|file_b|file_c)\.php$ {
fastcgi_pass backend;
# [...]
}

Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не
попадают, Nginx их начинает тупо выдавать без обработки.


location заданные регулярными выражениями
обрабатываются в порядке их появления в конфиге:
http://nginx.org/ru/docs/http/ngx_http_core_module.html#location

Можно делать так:

location ~* (file_a|file_b|file_c)\.php$ {
fastcgi_pass backend;
# [...]
}

location ~* \.php$ {
return 403;
}

--
Best regards,
 Gena

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

Re: Очередной вопрос nginx+php

2016-11-25 Пенетрантность Aleksandr Sytar

25 ноября 2016 г., 14:55 пользователь Илья Шипицин 
написал:

> через try_files можно сделать условие "если есть файл - отдать его, если
> нет, маршрутизируем в @php


И при запросе php-файла nginx радостно отдаст его пользователю.

Не надо давать "плохие" советы, человек про другое спрашивал
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx/1.10.2 crashes in ngx_http_v2_write_handler

2016-11-25 Пенетрантность Валентин Бартенев

On Friday 25 November 2016 18:05:30 Валентин Бартенев wrote:
> On Friday 25 November 2016 10:56:45 Dmitriy M. wrote:
> > 25 ноября 2016 г., 10:31 пользователь Dmitriy M.  
> > написал:
> > > 20 ноября 2016 г., 18:22 пользователь Валентин Бартенев
> > >  написал:
> > >> On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote:
> > >>> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote:
> > >>> [..]
> > >>> >
> > >>> > К сожалению, это практически невозможно. Сервису необходимы
> > >>> > перечисленные при сборке модули, без них возможности проверки под
> > >>> > нагрузкой нет. Способа воспроизведения нет, они происходят
> > >>> > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных
> > >>> > клонированных сетапов).
> > >>> >
> > >>> > Могу дополнить, что эти же модули (набор модулей, но да
> > >>> > headers-more-nginx-module-84241e4 и libressl были обновлены) были
> > >>> > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода
> > >>> > крашей небыло, конфигурация nginx.conf существенно не менялась.
> > >>> >
> > >>> > Попробую собрать с предыдущими версиями модулей
> > >>> > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без
> > >>> > оптимизаций кода для дебаггинга.
> > >>> > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/
> > >>>
> > >>> То, что модули раньше работали - абсолютно не показатель.  Многие 
> > >>> сторонние
> > >>> модули славятся тем, что лезут во внутренние структуры nginx, используя 
> > >>> их
> > >>> не по назначению.  Как результат, такие модули могут поломать nginx при 
> > >>> любых
> > >>> изменениях в его внутренних механизмах.
> > >>>
> > >>> Между версией 1.10.1 и 1.10.2 произошли существенные изменения в 
> > >>> обработке
> > >>> тела запроса в модуле http/2.
> > >>>
> > >>> Бектрейс, который вы привели - не содержит какой-либо полезной 
> > >>> информации
> > >>> для дебага.  Ошибка, послужившая причиной падения, произошла в другом 
> > >>> месте,
> > >>> на другой итерации цикла обработки событий.  А то, что видно на 
> > >>> бэктрейсе -
> > >>> лишь следствие.
> > >>>
> > >>> Можно попытаться получить debug-лог перед падением:
> > >>> http://nginx.org/ru/docs/debugging_log.html#memory
> > >>>
> > >>> Смотрите раздел про запись его в буфер в памяти.
> > >>>
> > >> [..]
> > >>
> > >> И в дополнение к предыдущему письму, а вы уверены, что у вас
> > >> nginx-upload-progress-module вообще с HTTP/2 корректно работает?
> > >>
> > >> Судя по тому же тикету на github, он и не должен:
> > >> https://github.com/masterzen/nginx-upload-progress-module/issues/45
> > >>
> > >> Интересно также, что вы делаете с помощью headers-more-nginx-module,
> > >> что не получается сделать стандартными средствами nginx?
> > >>
> > >> --
> > >> Валентин Бартенев
> > >
> > > Добрый день, Валентин
> > >
> > 
> > и вдогонку прошлому письму, core номер два, тоже на сетапе без сторонних 
> > модулей
> > nginx -V
> > nginx version: nginx/1.10.2
> > built with LibreSSL 2.4.4
> > TLS SNI support enabled
> > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
> > /usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt'
> > --conf-path=/usr/local/etc/nginx/nginx.conf
> > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
> > --error-log-path=/var/log/nginx/error.log --user=www --group=www
> > --modules-path=/usr/local/libexec/nginx
> > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp
> > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
> > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp
> > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp
> > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
> > --http-log-path=/var/log/nginx/access.log --with-http_realip_module
> > --with-http_stub_status_module --with-pcre --with-threads
> > --with-http_ssl_module --with-http_v2_module
> > --with-openssl=./libressl-2.4.4 --with-debug
> > 
> > 
> > #0  0x004fd0da in ngx_http_v2_write_handler (wev=0x85144f380)
> > at src/http/v2/ngx_http_v2.c:435
> > 435 ngx_queue_remove(q);
> > [New Thread 801c16000 (LWP 100771/)]
> > (gdb) i locals
> > rc = -2
> > q = (ngx_queue_t *) 0x85d2bdcb0
> > c = (ngx_connection_t *) 0x84a4b0b80
> > stream = (ngx_http_v2_stream_t *) 0x85144f380
> > h2c = (ngx_http_v2_connection_t *) 0x853bf7a20
> > Current language:  auto; currently minimal
> > (gdb) p q
> > $1 = (ngx_queue_t *) 0x85d2bdcb0
> > (gdb) p *q
> > $2 = {prev = 0x3938386138313962, next = 0x85e7d7cb0}
> > (gdb) p c
> > $3 = (ngx_connection_t *) 0x84a4b0b80
> > (gdb) p *c
> > $4 = {data = 0x853bf7a20, read = 0x84f44f380, write = 0x85144f380, fd
> > = 6509, recv = 0x491af0 , send = 0x491db0
> > , recv_chain = 0x492240 ,
> > send_chain = 0x4923b0 ,
> >   listening = 0x801de93d0, sent = 2319718, log = 0x8562a2460, pool =
> > 0x8562a2400, type = 1, sockaddr = 0x8562a2450, socklen = 16, addr_text
> > = {len = 12, data = 0x8562a24b0 "92.60.186.11\b"}, proxy_protocol_addr
> > =

Re: nginx/1.10.2 crashes in ngx_http_v2_write_handler

2016-11-25 Пенетрантность Валентин Бартенев

On Friday 25 November 2016 10:56:45 Dmitriy M. wrote:
> 25 ноября 2016 г., 10:31 пользователь Dmitriy M.  
> написал:
> > 20 ноября 2016 г., 18:22 пользователь Валентин Бартенев
> >  написал:
> >> On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote:
> >>> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote:
> >>> [..]
> >>> >
> >>> > К сожалению, это практически невозможно. Сервису необходимы
> >>> > перечисленные при сборке модули, без них возможности проверки под
> >>> > нагрузкой нет. Способа воспроизведения нет, они происходят
> >>> > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных
> >>> > клонированных сетапов).
> >>> >
> >>> > Могу дополнить, что эти же модули (набор модулей, но да
> >>> > headers-more-nginx-module-84241e4 и libressl были обновлены) были
> >>> > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода
> >>> > крашей небыло, конфигурация nginx.conf существенно не менялась.
> >>> >
> >>> > Попробую собрать с предыдущими версиями модулей
> >>> > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без
> >>> > оптимизаций кода для дебаггинга.
> >>> > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/
> >>>
> >>> То, что модули раньше работали - абсолютно не показатель.  Многие 
> >>> сторонние
> >>> модули славятся тем, что лезут во внутренние структуры nginx, используя их
> >>> не по назначению.  Как результат, такие модули могут поломать nginx при 
> >>> любых
> >>> изменениях в его внутренних механизмах.
> >>>
> >>> Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке
> >>> тела запроса в модуле http/2.
> >>>
> >>> Бектрейс, который вы привели - не содержит какой-либо полезной информации
> >>> для дебага.  Ошибка, послужившая причиной падения, произошла в другом 
> >>> месте,
> >>> на другой итерации цикла обработки событий.  А то, что видно на бэктрейсе 
> >>> -
> >>> лишь следствие.
> >>>
> >>> Можно попытаться получить debug-лог перед падением:
> >>> http://nginx.org/ru/docs/debugging_log.html#memory
> >>>
> >>> Смотрите раздел про запись его в буфер в памяти.
> >>>
> >> [..]
> >>
> >> И в дополнение к предыдущему письму, а вы уверены, что у вас
> >> nginx-upload-progress-module вообще с HTTP/2 корректно работает?
> >>
> >> Судя по тому же тикету на github, он и не должен:
> >> https://github.com/masterzen/nginx-upload-progress-module/issues/45
> >>
> >> Интересно также, что вы делаете с помощью headers-more-nginx-module,
> >> что не получается сделать стандартными средствами nginx?
> >>
> >> --
> >> Валентин Бартенев
> >
> > Добрый день, Валентин
> >
> 
> и вдогонку прошлому письму, core номер два, тоже на сетапе без сторонних 
> модулей
> nginx -V
> nginx version: nginx/1.10.2
> built with LibreSSL 2.4.4
> TLS SNI support enabled
> configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
> /usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt'
> --conf-path=/usr/local/etc/nginx/nginx.conf
> --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
> --error-log-path=/var/log/nginx/error.log --user=www --group=www
> --modules-path=/usr/local/libexec/nginx
> --http-client-body-temp-path=/var/tmp/nginx/client_body_temp
> --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
> --http-proxy-temp-path=/var/tmp/nginx/proxy_temp
> --http-scgi-temp-path=/var/tmp/nginx/scgi_temp
> --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
> --http-log-path=/var/log/nginx/access.log --with-http_realip_module
> --with-http_stub_status_module --with-pcre --with-threads
> --with-http_ssl_module --with-http_v2_module
> --with-openssl=./libressl-2.4.4 --with-debug
> 
> 
> #0  0x004fd0da in ngx_http_v2_write_handler (wev=0x85144f380)
> at src/http/v2/ngx_http_v2.c:435
> 435 ngx_queue_remove(q);
> [New Thread 801c16000 (LWP 100771/)]
> (gdb) i locals
> rc = -2
> q = (ngx_queue_t *) 0x85d2bdcb0
> c = (ngx_connection_t *) 0x84a4b0b80
> stream = (ngx_http_v2_stream_t *) 0x85144f380
> h2c = (ngx_http_v2_connection_t *) 0x853bf7a20
> Current language:  auto; currently minimal
> (gdb) p q
> $1 = (ngx_queue_t *) 0x85d2bdcb0
> (gdb) p *q
> $2 = {prev = 0x3938386138313962, next = 0x85e7d7cb0}
> (gdb) p c
> $3 = (ngx_connection_t *) 0x84a4b0b80
> (gdb) p *c
> $4 = {data = 0x853bf7a20, read = 0x84f44f380, write = 0x85144f380, fd
> = 6509, recv = 0x491af0 , send = 0x491db0
> , recv_chain = 0x492240 ,
> send_chain = 0x4923b0 ,
>   listening = 0x801de93d0, sent = 2319718, log = 0x8562a2460, pool =
> 0x8562a2400, type = 1, sockaddr = 0x8562a2450, socklen = 16, addr_text
> = {len = 12, data = 0x8562a24b0 "92.60.186.11\b"}, proxy_protocol_addr
> = {len = 0, data = 0x0},
>   ssl = 0x8562a2520, local_sockaddr = 0x801c99d28, local_socklen = 16,
> buffer = 0x0, queue = {prev = 0x0, next = 0x0}, number = 25442656,
> requests = 202, buffered = 1, log_error = 2, unexpected_eof = 1,
> timedout = 0, error = 0,
>   destroyed = 0, idle = 0, reusable = 0, close = 0,

Re: Очередной вопрос nginx+php

2016-11-25 Пенетрантность Илья Шипицин

25 ноября 2016 г., 13:55 пользователь IvanMiller <
nginx-fo...@forum.nginx.org> написал:

> Всем добрый день.
> Вот в очередной раз принялся "конфигурировать". Обратился к офф.
> документации, там четко сказанно
>
> The problem section usually looks like this:
>
> location ~* \.php$ {
> fastcgi_pass backend;
> # [...]
> }
>
> Хорошо, плохо так плохо, а хорошо вот так
>
> location ~* (file_a|file_b|file_c)\.php$ {
> fastcgi_pass backend;
> # [...]
> }
>
> Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не
> попадают, Nginx их начинает тупо выдавать без обработки.
>

через try_files можно сделать условие "если есть файл - отдать его, если
нет, маршрутизируем в @php


>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,271168,271168#msg-271168
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очередной вопрос nginx+php

2016-11-25 Пенетрантность Andrey Kopeyko


Добрый день, Ivan!

On Fri, 25 Nov 2016, IvanMiller wrote:


Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не
попадают, Nginx их начинает тупо выдавать без обработки.


Тут есть 3 варианта
- расширить маску, чтобы и они попадали
- сделать дефолтный location, в котором отвечать 404
- удалить лишнее из DocumentRoot \ с сервера

У каждого - есть и плюсы и минусы.

--
Best regards,
Andrey Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очередной вопрос nginx+php

2016-11-25 Пенетрантность IvanMiller

Да никто и не говорит, что оно работать не будет, просто не очень понятно, о
чем в документации идет речь и как дальше настроить что бы nginx ны выдавал
php файлы.
Вот, она, документация
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,271168,271171#msg-271171

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

Re: Очередной вопрос nginx+php

2016-11-25 Пенетрантность Vadim A. Misbakh-Soloviov

> 
> Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не
> попадают, Nginx их начинает тупо выдавать без обработки.

У меня всё прекрасно работает с

location ~ \.php$ {
fastcgi_pass$upstream_name;
fastcgi_index   index.php;
include fastcgi.conf;
}

(просьба обратить внимание на отсутствие * после ~)
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx/1.10.2 crashes in ngx_http_v2_write_handler

2016-11-25 Пенетрантность Dmitriy M.

25 ноября 2016 г., 10:31 пользователь Dmitriy M.  написал:
> 20 ноября 2016 г., 18:22 пользователь Валентин Бартенев
>  написал:
>> On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote:
>>> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote:
>>> [..]
>>> >
>>> > К сожалению, это практически невозможно. Сервису необходимы
>>> > перечисленные при сборке модули, без них возможности проверки под
>>> > нагрузкой нет. Способа воспроизведения нет, они происходят
>>> > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных
>>> > клонированных сетапов).
>>> >
>>> > Могу дополнить, что эти же модули (набор модулей, но да
>>> > headers-more-nginx-module-84241e4 и libressl были обновлены) были
>>> > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода
>>> > крашей небыло, конфигурация nginx.conf существенно не менялась.
>>> >
>>> > Попробую собрать с предыдущими версиями модулей
>>> > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без
>>> > оптимизаций кода для дебаггинга.
>>> > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/
>>>
>>> То, что модули раньше работали - абсолютно не показатель.  Многие сторонние
>>> модули славятся тем, что лезут во внутренние структуры nginx, используя их
>>> не по назначению.  Как результат, такие модули могут поломать nginx при 
>>> любых
>>> изменениях в его внутренних механизмах.
>>>
>>> Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке
>>> тела запроса в модуле http/2.
>>>
>>> Бектрейс, который вы привели - не содержит какой-либо полезной информации
>>> для дебага.  Ошибка, послужившая причиной падения, произошла в другом месте,
>>> на другой итерации цикла обработки событий.  А то, что видно на бэктрейсе -
>>> лишь следствие.
>>>
>>> Можно попытаться получить debug-лог перед падением:
>>> http://nginx.org/ru/docs/debugging_log.html#memory
>>>
>>> Смотрите раздел про запись его в буфер в памяти.
>>>
>> [..]
>>
>> И в дополнение к предыдущему письму, а вы уверены, что у вас
>> nginx-upload-progress-module вообще с HTTP/2 корректно работает?
>>
>> Судя по тому же тикету на github, он и не должен:
>> https://github.com/masterzen/nginx-upload-progress-module/issues/45
>>
>> Интересно также, что вы делаете с помощью headers-more-nginx-module,
>> что не получается сделать стандартными средствами nginx?
>>
>> --
>> Валентин Бартенев
>
> Добрый день, Валентин
>

и вдогонку прошлому письму, core номер два, тоже на сетапе без сторонних модулей
nginx -V
nginx version: nginx/1.10.2
built with LibreSSL 2.4.4
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--modules-path=/usr/local/libexec/nginx
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_realip_module
--with-http_stub_status_module --with-pcre --with-threads
--with-http_ssl_module --with-http_v2_module
--with-openssl=./libressl-2.4.4 --with-debug


#0  0x004fd0da in ngx_http_v2_write_handler (wev=0x85144f380)
at src/http/v2/ngx_http_v2.c:435
435 ngx_queue_remove(q);
[New Thread 801c16000 (LWP 100771/)]
(gdb) i locals
rc = -2
q = (ngx_queue_t *) 0x85d2bdcb0
c = (ngx_connection_t *) 0x84a4b0b80
stream = (ngx_http_v2_stream_t *) 0x85144f380
h2c = (ngx_http_v2_connection_t *) 0x853bf7a20
Current language:  auto; currently minimal
(gdb) p q
$1 = (ngx_queue_t *) 0x85d2bdcb0
(gdb) p *q
$2 = {prev = 0x3938386138313962, next = 0x85e7d7cb0}
(gdb) p c
$3 = (ngx_connection_t *) 0x84a4b0b80
(gdb) p *c
$4 = {data = 0x853bf7a20, read = 0x84f44f380, write = 0x85144f380, fd
= 6509, recv = 0x491af0 , send = 0x491db0
, recv_chain = 0x492240 ,
send_chain = 0x4923b0 ,
  listening = 0x801de93d0, sent = 2319718, log = 0x8562a2460, pool =
0x8562a2400, type = 1, sockaddr = 0x8562a2450, socklen = 16, addr_text
= {len = 12, data = 0x8562a24b0 "92.60.186.11\b"}, proxy_protocol_addr
= {len = 0, data = 0x0},
  ssl = 0x8562a2520, local_sockaddr = 0x801c99d28, local_socklen = 16,
buffer = 0x0, queue = {prev = 0x0, next = 0x0}, number = 25442656,
requests = 202, buffered = 1, log_error = 2, unexpected_eof = 1,
timedout = 0, error = 0,
  destroyed = 0, idle = 0, reusable = 0, close = 0, shared = 0,
sendfile = 0, sndlowat = 0, tcp_nodelay = 1, tcp_nopush = 0,
need_last_buf = 0, sendfile_task = 0x0}
(gdb) fr
#0  0x004fd0da in ngx_http_v2_write_handler (wev=0x85144f380)
at src/http/v2/ngx_http_v2.c:435
435 ngx_queue_remove(q);
(gdb) l
430 }
431
432 while

Очередной вопрос nginx+php

2016-11-25 Пенетрантность IvanMiller

Всем добрый день.
Вот в очередной раз принялся "конфигурировать". Обратился к офф.
документации, там четко сказанно

The problem section usually looks like this:

location ~* \.php$ {
fastcgi_pass backend;
# [...]
}

Хорошо, плохо так плохо, а хорошо вот так

location ~* (file_a|file_b|file_c)\.php$ {
fastcgi_pass backend;
# [...]
}

Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не
попадают, Nginx их начинает тупо выдавать без обработки.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,271168,271168#msg-271168

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

Re: nginx/1.10.2 crashes in ngx_http_v2_write_handler

2016-11-25 Пенетрантность Dmitriy M.

20 ноября 2016 г., 18:22 пользователь Валентин Бартенев
 написал:
> On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote:
>> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote:
>> [..]
>> >
>> > К сожалению, это практически невозможно. Сервису необходимы
>> > перечисленные при сборке модули, без них возможности проверки под
>> > нагрузкой нет. Способа воспроизведения нет, они происходят
>> > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных
>> > клонированных сетапов).
>> >
>> > Могу дополнить, что эти же модули (набор модулей, но да
>> > headers-more-nginx-module-84241e4 и libressl были обновлены) были
>> > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода
>> > крашей небыло, конфигурация nginx.conf существенно не менялась.
>> >
>> > Попробую собрать с предыдущими версиями модулей
>> > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без
>> > оптимизаций кода для дебаггинга.
>> > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/
>>
>> То, что модули раньше работали - абсолютно не показатель.  Многие сторонние
>> модули славятся тем, что лезут во внутренние структуры nginx, используя их
>> не по назначению.  Как результат, такие модули могут поломать nginx при любых
>> изменениях в его внутренних механизмах.
>>
>> Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке
>> тела запроса в модуле http/2.
>>
>> Бектрейс, который вы привели - не содержит какой-либо полезной информации
>> для дебага.  Ошибка, послужившая причиной падения, произошла в другом месте,
>> на другой итерации цикла обработки событий.  А то, что видно на бэктрейсе -
>> лишь следствие.
>>
>> Можно попытаться получить debug-лог перед падением:
>> http://nginx.org/ru/docs/debugging_log.html#memory
>>
>> Смотрите раздел про запись его в буфер в памяти.
>>
> [..]
>
> И в дополнение к предыдущему письму, а вы уверены, что у вас
> nginx-upload-progress-module вообще с HTTP/2 корректно работает?
>
> Судя по тому же тикету на github, он и не должен:
> https://github.com/masterzen/nginx-upload-progress-module/issues/45
>
> Интересно также, что вы делаете с помощью headers-more-nginx-module,
> что не получается сделать стандартными средствами nginx?
>
> --
> Валентин Бартенев

Добрый день, Валентин

прошу прощения за задержку в ответе - проверяли разные комбинации nginx.

nginx-upload-progress-module и headers-more-nginx-module были у нас в
конфигурации скорее исторически, необходимости в них, как оказалось,
нет.
Поэтому, создали конфигурацию без сторонних модулей , с одной простой
функцией - приём SSL HTTP и проксирование:

# nginx -V
nginx version: nginx/1.10.2
built with LibreSSL 2.4.4
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--modules-path=/usr/local/libexec/nginx
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_realip_module
--with-http_stub_status_module --with-pcre --with-threads
--with-http_ssl_module --with-http_v2_module
--with-openssl=../libressl-2.4.4 --with-debug

И nginx продолжает крашится (некоторые приватные данные были заменены на ХХХ):

#0  ngx_http_v2_write_handler (wev=0x851458eb0) at src/http/v2/ngx_http_v2.c:444
444 wev = stream->request->connection->write;
[New Thread 801c16000 (LWP 100649/)]
(gdb) bt
#0  ngx_http_v2_write_handler (wev=0x851458eb0) at src/http/v2/ngx_http_v2.c:444
#1  0x0048cb23 in ngx_kqueue_process_events
(cycle=0x801de9050, timer=213, flags=1) at
src/event/modules/ngx_kqueue_module.c:669
#2  0x0047b3fa in ngx_process_events_and_timers
(cycle=0x801de9050) at src/event/ngx_event.c:242
#3  0x00489b9a in ngx_worker_process_cycle (cycle=0x801de9050,
data=0x1) at src/os/unix/ngx_process_cycle.c:753
#4  0x00486cad in ngx_spawn_process (cycle=0x801de9050,
proc=0x489a90 , data=0x1, name=0x6a6192
"worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#5  0x00488890 in ngx_start_worker_processes
(cycle=0x801de9050, n=8, type=-4) at
src/os/unix/ngx_process_cycle.c:358
#6  0x00488657 in ngx_master_process_cycle (cycle=0x801de9050)
at src/os/unix/ngx_process_cycle.c:243
#7  0x00447672 in main (argc=1, argv=0x7fffebb8) at
src/core/nginx.c:367
Current language:  auto; currently minimal
(gdb) i locals
rc = -2
q = (ngx_queue_t *) 0x85379ccb0
c = (ngx_connection_t *) 0x84a4c65b0
stream = (ngx_http_v2_stream_t *) 0x85379cc60
h2c = (ngx_http_v2_connection_t *) 0x85797c220
(gdb) p *q
$1 = {prev =

Re: Очередной вопрос nginx+php

Re: Очередной вопрос nginx+php

Re: nginx/1.10.2 crashes in ngx_http_v2_write_handler

Re: nginx/1.10.2 crashes in ngx_http_v2_write_handler

Re: Очередной вопрос nginx+php

Re: Очередной вопрос nginx+php

Re: Очередной вопрос nginx+php

Re: Очередной вопрос nginx+php

Re: nginx/1.10.2 crashes in ngx_http_v2_write_handler

Очередной вопрос nginx+php

Re: nginx/1.10.2 crashes in ngx_http_v2_write_handler

11 matches

Site Navigation

Mail list logo

Footer information