From nginx-forum на forum.nginx.org  Fri Sep  1 10:54:49 2017
From: nginx-forum на forum.nginx.org (growield)
Date: Fri, 01 Sep 2017 06:54:49 -0400
Subject: change root to uplevel folder
Message-ID: <0c58193f6fec21eccf225a8bd2bac5d1.NginxMailingListRussian@forum.nginx.org>

Hello. I have  site that have root /www/site
but i must to get some file from /www. How can i change root only for one
this file?

For example
some.domain.com/index.php?key=ss
if $key is number rewrite to
some.domain.com/test.php?key=12

But  test.php locates in /www not in /www/site

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


From alex.hha на gmail.com  Fri Sep  1 14:03:33 2017
From: alex.hha на gmail.com (Alex Domoradov)
Date: Fri, 1 Sep 2017 17:03:33 +0300
Subject: change root to uplevel folder
In-Reply-To: <0c58193f6fec21eccf225a8bd2bac5d1.NginxMailingListRussian@forum.nginx.org>
References: <0c58193f6fec21eccf225a8bd2bac5d1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAK90gp716TYYs=Ry_pidsb+Z3YfeLDLemvCp6iOpUx6jjHQo9w@mail.gmail.com>

You can use location and there override root

location =/test.php {
   root /www;
   ...
}

On Fri, Sep 1, 2017 at 1:54 PM, growield <nginx-forum на forum.nginx.org>
wrote:

> Hello. I have  site that have root /www/site
> but i must to get some file from /www. How can i change root only for one
> this file?
>
> For example
> some.domain.com/index.php?key=ss
> if $key is number rewrite to
> some.domain.com/test.php?key=12
>
> But  test.php locates in /www not in /www/site
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276213,276213#msg-276213
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170901/a6c1f45e/attachment.html>

From nginx на kinetiksoft.com  Sun Sep  3 13:19:27 2017
From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=)
Date: Sun, 03 Sep 2017 16:19:27 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQu9C10LPQsNC70YzQvdC+0LUg0L/RgNC+0LrRgdC40YDQvtCy0LA=?=
 =?UTF-8?B?0L3QuNC1INGB0LDQudGC0LAg0YHRgNC10LTRgdGC0LLQsNC80Lggbmdpbng=?=
In-Reply-To: <CAK90gp6pEUweZ=nuwPVFu7Ox+-fUotY=FitHS1O6Xoj2jy11Sg@mail.gmail.com>
References: <CAL9wMxVNUFQG4aKjrUVkgyP=XAimLoR=miYuweo44LnMbRWhVw@mail.gmail.com>
 <1522853.6mXDAIU1tX@cybernote>
 <CAK90gp6pEUweZ=nuwPVFu7Ox+-fUotY=FitHS1O6Xoj2jy11Sg@mail.gmail.com>
Message-ID: <12042471.hS4pSrN5Ko@cybernote>

На предмет совпадения с ипом вражеского прокси, конечно же. Вычислять 
ипы вражеского прокси можно, анализируя логи на частоту запросов с IP. Все 
IP, rps с которых, выше определенного порога - прокси. Вы же не делаете 
realip на * ?

Собственно, как альтернатива, превентивно можно отрубить вражеские 
прокси просто поставив limit_req с одного IP.

В письме от среда, 30 августа 2017 г. 12:20:11 MSK пользователь Alex 
Domoradov написал:
> > Вариант сходу - проверять $remote_addr, Вам не подойдет?
> 
> проверять на предмет чего?
> 
> 2017-08-30 10:50 GMT+03:00 Иван <nginx на kinetiksoft.com>:
> 
> 
> > Здравствуйте!
> >
> >
> >
> > Вариант сходу - проверять $remote_addr, Вам не подойдет?
> >
> >
> >
> > С уважением, Иван.
> >
> >
> >
> > В письме от среда, 30 августа 2017 г. 10:38:45 MSK пользователь Dmitry
> > Simonov написал:
> > 
> > > Коллеги!
> > >
> > >
> > >
> > > А есть какой-то более-менее достоверный способ определить, что вот 
эти
> > > и эти клиенты, - это nginx, который проксирует наш сервис куда-то на
> > > левый домен.
> > >
> > >
> > >
> > > В моём случае оригинал www.setup.ru, а проксированная нелегальная
> > > копия - www.britash.top
> > >
> > >
> > >
> > > Цель - запретить проксирование.
> > >
> > >
> > >
> > > ---
> > > Dmitriy V. Simonov
> > > _______________________________________________
> > > 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
> >
> >


From nginx-forum на forum.nginx.org  Sun Sep  3 13:37:24 2017
From: nginx-forum на forum.nginx.org (Seriyyy95)
Date: Sun, 03 Sep 2017 09:37:24 -0400
Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDRjtGCINGA0LXQs9GD0LvRj9GA0L3Ri9C1INCy0Ys=?=
 =?UTF-8?B?0YDQsNC20LXQvdC40Y8g0LIgbG9jYXRpb24=?=
Message-ID: <1a781e1b82b6fbdd5e0e67a912e9787c.NginxMailingListRussian@forum.nginx.org>

Недавно обновил версию Nginx и столкнулся с проблемой, что перестали
работать регулярные выражения в location вида:

location ~ строка {}

Хотя если просто написать location = /строка {} то это срабатывает, но нужно
именно регулярное выражение, чтобы искалась не именно эта строка, любая URL,
которая содержит нужную подстроку. Например, хочу заблокировать доступ к
всем файлам AI-BOLIT на сервере, для этого делаю:

location ~ ^/(AI-BOLIT|AIBOLIT|ai-bolit) {
 deny all;
}

Но эффекта 0, url без проблем открываются, хотя на
http://nginx.viraptor.info/ показано что этот запрос должен работать.
Дистрибутив CentOS 7, программу брал из Brouken repo. Вот вывод nginx -v:

nginx -V
nginx version: nginx/1.13.4
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) 
built with OpenSSL 1.0.2l  25 May 2017
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
--lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx
--with-compat --with-file-aio --with-threads --with-http_addition_module
--with-http_auth_request_module --with-http_dav_module
--with-http_flv_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module
--with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-openssl=openssl-1.0.2l
--with-http_stub_status_module --with-http_sub_module --with-http_v2_module
--with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module
--with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
--with-ld-opt=

В чем может быть причина и что делать?

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


From nginx-forum на forum.nginx.org  Sun Sep  3 15:20:06 2017
From: nginx-forum на forum.nginx.org (Bonintr)
Date: Sun, 03 Sep 2017 11:20:06 -0400
Subject: connect() failed (11: Resource temporarily unavailable) while
 connecting to upstream
In-Reply-To: <f4079bd81003131136v2c10f389r49463d9f277beb4a@mail.gmail.com>
References: <f4079bd81003131136v2c10f389r49463d9f277beb4a@mail.gmail.com>
Message-ID: <8199d0e036c3102d71e10851a7cf808d.NginxMailingListRussian@forum.nginx.org>

Вы можете воспользоваться сберегательной альтернативой, чтобы помочь вам:
http: //www.videoconverterfactory.com/tips/savefrom-net-alternative.html
Там есть чек. Надеюсь, что это может быть полезно.ыть полезно.

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


From nginx-forum на forum.nginx.org  Mon Sep  4 07:23:50 2017
From: nginx-forum на forum.nginx.org (oradba25)
Date: Mon, 04 Sep 2017 03:23:50 -0400
Subject: =?UTF-8?B?0J/RgNC+0LHRgNC+0YEgaHR0cHMg0L3QsCDQv9C+0YDRgiwg0L7RgtC70LjRh9C9?=
 =?UTF-8?B?0YvQuSDQvtGCIDQ0Mw==?=
Message-ID: <0370103cbbf48ee6a5b1240b0ad54bfb.NginxMailingListRussian@forum.nginx.org>

Здравствуйте

Потребовалось слушать SSL на стандартном 443 порту и пробрасывать на Tomcat
слушающий SSL на порту 11443
В настройках
listen 443 ssl;
ssl_certificate ...
ssl_certificate_key ...
location /application {
    proxy_pass https://192.168.213.13:11443;
}

При запросе долго ждет, затем отваливается про таймауту
Если Tomcat слушает на 443 порту и в конфигурации соответственно, proxy_pass
https://192.168.213.13:443; то все проходит без проблем

Особенности:
-- для конкретно этого приложения нельзя использовать HTTPS -> HTTP (с
некоторыми браузерами возникают проблемы), для других приложений это
используется
-- используется TRANSPARENT прокси (там еще stream надо передавать и
определять адрес клиента)
-- сертификат самозаверенный и не соответствует адресу (для nginx слушается
на отдельном интерфейсе)

С машинки с nginx-ом curl -k https://192.168.213.13:11443/application отдает
страничку

Может нужно какие-то дополнительные настройки указывать?

Спасибо

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


From alex на vorona.com.ua  Mon Sep  4 07:33:01 2017
From: alex на vorona.com.ua (Alex Vorona)
Date: Mon, 4 Sep 2017 10:33:01 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0YDQvtGBIGh0dHBzINC90LAg0L/QvtGA0YIsINC+0YLQu9C4?=
 =?UTF-8?B?0YfQvdGL0Lkg0L7RgiA0NDM=?=
In-Reply-To: <0370103cbbf48ee6a5b1240b0ad54bfb.NginxMailingListRussian@forum.nginx.org>
References: <0370103cbbf48ee6a5b1240b0ad54bfb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <ba438cba-8581-7a42-b96b-beae90fa0b8e@vorona.com.ua>

Здравствуйте,

nginx у меня без проблем слушает https 443 и проксирует на tomcat https 
на нестандартный порт. Правда сертификаты LetsEncrypt.

Посмотрите, что в error-логах nginx.

--
Alex Vorona

From basil на vpm.net.ua  Mon Sep  4 07:33:19 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Mon, 4 Sep 2017 10:33:19 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0YDQvtGBIGh0dHBzINC90LAg0L/QvtGA0YIsINC+0YLQu9C4?=
 =?UTF-8?B?0YfQvdGL0Lkg0L7RgiA0NDM=?=
In-Reply-To: <0370103cbbf48ee6a5b1240b0ad54bfb.NginxMailingListRussian@forum.nginx.org>
References: <0370103cbbf48ee6a5b1240b0ad54bfb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAMPJU7CR-dwywrkF2=FUyB4to+2oN0OU0iw1B29r3SH8UNfHFQ@mail.gmail.com>

коннект с хоста нгинкса проверили ?

telnet 192.168.213.13 11443

4 сентября 2017 г., 10:23 пользователь oradba25 <nginx-forum на forum.nginx.org
> написал:

> Здравствуйте
>
> Потребовалось слушать SSL на стандартном 443 порту и пробрасывать на Tomcat
> слушающий SSL на порту 11443
> В настройках
> listen 443 ssl;
> ssl_certificate ...
> ssl_certificate_key ...
> location /application {
>     proxy_pass https://192.168.213.13:11443;
> }
>
> При запросе долго ждет, затем отваливается про таймауту
> Если Tomcat слушает на 443 порту и в конфигурации соответственно,
> proxy_pass
> https://192.168.213.13:443; то все проходит без проблем
>
> Особенности:
> -- для конкретно этого приложения нельзя использовать HTTPS -> HTTP (с
> некоторыми браузерами возникают проблемы), для других приложений это
> используется
> -- используется TRANSPARENT прокси (там еще stream надо передавать и
> определять адрес клиента)
> -- сертификат самозаверенный и не соответствует адресу (для nginx слушается
> на отдельном интерфейсе)
>
> С машинки с nginx-ом curl -k https://192.168.213.13:11443/application
> отдает
> страничку
>
> Может нужно какие-то дополнительные настройки указывать?
>
> Спасибо
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276241,276241#msg-276241
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170904/600f3972/attachment-0001.html>

From basil на vpm.net.ua  Mon Sep  4 07:34:07 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Mon, 4 Sep 2017 10:34:07 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0YDQvtGBIGh0dHBzINC90LAg0L/QvtGA0YIsINC+0YLQu9C4?=
 =?UTF-8?B?0YfQvdGL0Lkg0L7RgiA0NDM=?=
In-Reply-To: <CAMPJU7CR-dwywrkF2=FUyB4to+2oN0OU0iw1B29r3SH8UNfHFQ@mail.gmail.com>
References: <0370103cbbf48ee6a5b1240b0ad54bfb.NginxMailingListRussian@forum.nginx.org>
 <CAMPJU7CR-dwywrkF2=FUyB4to+2oN0OU0iw1B29r3SH8UNfHFQ@mail.gmail.com>
Message-ID: <CAMPJU7DGmms_Tk-Eob+qoz76N=AnqW7A0XUSM9n7cAdYbWzAyA@mail.gmail.com>

затупил :)

4 сентября 2017 г., 10:33 пользователь Vasiliy P. Melnik <basil на vpm.net.ua>
написал:

> коннект с хоста нгинкса проверили ?
>
> telnet 192.168.213.13 11443
>
> 4 сентября 2017 г., 10:23 пользователь oradba25 <
> nginx-forum на forum.nginx.org> написал:
>
>> Здравствуйте
>>
>> Потребовалось слушать SSL на стандартном 443 порту и пробрасывать на
>> Tomcat
>> слушающий SSL на порту 11443
>> В настройках
>> listen 443 ssl;
>> ssl_certificate ...
>> ssl_certificate_key ...
>> location /application {
>>     proxy_pass https://192.168.213.13:11443;
>> }
>>
>> При запросе долго ждет, затем отваливается про таймауту
>> Если Tomcat слушает на 443 порту и в конфигурации соответственно,
>> proxy_pass
>> https://192.168.213.13:443; то все проходит без проблем
>>
>> Особенности:
>> -- для конкретно этого приложения нельзя использовать HTTPS -> HTTP (с
>> некоторыми браузерами возникают проблемы), для других приложений это
>> используется
>> -- используется TRANSPARENT прокси (там еще stream надо передавать и
>> определять адрес клиента)
>> -- сертификат самозаверенный и не соответствует адресу (для nginx
>> слушается
>> на отдельном интерфейсе)
>>
>> С машинки с nginx-ом curl -k https://192.168.213.13:11443/application
>> отдает
>> страничку
>>
>> Может нужно какие-то дополнительные настройки указывать?
>>
>> Спасибо
>>
>> Posted at Nginx Forum: https://forum.nginx.org/read.p
>> hp?21,276241,276241#msg-276241
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170904/565fea11/attachment.html>

From nginx-forum на forum.nginx.org  Mon Sep  4 09:17:00 2017
From: nginx-forum на forum.nginx.org (oradba25)
Date: Mon, 04 Sep 2017 05:17:00 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0YDQvtGBIGh0dHBzINC90LAg0L/QvtGA0YIsINC+0YLQu9C4?=
 =?UTF-8?B?0YfQvdGL0Lkg0L7RgiA0NDM=?=
In-Reply-To: <CAMPJU7DGmms_Tk-Eob+qoz76N=AnqW7A0XUSM9n7cAdYbWzAyA@mail.gmail.com>
References: <CAMPJU7DGmms_Tk-Eob+qoz76N=AnqW7A0XUSM9n7cAdYbWzAyA@mail.gmail.com>
Message-ID: <37ee9065dab868add034fbcb387a1247.NginxMailingListRussian@forum.nginx.org>

Всем спасибо

Для TRANSPARENT-proxy были настроены iptables правила только для 443 и 8080
Добавил нужные порты и все поехало

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


From mdounin на mdounin.ru  Mon Sep  4 12:52:45 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 4 Sep 2017 15:52:45 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0Y7RgiDRgNC10LPRg9C70Y/RgNC90YvQtSA=?=
 =?UTF-8?B?0LLRi9GA0LDQttC10L3QuNGPINCyIGxvY2F0aW9u?=
In-Reply-To: <1a781e1b82b6fbdd5e0e67a912e9787c.NginxMailingListRussian@forum.nginx.org>
References: <1a781e1b82b6fbdd5e0e67a912e9787c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170904125244.GK93611@mdounin.ru>

Hello!

On Sun, Sep 03, 2017 at 09:37:24AM -0400, Seriyyy95 wrote:

> Недавно обновил версию Nginx и столкнулся с проблемой, что перестали
> работать регулярные выражения в location вида:
> 
> location ~ строка {}
> 
> Хотя если просто написать location = /строка {} то это срабатывает, но нужно
> именно регулярное выражение, чтобы искалась не именно эта строка, любая URL,
> которая содержит нужную подстроку. Например, хочу заблокировать доступ к
> всем файлам AI-BOLIT на сервере, для этого делаю:
> 
> location ~ ^/(AI-BOLIT|AIBOLIT|ai-bolit) {
>  deny all;
> }
> 
> Но эффекта 0, url без проблем открываются, хотя на
> http://nginx.viraptor.info/ показано что этот запрос должен работать.
> Дистрибутив CentOS 7, программу брал из Brouken repo. Вот вывод nginx -v:

[...]

> В чем может быть причина и что делать?

Наиболее частая причина подобных проблем с регулярными выражениями - 
в том, что они выполняются последовательно, и используется 
первое совпадение.  Так, если у вас в начале конфига виртуального 
сервера есть запись вида "location ~ / { ... }", то никакие другие 
регулярные выражения работать не будут, ибо первое совпадение 
случится именно у этого location'а, и именно он будет использован 
для обработки запроса.

Чтобы такого не было - нужно чётко следить за тем, какие 
location'ы, заданные регулярными выражениями, используются в блоке 
server{}.  А лучше - по возможности не использовать их, а 
использовать обычные префиксные location'ы, где поведение гораздо 
более интуитивно и легче поддаётся контролю администратором.

Подробнее об этой и других проблемах поддержки больших 
конфигураций можно узнать из доклада Игоря
"Масштабируемая конфигурация nginx".  Видео доклада и его 
расшифровка есть тут:

https://habrahabr.ru/company/oleg-bunin/blog/313666/

-- 
Maxim Dounin
http://nginx.org/

From mdounin на mdounin.ru  Tue Sep  5 15:42:41 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 5 Sep 2017 18:42:41 +0300
Subject: nginx-1.13.5
Message-ID: <20170905154241.GS93611@mdounin.ru>

Изменения в nginx 1.13.5                                          05.09.2017

    *) Добавление: переменная $ssl_client_escaped_cert.

    *) Исправление: директива ssl_session_ticket_key и параметр include
       директивы geo не работали на Windows.

    *) Исправление: на 32-битных платформах при запросе более 4 гигабайт с
       помощью нескольких диапазонов возвращалась некорректная длина ответа.

    *) Исправление: директива "expires modified" и обработка строки If-Range
       заголовка запроса не учитывали время последнего изменения ответа,
       если использовалось проксирование без кэширования.


-- 
Maxim Dounin
http://nginx.org/

From kiav1976 на mail.ru  Wed Sep  6 14:16:10 2017
From: kiav1976 на mail.ru (=?UTF-8?B?0JDQvdCw0YLQvtC70LjQuSDQmtC40YDRgdCw0L3QvtCy?=)
Date: Wed, 6 Sep 2017 17:16:10 +0300
Subject: =?UTF-8?B?0KfRgtC+INC+0YHRgtCw0LLQuNGCINCyINC70L7Qs9Cw0YUgbmdpbngg0L/RgNC4?=
 =?UTF-8?B?INC/0L7RgtC10YDQtSDRgdCy0Y/Qt9C4INC80LXQttC00YMg0YHQtdGA0LI=?=
 =?UTF-8?B?0LXRgNC+0Lwg0Lgg0LrQu9C40LXQvdGC0L7QvA==?=
Message-ID: <4b1c1635-f629-1d43-3e88-33050443eb60@mail.ru>

Ситуация: Сервер получил запрос, подготовил ответ. Но клиент потерял 
связь с сервером (просто Инет такой) и не получил ответа.

Что будет в логах?

         access_log /var/www/httpd-logs/example.ru.access.log;
         error_log /var/www/httpd-logs/example.ru.error.log notice;

А если это хит не на статику, а на PHP?

         location / {
                 location ~ [^/]\.ph(p\d*|tml)$ {
                         try_files /does_not_exists @fallback;
                 }
                 location ~* 
^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
                         try_files $uri $uri/ @fallback;
                 }
                 location / {
                         try_files /does_not_exists @fallback;
                 }
         }
         location @fallback {
                 proxy_pass http://127.0.0.1:8080;
                 proxy_redirect http://127.0.0.1:8080 /;
                 proxy_set_header Host $host;
                 proxy_set_header X-Forwarded-For 
$proxy_add_x_forwarded_for;
                 proxy_set_header X-Forwarded-Proto $scheme;
                 access_log off;
                 proxy_set_header X-Forwarded-Port $server_port;
         }

В какие логи и кто что запишет (на прокси Apache, PHP в виде FastCGI)?

-- 
С уважением,
Анатолий Кирсанов


From nginx-forum на forum.nginx.org  Wed Sep  6 14:33:38 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Wed, 06 Sep 2017 10:33:38 -0400
Subject: =?UTF-8?B?0J7Qv9GP0YLRjCAiY2FjaGUgZmlsZSBoYXMgdG9vIGxvbmcgaGVhZGVyIg==?=
Message-ID: <3d96321167595431e1a06c9f7ee76c41.NginxMailingListRussian@forum.nginx.org>

nginx/1.13.4 64bit под CentOS7.
Редко, но регулярно выдаёт ошибку "cache file ... has too long header"

Прочёл всё, что написано по данному поводу:
1) https://forum.nginx.org/read.php?21,243579,243589#msg-243589
2)
http://nginx.2469901.n2.nabble.com/cache-file-has-too-long-header-bug-td7594976.html

proxy_buffer_size установлен в 8k и не менялся несколько месяцев.

Сайтов кэшируется много, все настройки у всех одинаковые, но почти все
ошибки происходят только у одного, причём не самого нагруженного. На
некоторых файлах - больше одного раза, т.е. вариант со старыми кэш-файлами,
созданными с другим proxy_buffer_size, отпадает.

Служебный заголовок с заголовком HTTP-ответа во всех файлах занимают меньше
килобайта, проверял командой:

find /home/.nginx/cache/.edge/user98023/ -type f -printf "%p  " -exec perl
-e 'my $len = 0; while(<>) { last if /^[\r\n]*$/; $len += length } print
"$len, $.\n"' '{}' ';'

Вопросы:

1) race condition при одновременном обновлении-чтении кэш-файла несколькими
воркерами ещё не побеждён?
В данный момент это наш единственный подозреваемый.

2) Какие данные имеет смысл дополнительно распечатывать в
http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_file_cache.c#l578 для
диагностики, кроме h->body_start и c->body_start?

К сожалению, ошибка происходит только на загруженных production, которые
мало подходят для экспериментов.

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


From mdounin на mdounin.ru  Wed Sep  6 16:07:09 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 6 Sep 2017 19:07:09 +0300
Subject: =?UTF-8?B?UmU6INCn0YLQviDQvtGB0YLQsNCy0LjRgiDQsiDQu9C+0LPQsNGFIG5naW54INC/?=
 =?UTF-8?B?0YDQuCDQv9C+0YLQtdGA0LUg0YHQstGP0LfQuCDQvNC10LbQtNGDINGB0LU=?=
 =?UTF-8?B?0YDQstC10YDQvtC8INC4INC60LvQuNC10L3RgtC+0Lw=?=
In-Reply-To: <4b1c1635-f629-1d43-3e88-33050443eb60@mail.ru>
References: <4b1c1635-f629-1d43-3e88-33050443eb60@mail.ru>
Message-ID: <20170906160709.GY93611@mdounin.ru>

Hello!

On Wed, Sep 06, 2017 at 05:16:10PM +0300, Анатолий Кирсанов wrote:

> Ситуация: Сервер получил запрос, подготовил ответ. Но клиент потерял 
> связь с сервером (просто Инет такой) и не получил ответа.
> 
> Что будет в логах?

В самом плохом случае - в логах будет 200 с полной длиной ответа, 
а о том, что клиент эти данные не получил, вы никак не узнаете.  
Так будет, если TCP-пакеты в момент отправки ответа до клиента 
перестали доходить, но ответ достаточно мал и полностью помещается 
в буфер сокета на отправку.  Соответственно nginx запишет ответ в 
сокет, и на этом обработка запроса успешно завершится.

В самом хорошем случае - в логах будет 200 и количество 
отправленных байт меньше, чем ожидаемая длина ответа, а в 
error_log'е что-нибудь про client timed out или ошибку отправки 
данных клиенту.

-- 
Maxim Dounin
http://nginx.org/

From kiav1976 на mail.ru  Wed Sep  6 17:52:25 2017
From: kiav1976 на mail.ru (=?UTF-8?B?0JDQvdCw0YLQvtC70LjQuSDQmtC40YDRgdCw0L3QvtCy?=)
Date: Wed, 6 Sep 2017 20:52:25 +0300
Subject: =?UTF-8?B?UmU6INCn0YLQviDQvtGB0YLQsNCy0LjRgiDQsiDQu9C+0LPQsNGFIG5naW54INC/?=
 =?UTF-8?B?0YDQuCDQv9C+0YLQtdGA0LUg0YHQstGP0LfQuCDQvNC10LbQtNGDINGB0LU=?=
 =?UTF-8?B?0YDQstC10YDQvtC8INC4INC60LvQuNC10L3RgtC+0Lw=?=
In-Reply-To: <20170906160709.GY93611@mdounin.ru>
References: <4b1c1635-f629-1d43-3e88-33050443eb60@mail.ru>
 <20170906160709.GY93611@mdounin.ru>
Message-ID: <e4830b6f-a68d-b125-7bd7-1aed7f40fd23@mail.ru>

Тогда совершенно непонятно что творится.

Страница на PHP успешно записала в лог данные. Есть метка времени когда 
пришел хит.

Но этого хита нет в логах посещений и ошибок. Как-будто его не было, 
этого хита.

Как такое возможно?

С уважением,
Анатолий Кирсанов

06.09.2017 19:07, Maxim Dounin пишет:
> Hello!
>
> On Wed, Sep 06, 2017 at 05:16:10PM +0300, Анатолий Кирсанов wrote:
>
>> Ситуация: Сервер получил запрос, подготовил ответ. Но клиент потерял
>> связь с сервером (просто Инет такой) и не получил ответа.
>>
>> Что будет в логах?
> В самом плохом случае - в логах будет 200 с полной длиной ответа,
> а о том, что клиент эти данные не получил, вы никак не узнаете.
> Так будет, если TCP-пакеты в момент отправки ответа до клиента
> перестали доходить, но ответ достаточно мал и полностью помещается
> в буфер сокета на отправку.  Соответственно nginx запишет ответ в
> сокет, и на этом обработка запроса успешно завершится.
>
> В самом хорошем случае - в логах будет 200 и количество
> отправленных байт меньше, чем ожидаемая длина ответа, а в
> error_log'е что-нибудь про client timed out или ошибку отправки
> данных клиенту.
>


From mdounin на mdounin.ru  Wed Sep  6 18:17:47 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 6 Sep 2017 21:17:47 +0300
Subject: =?UTF-8?B?UmU6INCn0YLQviDQvtGB0YLQsNCy0LjRgiDQsiDQu9C+0LPQsNGFIG5naW54INC/?=
 =?UTF-8?B?0YDQuCDQv9C+0YLQtdGA0LUg0YHQstGP0LfQuCDQvNC10LbQtNGDINGB0LU=?=
 =?UTF-8?B?0YDQstC10YDQvtC8INC4INC60LvQuNC10L3RgtC+0Lw=?=
In-Reply-To: <e4830b6f-a68d-b125-7bd7-1aed7f40fd23@mail.ru>
References: <4b1c1635-f629-1d43-3e88-33050443eb60@mail.ru>
 <20170906160709.GY93611@mdounin.ru>
 <e4830b6f-a68d-b125-7bd7-1aed7f40fd23@mail.ru>
Message-ID: <20170906181746.GZ93611@mdounin.ru>

Hello!

On Wed, Sep 06, 2017 at 08:52:25PM +0300, Анатолий Кирсанов wrote:

> Тогда совершенно непонятно что творится.
> 
> Страница на PHP успешно записала в лог данные. Есть метка времени когда 
> пришел хит.
> 
> Но этого хита нет в логах посещений и ошибок. Как-будто его не было, 
> этого хита.
> 
> Как такое возможно?

Если говорить про конкретный конфиг, который вы привели в исходном 
письме, то в нём отключены access-логи для обращений к бекенду.

-- 
Maxim Dounin
http://nginx.org/

From kiav1976 на mail.ru  Wed Sep  6 21:36:14 2017
From: kiav1976 на mail.ru (=?UTF-8?B?0JDQvdCw0YLQvtC70LjQuSDQmtC40YDRgdCw0L3QvtCy?=)
Date: Thu, 7 Sep 2017 00:36:14 +0300
Subject: =?UTF-8?B?UmU6INCn0YLQviDQvtGB0YLQsNCy0LjRgiDQsiDQu9C+0LPQsNGFIG5naW54INC/?=
 =?UTF-8?B?0YDQuCDQv9C+0YLQtdGA0LUg0YHQstGP0LfQuCDQvNC10LbQtNGDINGB0LU=?=
 =?UTF-8?B?0YDQstC10YDQvtC8INC4INC60LvQuNC10L3RgtC+0Lw=?=
In-Reply-To: <20170906181746.GZ93611@mdounin.ru>
References: <4b1c1635-f629-1d43-3e88-33050443eb60@mail.ru>
 <20170906160709.GY93611@mdounin.ru>
 <e4830b6f-a68d-b125-7bd7-1aed7f40fd23@mail.ru>
 <20170906181746.GZ93611@mdounin.ru>
Message-ID: <7b718058-d9cc-cf5f-0784-557b9015b892@mail.ru>

Удивлен. На уровне server логи прописаны. В location они уже не наследуются?

С уважением,
Анатолий Кирсанов

06.09.2017 21:17, Maxim Dounin пишет:
> Hello!
>
> On Wed, Sep 06, 2017 at 08:52:25PM +0300, Анатолий Кирсанов wrote:
>
>> Тогда совершенно непонятно что творится.
>>
>> Страница на PHP успешно записала в лог данные. Есть метка времени когда
>> пришел хит.
>>
>> Но этого хита нет в логах посещений и ошибок. Как-будто его не было,
>> этого хита.
>>
>> Как такое возможно?
> Если говорить про конкретный конфиг, который вы привели в исходном
> письме, то в нём отключены access-логи для обращений к бекенду.
>


From andrey на kopeyko.ru  Wed Sep  6 22:24:52 2017
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Thu, 07 Sep 2017 01:24:52 +0300
Subject: =?UTF-8?B?UmU6INCn0YLQviDQvtGB0YLQsNCy0LjRgiDQsiDQu9C+0LPQsNGFIG5naW54INC/?=
 =?UTF-8?B?0YDQuCDQv9C+0YLQtdGA0LUg0YHQstGP0LfQuCDQvNC10LbQtNGDINGB0LU=?=
 =?UTF-8?B?0YDQstC10YDQvtC8INC4INC60LvQuNC10L3RgtC+0Lw=?=
In-Reply-To: <7b718058-d9cc-cf5f-0784-557b9015b892@mail.ru>
References: <4b1c1635-f629-1d43-3e88-33050443eb60@mail.ru>
 <20170906160709.GY93611@mdounin.ru>
 <e4830b6f-a68d-b125-7bd7-1aed7f40fd23@mail.ru>
 <20170906181746.GZ93611@mdounin.ru>
 <7b718058-d9cc-cf5f-0784-557b9015b892@mail.ru>
Message-ID: <d8eaf4cccc12aaa388c3c1dca1c19158@kopeyko.ru>

Анатолий Кирсанов писал 2017-09-07 00:36:
> Удивлен. На уровне server логи прописаны. В location они уже не 
> наследуются?

Они наследовались бы, если бы вы не переопределили access_log в location 
@fallback (где обработка запроса и логирование его результатов и 
происходят).


> 06.09.2017 21:17, Maxim Dounin пишет:
>> 
>>> Как такое возможно?
>> Если говорить про конкретный конфиг, который вы привели в исходном
>> письме, то в нём отключены access-логи для обращений к бекенду.
>> 

-- 
Best regards,
Andrey A. Kopeyko <andrey на kopeyko.ru>

From nginx-forum на forum.nginx.org  Thu Sep  7 08:20:24 2017
From: nginx-forum на forum.nginx.org (RockerMan)
Date: Thu, 07 Sep 2017 04:20:24 -0400
Subject: =?UTF-8?B?0J/QtdGA0LXQtNCw0YfQsCDRgNC10LDQu9GM0L3QvtCz0L4gSVAg0YfQtdGA0LU=?=
 =?UTF-8?B?0LcgTmdpbngg0L3QsCBNUyBJSVMg0YHQtdGA0LLQtdGA?=
Message-ID: <d215f7ac6b4247ab84f1a18ff2d5a1db.NginxMailingListRussian@forum.nginx.org>

Добрый день

Есть nginx, работающий в качестве реверс-прокси. За ним стоит MS IIS. У него
в логах запросы от клиента идут не от внешнего клиентского IP адреса, а от
адреса Nginx. В настройках nginx проброс реального IP прописан:
-
        location / {
            proxy_pass https://*.*.*.*/clientproxy/;
            proxy_set_header  X-Real-IP $remote_addr;
            proxy_set_header  X-Forwarded-For
$proxy_add_x_forwarded_for,$remote_addr;
            }
-
В случае Apache в качестве бэкенд сервера рекомендуют на нем установить и
настроить:
-
Forwarding real remote IP from nginx to apache actually requires
mod_remoteip module installed & enabled in httpd.conf on the apache side.
Required proxy_set_header options in the server block:
server {
    ...
    proxy_set_header    X-Real-IP        $remote_addr;
    proxy_set_header    X-Forwarded-For  $proxy_add_x_forwarded_for;
    ...
}

On the apache side you should enable the required module with:
LoadModule remoteip_module modules/mod_remoteip.so

and set this directives:
RemoteIPHeader X-Real-IP
RemoteIPInternalProxy 127.0.0.1

replace 127.0.0.1 with your nginx IP if needed...
-

Знатоки IIS, подскажите плз, есть у него аналогичный модуль? и как его
настроить, если такой имеется?

Спасибо.

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


From chipitsine на gmail.com  Thu Sep  7 09:36:18 2017
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 7 Sep 2017 14:36:18 +0500
Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LTQsNGH0LAg0YDQtdCw0LvRjNC90L7Qs9C+IElQINGH0LU=?=
 =?UTF-8?B?0YDQtdC3IE5naW54INC90LAgTVMgSUlTINGB0LXRgNCy0LXRgA==?=
In-Reply-To: <d215f7ac6b4247ab84f1a18ff2d5a1db.NginxMailingListRussian@forum.nginx.org>
References: <d215f7ac6b4247ab84f1a18ff2d5a1db.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHS12bBRKDfaY=UuEahVJUEcbpzhx5wb8VAW+PG70xkYA@mail.gmail.com>

7 сентября 2017 г., 13:20 пользователь RockerMan <
nginx-forum на forum.nginx.org> написал:

> Добрый день
>
> Есть nginx, работающий в качестве реверс-прокси. За ним стоит MS IIS. У
> него
> в логах запросы от клиента идут не от внешнего клиентского IP адреса, а от
> адреса Nginx. В настройках nginx проброс реального IP прописан:
> -
>         location / {
>             proxy_pass https://*.*.*.*/clientproxy/;
>             proxy_set_header  X-Real-IP $remote_addr;
>             proxy_set_header  X-Forwarded-For
> $proxy_add_x_forwarded_for,$remote_addr;
>             }
> -
> В случае Apache в качестве бэкенд сервера рекомендуют на нем установить и
> настроить:
> -
> Forwarding real remote IP from nginx to apache actually requires
> mod_remoteip module installed & enabled in httpd.conf on the apache side.
> Required proxy_set_header options in the server block:
> server {
>     ...
>     proxy_set_header    X-Real-IP        $remote_addr;
>     proxy_set_header    X-Forwarded-For  $proxy_add_x_forwarded_for;
>     ...
> }
>
> On the apache side you should enable the required module with:
> LoadModule remoteip_module modules/mod_remoteip.so
>
> and set this directives:
> RemoteIPHeader X-Real-IP
> RemoteIPInternalProxy 127.0.0.1
>
> replace 127.0.0.1 with your nginx IP if needed...
> -
>
> Знатоки IIS, подскажите плз, есть у него аналогичный модуль? и как его
> настроить, если такой имеется?
>


1. штатно (начиная с 8-й версии)

https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-85/enhanced-logging-for-iis85

2. модуль логирования (для предыдущих версий)

https://www.iis.net/downloads/microsoft/advanced-logging

3. arr helper

https://blogs.iis.net/anilr/client-ip-not-logged-on-content-server-when-using-arr


>
> Спасибо.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276283,276283#msg-276283
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170907/9e27d06d/attachment.html>

From nginx-forum на forum.nginx.org  Thu Sep  7 10:33:19 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Thu, 07 Sep 2017 06:33:19 -0400
Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0YwgImNhY2hlIGZpbGUgaGFzIHRvbyBsb25nIGhlYWRlciI=?=
In-Reply-To: <3d96321167595431e1a06c9f7ee76c41.NginxMailingListRussian@forum.nginx.org>
References: <3d96321167595431e1a06c9f7ee76c41.NginxMailingListRussian@forum.nginx.org>
Message-ID: <810dbe3ac8bd5feecf404fb84ef48733.NginxMailingListRussian@forum.nginx.org>

Написал патч для более подробной диагностики:
https://gist.github.com/ilyaevseev/f2c57519db829329f8e9f9aff5d51789

Попутно нашел ошибку в Nginx:
1) wget http://nginx-frontend/cached-upstream-file
2) ищем на nginx-сервере файл в кэше, удаляем всё, начиная от пары последних
строк заголовка HTTP-ответа
3) повторяем wget и он подвисает: "HTTP-запрос отправлен. Ожидание ответа...
Не получено никаких данных."

Проверил на 1.13.5 с моим патчем  и на 1.13.4 без патча.

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


From valintinr на tangramltd.com  Thu Sep  7 11:59:05 2017
From: valintinr на tangramltd.com (valintinr на tangramltd.com)
Date: Thu, 07 Sep 2017 14:59:05 +0300
Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCIHJlbG9hZCDQv9GA0Lggc3NsINGB0LXRgNGC?=
 =?UTF-8?B?0LjRhNC40LrQsNGC0LDRhSDRgSDQv9Cw0YDQvtC70LXQvA==?=
Message-ID: <7b43b853a98c58f9b99481bca822603f@tangramltd.com>

Здравствуйте!
Имеется последняя версия nginx (на старых тоже воспроизводится) и 
запароленный ssl сертификат, пароль ввожу вручную (Enter PEM pass 
phrase:), вариант с ssl_password_file в конфиге пока не подходит.
После "nginx -s reload" этот самый reload не происходит и в error.log 
получаем ошибку:

2017/09/07 07:44:08 [notice] 46875#0: signal process started
Enter PEM pass phrase:
2017/09/07 07:44:14 [emerg] 42290#0: 
SSL_CTX_use_PrivateKey_file("/usr/local/etc/ssl_certs_ps/nginx/wildcard_e.key") 
failed (SSL: error:2807106B:UI routines:UI_process:processing 
error:while reading strings error:0906406D:PEM 
routines:PEM_def_callback:problems getting password error:0906A068:PEM 
routines:PEM_do_header:bad password read error:140B0009:SSL 
routines:SSL_CTX_use_PrivateKey_file:PEM lib)

При тесте конфига/start/stop все работает, не работает только reload.

Версия и опции сборки:
banner на banner4-c1:~/nginx$ /home/banner/nginx/sbin/nginx -V
nginx version: nginx/1.13.5
built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
built with OpenSSL 1.1.0f  25 May 2017
TLS SNI support enabled
configure arguments: --prefix=/home/banner/nginx 
--conf-path=/home/banner/nginx/conf/nginx.conf 
--error-log-path=logs/error.log --user=banner --group=banner 
--with-http_ssl_module --with-openssl=/home/banner/src/openssl-1.1.0f 
--with-pcre=/home/banner/src/pcre-8.41 --with-http_realip_module 
--with-file-aio --with-http_gzip_static_module 
--with-http_stub_status_module --without-http_ssi_module 
--without-http_userid_module --without-http_geo_module 
--without-http_map_module --without-http_fastcgi_module 
--without-http_memcached_module --without-http_empty_gif_module 
--without-http_browser_module --without-mail_pop3_module 
--without-mail_smtp_module --without-mail_imap_module


Strace reload'а и stop'а в аттаче.

P.S пробовал паролить сертификат простым паролем только из цифр и букв - 
результат тот же.
----------- следущая часть -----------
Вложенный текст с неопределенной кодировкой был извлечен&hellip;
Имя: strace_reload.txt
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170907/1a125b76/attachment-0002.txt>
----------- следущая часть -----------
Вложенный текст с неопределенной кодировкой был извлечен&hellip;
Имя: strace_stop.txt
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170907/1a125b76/attachment-0003.txt>

From mdounin на mdounin.ru  Thu Sep  7 12:43:10 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 7 Sep 2017 15:43:10 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZWxvYWQg0L/RgNC4IHNzbCDRgdC1?=
 =?UTF-8?B?0YDRgtC40YTQuNC60LDRgtCw0YUg0YEg0L/QsNGA0L7Qu9C10Lw=?=
In-Reply-To: <7b43b853a98c58f9b99481bca822603f@tangramltd.com>
References: <7b43b853a98c58f9b99481bca822603f@tangramltd.com>
Message-ID: <20170907124310.GA93611@mdounin.ru>

Hello!

On Thu, Sep 07, 2017 at 02:59:05PM +0300, valintinr на tangramltd.com wrote:

> Здравствуйте!
> Имеется последняя версия nginx (на старых тоже воспроизводится) и 
> запароленный ssl сертификат, пароль ввожу вручную (Enter PEM pass 
> phrase:), вариант с ssl_password_file в конфиге пока не подходит.
> После "nginx -s reload" этот самый reload не происходит и в error.log 
> получаем ошибку:

И не может пройти, так как перезагрузка конфигурации происходит в 
master-процессе, который не имеет доступа к терминалу.  Нужно либо 
снимать пароль с ключа, либо использовать ssl_password_file.

Отмечу в скобках, что "nginx -s reload" - это такой сложный способ 
сказать "kill -HUP `cat /path/to/nginx.pid`", и вся происходящая в 
нём загрузка конфигурации нужна на самом деле только для того, 
чтобы найти путь к pid-файлу.

-- 
Maxim Dounin
http://nginx.org/

From valintinr на tangramltd.com  Thu Sep  7 12:47:35 2017
From: valintinr на tangramltd.com (valintinr на tangramltd.com)
Date: Thu, 07 Sep 2017 15:47:35 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZWxvYWQg0L/RgNC4IHNzbCDRgdC1?=
 =?UTF-8?B?0YDRgtC40YTQuNC60LDRgtCw0YUg0YEg0L/QsNGA0L7Qu9C10Lw=?=
In-Reply-To: <20170907124310.GA93611@mdounin.ru>
References: <7b43b853a98c58f9b99481bca822603f@tangramltd.com>
 <20170907124310.GA93611@mdounin.ru>
Message-ID: <54f955eb51c9aa6f535a601a88edcd3e@tangramltd.com>

Maxim Dounin писал 2017-09-07 15:43:
> Hello!
> 
> On Thu, Sep 07, 2017 at 02:59:05PM +0300, valintinr на tangramltd.com 
> wrote:
> 
>> Здравствуйте!
>> Имеется последняя версия nginx (на старых тоже воспроизводится) и
>> запароленный ssl сертификат, пароль ввожу вручную (Enter PEM pass
>> phrase:), вариант с ssl_password_file в конфиге пока не подходит.
>> После "nginx -s reload" этот самый reload не происходит и в error.log
>> получаем ошибку:
> 
> И не может пройти, так как перезагрузка конфигурации происходит в
> master-процессе, который не имеет доступа к терминалу.  Нужно либо
> снимать пароль с ключа, либо использовать ssl_password_file.
Ясно, спасибо.

From mdounin на mdounin.ru  Thu Sep  7 16:54:05 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 7 Sep 2017 19:54:05 +0300
Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0YwgImNhY2hlIGZpbGUgaGFzIHRvbyBsb25nIGhlYWRlciI=?=
In-Reply-To: <810dbe3ac8bd5feecf404fb84ef48733.NginxMailingListRussian@forum.nginx.org>
References: <3d96321167595431e1a06c9f7ee76c41.NginxMailingListRussian@forum.nginx.org>
 <810dbe3ac8bd5feecf404fb84ef48733.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170907165405.GI93611@mdounin.ru>

Hello!

On Thu, Sep 07, 2017 at 06:33:19AM -0400, Ilya Evseev wrote:

> Написал патч для более подробной диагностики:
> https://gist.github.com/ilyaevseev/f2c57519db829329f8e9f9aff5d51789
> 
> Попутно нашел ошибку в Nginx:
> 1) wget http://nginx-frontend/cached-upstream-file
> 2) ищем на nginx-сервере файл в кэше, удаляем всё, начиная от пары последних
> строк заголовка HTTP-ответа
> 3) повторяем wget и он подвисает: "HTTP-запрос отправлен. Ожидание ответа...
> Не получено никаких данных."

Патч ниже должен помочь.

# HG changeset patch
# User Maxim Dounin <mdounin на mdounin.ru>
# Date 1504803092 -10800
#      Thu Sep 07 19:51:32 2017 +0300
# Node ID 74c7990ae3c7a7c4a8779ea6340d044108e24e98
# Parent  97e138ddbfcb476f583d95ea74ff0eb27e81478a
Upstream: better handling of invalid headers in cache files.

If cache file is truncated, it is possible that u->process_header()
will return NGX_AGAIN.  Added appropriate handling of this case by
changing the error to NGX_HTTP_UPSTREAM_INVALID_HEADER.

Also, added appropriate logging of this and NGX_HTTP_UPSTREAM_INVALID_HEADER
cases at the "crit" level.  Note that this will result in duplicate logging
in case of NGX_HTTP_UPSTREAM_INVALID_HEADER.  While this is something better
to avoid, it is considered to be an overkill to implement cache-specific
error logging in u->process_header().

Additionally, u->buffer.start is now reset to be able to receive a new
response, and u->cache_status set to MISS to provide the value in the
$upstream_cache_status variable, much like it happens on other cache file
errors detected by ngx_http_file_cache_read(), instead of HIT, which is
believed to be misleading.

diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c
--- a/src/http/ngx_http_upstream.c
+++ b/src/http/ngx_http_upstream.c
@@ -582,6 +582,8 @@ ngx_http_upstream_init_request(ngx_http_
             if (rc == NGX_HTTP_UPSTREAM_INVALID_HEADER) {
                 rc = NGX_DECLINED;
                 r->cached = 0;
+                u->buffer.start = NULL;
+                u->cache_status = NGX_HTTP_CACHE_MISS;
             }
 
             if (ngx_http_upstream_cache_background_update(r, u) != NGX_OK) {
@@ -1059,8 +1061,16 @@ ngx_http_upstream_cache_send(ngx_http_re
         return NGX_ERROR;
     }
 
+    if (rc == NGX_AGAIN) {
+        rc = NGX_HTTP_UPSTREAM_INVALID_HEADER; 
+    }
+
     /* rc == NGX_HTTP_UPSTREAM_INVALID_HEADER */
 
+    ngx_log_error(NGX_LOG_CRIT, r->connection->log, 0,
+                  "cache file \"%s\" contains invalid header",
+                  c->file.name.data);
+
     /* TODO: delete file */
 
     return rc;


-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Fri Sep  8 08:40:56 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Fri, 08 Sep 2017 04:40:56 -0400
Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0YwgImNhY2hlIGZpbGUgaGFzIHRvbyBsb25nIGhlYWRlciI=?=
In-Reply-To: <20170907165405.GI93611@mdounin.ru>
References: <20170907165405.GI93611@mdounin.ru>
Message-ID: <590a92e35017b40c8f34a4d6a536a0c4.NginxMailingListRussian@forum.nginx.org>

Патч вылечил ошибку с подвисанием. Но как быть с "too long header"?

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


From mdounin на mdounin.ru  Fri Sep  8 12:41:06 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 8 Sep 2017 15:41:06 +0300
Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0YwgImNhY2hlIGZpbGUgaGFzIHRvbyBsb25nIGhlYWRlciI=?=
In-Reply-To: <590a92e35017b40c8f34a4d6a536a0c4.NginxMailingListRussian@forum.nginx.org>
References: <20170907165405.GI93611@mdounin.ru>
 <590a92e35017b40c8f34a4d6a536a0c4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170908124106.GL93611@mdounin.ru>

Hello!

On Fri, Sep 08, 2017 at 04:40:56AM -0400, Ilya Evseev wrote:

> Патч вылечил ошибку с подвисанием. Но как быть с "too long header"?

Если дело действительно в упомянутом race'е, то на текущий момент 
существует два workaround'а:

- использовать proxy_cache_lock / proxy_cache_use_stale updating, 
  дабы минимизировать вероятность одновременного обновления 
  элемента кеша несколькими рабочими процессами;

- разобраться, почему заголовки ответов, возвращаемых бекендом 
  одновременно, отличаются, и по возможности это исправить.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Fri Sep  8 13:09:53 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Fri, 08 Sep 2017 09:09:53 -0400
Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0YwgImNhY2hlIGZpbGUgaGFzIHRvbyBsb25nIGhlYWRlciI=?=
In-Reply-To: <20170908124106.GL93611@mdounin.ru>
References: <20170908124106.GL93611@mdounin.ru>
Message-ID: <46fbb87e4884fc01ac99333b1170a210.NginxMailingListRussian@forum.nginx.org>

У нас уже включено:

  proxy_cache_use_stale updating error timeout invalid_header http_500
http_502 http_503 http_504;
  proxy_cache_lock on;
  proxy_cache_lock_age 1m;
  proxy_cache_lock_timeout 1m;

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


From mdounin на mdounin.ru  Fri Sep  8 13:21:25 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 8 Sep 2017 16:21:25 +0300
Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0YwgImNhY2hlIGZpbGUgaGFzIHRvbyBsb25nIGhlYWRlciI=?=
In-Reply-To: <46fbb87e4884fc01ac99333b1170a210.NginxMailingListRussian@forum.nginx.org>
References: <20170908124106.GL93611@mdounin.ru>
 <46fbb87e4884fc01ac99333b1170a210.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170908132125.GO93611@mdounin.ru>

Hello!

On Fri, Sep 08, 2017 at 09:09:53AM -0400, Ilya Evseev wrote:

> У нас уже включено:
> 
>   proxy_cache_use_stale updating error timeout invalid_header http_500
> http_502 http_503 http_504;
>   proxy_cache_lock on;
>   proxy_cache_lock_age 1m;
>   proxy_cache_lock_timeout 1m;

Тогда вряд ли речь идёт про известный race.  Если вы умеете 
воспроизводить проблему - было бы неплохо увидеть debug log, а 
равно nginx -V и полную конфигурацию, с которой проблема 
воспроизводится.

Естественно, стоит для начала исключить возможные внешние факторы, 
как то другие программы, пытающиеся изменять файлы в кеше (включая 
другие копии nginx'а), а равно сторонние модули, если есть.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Fri Sep  8 14:32:31 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Fri, 08 Sep 2017 10:32:31 -0400
Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0YwgImNhY2hlIGZpbGUgaGFzIHRvbyBsb25nIGhlYWRlciI=?=
In-Reply-To: <20170908132125.GO93611@mdounin.ru>
References: <20170908132125.GO93611@mdounin.ru>
Message-ID: <f38fbf3c008162260bd1d13580cf9b80.NginxMailingListRussian@forum.nginx.org>

Когда ошибка случается, h->body_start почему-то всегда больше c->body_start
ровно на один байт:

$ perl -ne 'print "$1 $2\n" if /has too long header \(actual = (\d+),
required = (\d+)\)/' /var/log/nginx/error.log
730 729
734 733
732 731
724 723
734 733
737 736
722 721
729 728
729 728
750 749
750 749
750 749

Совпадение? Не думаю(c)

Какие ещё данные имеет смысл распечатывать в сообщении об ошибке, кроме
body_start?

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


From mdounin на mdounin.ru  Fri Sep  8 14:58:40 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 8 Sep 2017 17:58:40 +0300
Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0YwgImNhY2hlIGZpbGUgaGFzIHRvbyBsb25nIGhlYWRlciI=?=
In-Reply-To: <f38fbf3c008162260bd1d13580cf9b80.NginxMailingListRussian@forum.nginx.org>
References: <20170908132125.GO93611@mdounin.ru>
 <f38fbf3c008162260bd1d13580cf9b80.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170908145840.GP93611@mdounin.ru>

Hello!

On Fri, Sep 08, 2017 at 10:32:31AM -0400, Ilya Evseev wrote:

> Когда ошибка случается, h->body_start почему-то всегда больше c->body_start
> ровно на один байт:
> 
> $ perl -ne 'print "$1 $2\n" if /has too long header \(actual = (\d+),
> required = (\d+)\)/' /var/log/nginx/error.log
> 730 729
> 734 733
> 732 731
> 724 723
> 734 733
> 737 736
> 722 721
> 729 728
> 729 728
> 750 749
> 750 749
> 750 749
> 
> Совпадение? Не думаю(c)
> 
> Какие ещё данные имеет смысл распечатывать в сообщении об ошибке, кроме
> body_start?

В первую очередь имеет смысл смотреть на то, что это за элемент 
кеша, когда именно он обновлялся до ошибки, и не обновлялся ли в 
то же время, что и ошибка.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Sat Sep  9 10:44:31 2017
From: nginx-forum на forum.nginx.org (aekv)
Date: Sat, 09 Sep 2017 06:44:31 -0400
Subject: =?UTF-8?Q?Exchange_ActiveSync_=D0=B8_iPhone?=
Message-ID: <212e39dcef0499e92cdbfc25e2e48793.NginxMailingListRussian@forum.nginx.org>

Здравствуйте,

Опубликовал exchange 16 через Nginx, все работает корректно за исключением
ActiveSync  и iPhone клиентов.
Проблема заключается в том, что не отправляются любые вложение размер
которых больше 1 килобайта. 
При отправке почтовый клиент сообщает "Сбой отправки сообщения" "Это
сообщение было отклонено сервером"


ОС Ubuntu 16.04, nginx/1.13.5

Exchange.conf

server {

      listen 443 ssl http2; 
      server_name mail.exchange.com autodiscover.exchange.com;

      ssl_certificate
/etc/letsencrypt/live/mail.exchange.com/fullchain.pem;
      ssl_certificate_key
/etc/letsencrypt/live/mail.exchange.com/privkey.pem;
      ssl_trusted_certificate
/etc/letsencrypt/live/mail.exchange.com/fullchain.pem;
      
      # add_header Strict-Transport-Security "max-age=15768000;
includeSubDomains; preload" always;
      # add_header X-Content-Type-Options nosniff always;

      include exchange_proxy.conf;

      proxy_ssl_verify off;

      location / {
      return 301 https://mail.exchange.com/owa;
      }

      location = /favicon.ico {
      empty_gif;
      access_log off;
      }

      location ~* ^/owa { 
      proxy_pass https://exchange;
      proxy_http_version 1.1;
      proxy_set_header Connection ""; 
  	}

      location ~* ^/Microsoft-Server-ActiveSync { 
      proxy_pass https://exchange;
      proxy_http_version 1.1;
      proxy_set_header Connection ""; 
      }

      location ~* ^/autodiscover { 
      proxy_pass https://exchange;
      proxy_http_version 1.1;
      proxy_set_header Connection ""; 
      }

#########################################

exchange_proxy.conf

client_max_body_size 0;
client_body_buffer_size 128k;

proxy_read_timeout 3h;
proxy_send_timeout 3h;
proxy_connect_timeout 3h;
keepalive_timeout 3h;

proxy_buffers  16 32k;
proxy_buffer_size 64k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

proxy_pass_header Date;
proxy_pass_header Server;
proxy_pass_header Authorization;

proxy_pass_request_headers on;

large_client_header_buffers 8 32k; 


# more_set_input_headers 'Authorization: $http_authorization';

proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Accept-Encoding "";
proxy_set_header Connection "Keep-Alive";

# more_set_headers -s 401 'WWW-Authenticate: Basic realm="10.11.11.11"';

proxy_buffering off;
proxy_request_buffering off;

#########################################

ssl.conf

ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_protocols TLSv1.2;
ssl_ciphers
'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;
# ssl_ecdh_curve secp384r1;
ssl_stapling on;
ssl_stapling_verify on;

#########################################

upstream.conf

upstream exchange {
      server 10.11.11.11:443;
}



В логах при отправке:

IP  - user на exchange.com [09/Sep/2017:13:38:23 +0300] "POST
/Microsoft-Server-ActiveSync?User=user на exchange.com&DeviceId=FDBV17HMPH1VDDJDFRGIS0K8ES&DeviceType=iPhone&Cmd=SendMail
HTTP/2.0" 400 166 "-" "Apple-iPhone8C2/1501.537200001" "-"

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


From nginx-forum на forum.nginx.org  Sat Sep  9 15:37:18 2017
From: nginx-forum на forum.nginx.org (Seriyyy95)
Date: Sat, 09 Sep 2017 11:37:18 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0Y7RgiDRgNC10LPRg9C70Y/RgNC90YvQtSA=?=
 =?UTF-8?B?0LLRi9GA0LDQttC10L3QuNGPINCyIGxvY2F0aW9u?=
In-Reply-To: <20170904125244.GK93611@mdounin.ru>
References: <20170904125244.GK93611@mdounin.ru>
Message-ID: <808b631640a5d555c54a9704e16a6252.NginxMailingListRussian@forum.nginx.org>

Да, все именно так. Спасибо огромное!

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


From nginx-forum на forum.nginx.org  Sat Sep  9 21:49:39 2017
From: nginx-forum на forum.nginx.org (aekv)
Date: Sat, 09 Sep 2017 17:49:39 -0400
Subject: =?UTF-8?Q?Re=3A_Exchange_ActiveSync_=D0=B8_iPhone?=
In-Reply-To: <212e39dcef0499e92cdbfc25e2e48793.NginxMailingListRussian@forum.nginx.org>
References: <212e39dcef0499e92cdbfc25e2e48793.NginxMailingListRussian@forum.nginx.org>
Message-ID: <463bbc32209f205208d8e25086b9d2b2.NginxMailingListRussian@forum.nginx.org>

error.log debug

2017/09/10 00:24:40 [info] 1769#1769: *91 client prematurely closed stream:
only 4095 out of 6989 bytes of request body received while sending request
to upstream, client: IP_Address, server: mail.exchange.com, request: "POST
/Microsoft-Server-ActiveSync?User=user на exchange.com&DeviceId=FD90DF5KLE1VDDJDFRGIS0K8ES&DeviceType=iPhone&Cmd=SendMail
HTTP/2.0", upstream:
"https://10.11.11.11:443/Microsoft-Server-ActiveSync?User=user на exchange.com&DeviceId=FD90DF5KLE1VDDJDFRGIS0K8ES&DeviceType=iPhone&Cmd=SendMail",
host: "mail.exchange.com"

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


From nginx-forum на forum.nginx.org  Sun Sep 10 12:54:30 2017
From: nginx-forum на forum.nginx.org (aekv)
Date: Sun, 10 Sep 2017 08:54:30 -0400
Subject: =?UTF-8?Q?Re=3A_Exchange_ActiveSync_=D0=B8_iPhone?=
In-Reply-To: <212e39dcef0499e92cdbfc25e2e48793.NginxMailingListRussian@forum.nginx.org>
References: <212e39dcef0499e92cdbfc25e2e48793.NginxMailingListRussian@forum.nginx.org>
Message-ID: <cb5bec3ed85ae805606b47a2bd0d716a.NginxMailingListRussian@forum.nginx.org>

Проблема решилась отключением http2

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


From maxim на nginx.com  Tue Sep 12 12:05:27 2017
From: maxim на nginx.com (Maxim Konovalov)
Date: Tue, 12 Sep 2017 15:05:27 +0300
Subject: Nginx Inc is hiring. Yes, again.
In-Reply-To: <70e2c13d-d39d-0a74-ad5f-099e16fdd795@nginx.com>
References: <70e2c13d-d39d-0a74-ad5f-099e16fdd795@nginx.com>
Message-ID: <fd7ba381-fd1b-9fdb-9e0b-daf71c895c39@nginx.com>

Добрый день.

Небольшой апдейт.

Формальное описание вакансии тут:

https://www.nginx.com/jobs/cunix-developer/

С проектом можно ознакомиться здесь:

http://unit.nginx.org/
http://hg.nginx.org/unit/file/tip

On 07/02/2017 15:27, Maxim Konovalov wrote:
> Добрый день.
> 
> Мы опять ищем разработчиков к нам в коллектив.
> 
> Основные факты о нас: компания основана в 2011 году, занимается
> развитием nginx f/oss [1] и созданием коммерческих продуктов на базе
> nginx [2].  Технический офис в Москве, штаб-квартира в
> Сан-Франциско, США.
> 
> Чем заниматься: разработкой прокси-сервера, интеграцией языков
> программирования в сервер приложений. Проект ведет непосредственно
> Игорь Сысоев.
> 
> Что надо знать и уметь:
> 
> - опыт профессионального программирования под UNIX на C от 3 лет;
> - продвинутый/экспертный уровень;
> - понимание архитектур современных операционных систем;
> - владение инструментами разработки под UNIX;
> - уверенные навыки пользователя UNIX;
> - технический английский язык.
> 
> Желательно:
> 
> - опыт написания клиент-серверных приложений;
> - навыки программированния асинхронных и многопоточных приложений;
> - понимание устройства и принципов работы интерпретируемых языков
> программирования;
> - знание и опыт программирования на Java, Go, PHP, Python,
> JavaScript, Ruby;
> - знание протокола HTTP.
> 
> В обмен на ваше участие предлагаем следующее:
> 
> - работа в проекте с международным признанием (~50% из top-100K
> мировых сайтов используют nginx [3]), в компактном коллективе
> профессионалов, увлеченных своим делом;
> - профессиональный рост;
> - конкурентная зарплата, ДМС после исп. срока, гибкий график работы,
> участие в опционной программе.
> 
> В связи со спецификой проекта, на который ищем людей, варианты с
> удаленной работой не рассматриваем, т.е. речь о полной занятости в
> Москве.
> 
> Жду ваши CV на maxim на nginx.com.
> 
> [1] http://nginx.org
> [2] http://nginx.com
> [3] http://w3techs.com/technologies/cross/web_server/ranking
> 


-- 
Maxim Konovalov

"I'm not a software developer, but it doesn't seem as rocket
science"

From nginx-forum на forum.nginx.org  Wed Sep 13 16:07:49 2017
From: nginx-forum на forum.nginx.org (ingtar)
Date: Wed, 13 Sep 2017 12:07:49 -0400
Subject: =?UTF-8?B?IndvcmtlciBwcm9jZXNzIGlzIHNodXR0aW5nIGRvd24iINC4INC+0YjQuNCx0Lo=?=
 =?UTF-8?B?0Lggb3BlbiBmaWxlcw==?=
Message-ID: <9bb46d5cb8e1c4cc210db3b3f5a6fbe0.NginxMailingListRussian@forum.nginx.org>

Добрый день! Такая непонятная штука стала происходить (время появления не
зафиксировали)
Есть nginx в котором:
worker_processes  28;
worker_rlimit_nofile 20000;

В случае выполнения nignx reload старые ооочень долго не завершаются.
Настройка worker_shutdown_timeout 1m выставлена, но особо не помогает.
Через какое-то время появляются ошибки Too many open files. Если посмотреть
по открытым файлам для каждого процесса то картина следующая:

несколько 
nginx: worker process
Limit                     Soft Limit           Hard Limit           Units   
 
Max open files            20000                20000                files   
 
pid 43587
Currently open files: 12510

и очень много:

nginx: worker process is shutting down
Limit                     Soft Limit           Hard Limit           Units   
 
Max open files            15240                15240                files   
 
pid 35319
Currently open files: 217

nginx: worker process is shutting down
Limit                     Soft Limit           Hard Limit           Units   
 
Max open files            15240                15240                files   
 
pid 35311
Currently open files: 223

Если посмотреть список процессов, то видно что нормальных воркеров мало, у
каждого перекос по файлам и такие ошибки.

nobody    1752 18.0  5.2 2752480 1712492 ?     S    18:40   4:13 nginx:
worker process is shutting down          
nobody    6034 36.3  5.2 2752480 1740768 ?     S    17:38  30:45 nginx:
worker process is shutting down          
nobody    6035  8.1  4.2 2752480 1399368 ?     S    17:38   6:54 nginx:
worker process is shutting down          
nobody    6040  5.4  4.1 2752480 1359280 ?     S    17:38   4:35 nginx:
worker process is shutting down          
nobody    6049 12.5  4.6 2752480 1539268 ?     S    17:38  10:35 nginx:
worker process is shutting down          
nobody    6050 31.3  5.2 2752480 1739804 ?     S    17:38  26:31 nginx:
worker process is shutting down          
nobody    6052  3.3  4.0 2752480 1343572 ?     S    17:38   2:51 nginx:
worker process is shutting down          
nobody    6054  5.3  4.1 2752480 1360352 ?     S    17:38   4:33 nginx:
worker process is shutting down          
nobody    6055 26.2  5.4 2752480 1790544 ?     S    17:38  22:13 nginx:
worker process is shutting down          
nobody    6058  0.0  3.7 2752480 1227076 ?     S    17:38   0:03 nginx:
cache manager process                    
root      6168  0.0  3.9 2752480 1293176 ?     Ss   13:24   0:16 nginx:
master process /usr/sbin/nginx -g daemon on; master_process on;
nobody   10656 48.4  5.2 2752480 1719536 ?     S    18:45   8:36 nginx:
worker process is shutting down          
nobody   10657 31.1  4.4 2752480 1460292 ?     S    18:45   5:31 nginx:
worker process is shutting down          
nobody   10658 70.8  5.2 2752480 1739444 ?     R    18:45  12:33 nginx:
worker process                           
nobody   10659 70.7  5.2 2752480 1739476 ?     R    18:45  12:32 nginx:
worker process                           
nobody   10660 10.7  4.1 2752480 1377328 ?     S    18:45   1:54 nginx:
worker process is shutting down          
nobody   11053 25.3  4.3 2752480 1440108 ?     S    18:45   4:26 nginx:
worker process is shutting down          
nobody   11054 51.3  5.3 2752480 1756036 ?     S    18:45   8:59 nginx:
worker process is shutting down          
nobody   11055  2.2  4.0 2752480 1324696 ?     S    18:45   0:23 nginx:
worker process is shutting down          
nobody   11056 38.6  4.8 2752480 1604476 ?     S    18:45   6:45 nginx:
worker process is shutting down          
nobody   11057 17.9  4.2 2752480 1400344 ?     S    18:45   3:07 nginx:
worker process is shutting down          
nobody   16049  9.6  4.1 2752480 1373540 ?     S    18:48   1:26 nginx:
worker process is shutting down          
nobody   19782 29.2  5.4 2752480 1784320 ?     S    18:18  13:08 nginx:
worker process is shutting down          
nobody   29881  7.8  4.7 2752480 1571664 ?     S    18:24   3:06 nginx:
worker process is shutting down          
nobody   32145 22.2  5.3 2752480 1757248 ?     S    17:53  15:40 nginx:
worker process is shutting down          
nobody   33168 19.8  5.3 2752480 1748384 ?     S    18:25   7:33 nginx:
worker process is shutting down          
nobody   36049 94.5  5.1 2752480 1702212 ?     R    18:59   3:29 nginx:
worker process                           
nobody   40384 14.9  4.1 2489628 1365948 ?     S    16:22  24:07 nginx:
worker process is shutting down          
root     43195  0.0  0.0  13956  2188 pts/0    S+   19:03   0:00 grep
--color=auto nginx
nobody   45130 22.6  5.2 2752480 1715320 ?     S    18:32   6:58 nginx:
worker process is shutting down          
nobody   48277  3.8  4.1 2489628 1369324 ?     S    16:58   4:48 nginx:
worker process is shutting down          
nobody   49924  6.1  4.2 2489628 1411852 ?     S    16:59   7:37 nginx:
worker process is shutting down          
nobody   49931  2.7  4.1 2489628 1368808 ?     S    16:59   3:22 nginx:
worker process is shutting down          
nobody   49943  8.3  4.4 2489628 1453684 ?     S    16:59  10:18 nginx:
worker process is shutting down          
nobody   49944  9.1  4.3 2489628 1444924 ?     S    16:59  11:18 nginx:
worker process is shutting down          
nobody   49945  3.8  4.3 2489628 1436344 ?     S    16:59   4:46 nginx:
worker process is shutting down          
nobody   50490  8.6  5.3 2752480 1768892 ?     S    18:35   2:25 nginx:
worker process is shutting down          
nobody   55442 24.4  5.3 2752480 1753424 ?     S    18:38   6:02 nginx:
worker process is shutting down          

Версия nignx 1.12.1 собрана так:

nginx version: nginx/1.12.1
built by gcc 4.9.2 (Debian 4.9.2-10) 
built with OpenSSL 1.0.2j  26 Sep 2016 (running with OpenSSL 1.0.2i  22 Sep
2016)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid
--lock-path=/run/lock/nginx.lock
--http-client-body-temp-path=/run/shm/body_temp
--http-proxy-temp-path=/run/shm/proxy_temp
--http-fastcgi-temp-path=/run/shm/fastcgi_temp
--http-uwsgi-temp-path=/run/shm/uwsgi_temp
--http-scgi-temp-path=/run/shm/scgi_temp --with-http_ssl_module
--with-http_realip_module --with-http_sub_module --with-http_dav_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_stub_status_module --with-mail --with-http_v2_module
--with-http_geoip_module --with-select_module
--with-http_auth_request_module --with-poll_module --with-debug

Встречалось ли такое?

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


From basil на vpm.net.ua  Wed Sep 13 16:25:46 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Wed, 13 Sep 2017 19:25:46 +0300
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <9bb46d5cb8e1c4cc210db3b3f5a6fbe0.NginxMailingListRussian@forum.nginx.org>
References: <9bb46d5cb8e1c4cc210db3b3f5a6fbe0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAMPJU7DrzkCMzobJBoRy8FAZ2KdV4AD8yuizvePOkNyuZ3EDig@mail.gmail.com>

кеш используется ?

13 сентября 2017 г., 19:07 пользователь ingtar <nginx-forum на forum.nginx.org>
написал:

> Добрый день! Такая непонятная штука стала происходить (время появления не
> зафиксировали)
> Есть nginx в котором:
> worker_processes  28;
> worker_rlimit_nofile 20000;
>
> В случае выполнения nignx reload старые ооочень долго не завершаются.
> Настройка worker_shutdown_timeout 1m выставлена, но особо не помогает.
> Через какое-то время появляются ошибки Too many open files. Если посмотреть
> по открытым файлам для каждого процесса то картина следующая:
>
> несколько
> nginx: worker process
> Limit                     Soft Limit           Hard Limit           Units
>
> Max open files            20000                20000                files
>
> pid 43587
> Currently open files: 12510
>
> и очень много:
>
> nginx: worker process is shutting down
> Limit                     Soft Limit           Hard Limit           Units
>
> Max open files            15240                15240                files
>
> pid 35319
> Currently open files: 217
>
> nginx: worker process is shutting down
> Limit                     Soft Limit           Hard Limit           Units
>
> Max open files            15240                15240                files
>
> pid 35311
> Currently open files: 223
>
> Если посмотреть список процессов, то видно что нормальных воркеров мало, у
> каждого перекос по файлам и такие ошибки.
>
> nobody    1752 18.0  5.2 2752480 1712492 ?     S    18:40   4:13 nginx:
> worker process is shutting down
> nobody    6034 36.3  5.2 2752480 1740768 ?     S    17:38  30:45 nginx:
> worker process is shutting down
> nobody    6035  8.1  4.2 2752480 1399368 ?     S    17:38   6:54 nginx:
> worker process is shutting down
> nobody    6040  5.4  4.1 2752480 1359280 ?     S    17:38   4:35 nginx:
> worker process is shutting down
> nobody    6049 12.5  4.6 2752480 1539268 ?     S    17:38  10:35 nginx:
> worker process is shutting down
> nobody    6050 31.3  5.2 2752480 1739804 ?     S    17:38  26:31 nginx:
> worker process is shutting down
> nobody    6052  3.3  4.0 2752480 1343572 ?     S    17:38   2:51 nginx:
> worker process is shutting down
> nobody    6054  5.3  4.1 2752480 1360352 ?     S    17:38   4:33 nginx:
> worker process is shutting down
> nobody    6055 26.2  5.4 2752480 1790544 ?     S    17:38  22:13 nginx:
> worker process is shutting down
> nobody    6058  0.0  3.7 2752480 1227076 ?     S    17:38   0:03 nginx:
> cache manager process
> root      6168  0.0  3.9 2752480 1293176 ?     Ss   13:24   0:16 nginx:
> master process /usr/sbin/nginx -g daemon on; master_process on;
> nobody   10656 48.4  5.2 2752480 1719536 ?     S    18:45   8:36 nginx:
> worker process is shutting down
> nobody   10657 31.1  4.4 2752480 1460292 ?     S    18:45   5:31 nginx:
> worker process is shutting down
> nobody   10658 70.8  5.2 2752480 1739444 ?     R    18:45  12:33 nginx:
> worker process
> nobody   10659 70.7  5.2 2752480 1739476 ?     R    18:45  12:32 nginx:
> worker process
> nobody   10660 10.7  4.1 2752480 1377328 ?     S    18:45   1:54 nginx:
> worker process is shutting down
> nobody   11053 25.3  4.3 2752480 1440108 ?     S    18:45   4:26 nginx:
> worker process is shutting down
> nobody   11054 51.3  5.3 2752480 1756036 ?     S    18:45   8:59 nginx:
> worker process is shutting down
> nobody   11055  2.2  4.0 2752480 1324696 ?     S    18:45   0:23 nginx:
> worker process is shutting down
> nobody   11056 38.6  4.8 2752480 1604476 ?     S    18:45   6:45 nginx:
> worker process is shutting down
> nobody   11057 17.9  4.2 2752480 1400344 ?     S    18:45   3:07 nginx:
> worker process is shutting down
> nobody   16049  9.6  4.1 2752480 1373540 ?     S    18:48   1:26 nginx:
> worker process is shutting down
> nobody   19782 29.2  5.4 2752480 1784320 ?     S    18:18  13:08 nginx:
> worker process is shutting down
> nobody   29881  7.8  4.7 2752480 1571664 ?     S    18:24   3:06 nginx:
> worker process is shutting down
> nobody   32145 22.2  5.3 2752480 1757248 ?     S    17:53  15:40 nginx:
> worker process is shutting down
> nobody   33168 19.8  5.3 2752480 1748384 ?     S    18:25   7:33 nginx:
> worker process is shutting down
> nobody   36049 94.5  5.1 2752480 1702212 ?     R    18:59   3:29 nginx:
> worker process
> nobody   40384 14.9  4.1 2489628 1365948 ?     S    16:22  24:07 nginx:
> worker process is shutting down
> root     43195  0.0  0.0  13956  2188 pts/0    S+   19:03   0:00 grep
> --color=auto nginx
> nobody   45130 22.6  5.2 2752480 1715320 ?     S    18:32   6:58 nginx:
> worker process is shutting down
> nobody   48277  3.8  4.1 2489628 1369324 ?     S    16:58   4:48 nginx:
> worker process is shutting down
> nobody   49924  6.1  4.2 2489628 1411852 ?     S    16:59   7:37 nginx:
> worker process is shutting down
> nobody   49931  2.7  4.1 2489628 1368808 ?     S    16:59   3:22 nginx:
> worker process is shutting down
> nobody   49943  8.3  4.4 2489628 1453684 ?     S    16:59  10:18 nginx:
> worker process is shutting down
> nobody   49944  9.1  4.3 2489628 1444924 ?     S    16:59  11:18 nginx:
> worker process is shutting down
> nobody   49945  3.8  4.3 2489628 1436344 ?     S    16:59   4:46 nginx:
> worker process is shutting down
> nobody   50490  8.6  5.3 2752480 1768892 ?     S    18:35   2:25 nginx:
> worker process is shutting down
> nobody   55442 24.4  5.3 2752480 1753424 ?     S    18:38   6:02 nginx:
> worker process is shutting down
>
> Версия nignx 1.12.1 собрана так:
>
> nginx version: nginx/1.12.1
> built by gcc 4.9.2 (Debian 4.9.2-10)
> built with OpenSSL 1.0.2j  26 Sep 2016 (running with OpenSSL 1.0.2i  22 Sep
> 2016)
> TLS SNI support enabled
> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/
> nginx/error.log
> --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid
> --lock-path=/run/lock/nginx.lock
> --http-client-body-temp-path=/run/shm/body_temp
> --http-proxy-temp-path=/run/shm/proxy_temp
> --http-fastcgi-temp-path=/run/shm/fastcgi_temp
> --http-uwsgi-temp-path=/run/shm/uwsgi_temp
> --http-scgi-temp-path=/run/shm/scgi_temp --with-http_ssl_module
> --with-http_realip_module --with-http_sub_module --with-http_dav_module
> --with-http_gunzip_module --with-http_gzip_static_module
> --with-http_stub_status_module --with-mail --with-http_v2_module
> --with-http_geoip_module --with-select_module
> --with-http_auth_request_module --with-poll_module --with-debug
>
> Встречалось ли такое?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276356,276356#msg-276356
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170913/cb15f7bc/attachment-0001.html>

From nginx-forum на forum.nginx.org  Wed Sep 13 18:06:16 2017
From: nginx-forum на forum.nginx.org (ingtar)
Date: Wed, 13 Sep 2017 14:06:16 -0400
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <CAMPJU7DrzkCMzobJBoRy8FAZ2KdV4AD8yuizvePOkNyuZ3EDig@mail.gmail.com>
References: <CAMPJU7DrzkCMzobJBoRy8FAZ2KdV4AD8yuizvePOkNyuZ3EDig@mail.gmail.com>
Message-ID: <9ce93b353fde43d3fc7a0b8de14069c3.NginxMailingListRussian@forum.nginx.org>

Да, 

proxy_cache_path   /lib/init/rw/proxy_cache  levels=1:2  
keys_zone=static:10m max_size=100m;

Завтра попробую посмотреть дебаг логи

Vasiliy P. Melnik Wrote:
-------------------------------------------------------
> кеш используется ?
>

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


From mdounin на mdounin.ru  Wed Sep 13 19:27:22 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 13 Sep 2017 22:27:22 +0300
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <9bb46d5cb8e1c4cc210db3b3f5a6fbe0.NginxMailingListRussian@forum.nginx.org>
References: <9bb46d5cb8e1c4cc210db3b3f5a6fbe0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170913192722.GJ58595@mdounin.ru>

Hello!

On Wed, Sep 13, 2017 at 12:07:49PM -0400, ingtar wrote:

> Добрый день! Такая непонятная штука стала происходить (время появления не
> зафиксировали)
> Есть nginx в котором:
> worker_processes  28;
> worker_rlimit_nofile 20000;
> 
> В случае выполнения nignx reload старые ооочень долго не завершаются.
> Настройка worker_shutdown_timeout 1m выставлена, но особо не помогает.
> Через какое-то время появляются ошибки Too many open files. Если посмотреть
> по открытым файлам для каждого процесса то картина следующая:

[...]

Для начала я бы рекомендовал посмотреть в логи ошибок, нет ли там 
сообщений с уровнями "crit", "alert" или "emerg", особенно - от 
мастера.  Если они есть - то разбираться, что их вызвало.

Вообще обращают на себя внимание два фактора:

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

- время запуска процессов распределено хаотически (в частности, 
  совпадает время запуска работающих процессов и завершающихся).

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

Такое может произойти, например, если nginx упёрся в ограничение 
по количеству открытых файлов на пользователя, и в этот момент 
попытались сделать reload.

Отмечу в скобках, что для восстановления из подобной ситуации - 
обязательно перезапустить nginx.  Попытки делать очередные 
reload'ы ни к чему хорошему не приведут.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Wed Sep 13 19:38:55 2017
From: nginx-forum на forum.nginx.org (ingtar)
Date: Wed, 13 Sep 2017 15:38:55 -0400
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <20170913192722.GJ58595@mdounin.ru>
References: <20170913192722.GJ58595@mdounin.ru>
Message-ID: <9bee7def236f6dedd40463a287167e83.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin Wrote:
-------------------------------------------------------

> Такое может произойти, например, если nginx упёрся в ограничение 
> по количеству открытых файлов на пользователя, и в этот момент 
> попытались сделать reload.

Имеется в виду глобальные ограничения в /etc/security/limits.conf или в
worker_rlimit_nofile?

> Отмечу в скобках, что для восстановления из подобной ситуации - 
> обязательно перезапустить nginx.  Попытки делать очередные 
> reload'ы ни к чему хорошему не приведут.
> 

Да, перезапускаем.

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


From nginx-forum на forum.nginx.org  Wed Sep 13 20:00:28 2017
From: nginx-forum на forum.nginx.org (ingtar)
Date: Wed, 13 Sep 2017 16:00:28 -0400
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <9bee7def236f6dedd40463a287167e83.NginxMailingListRussian@forum.nginx.org>
References: <20170913192722.GJ58595@mdounin.ru>
 <9bee7def236f6dedd40463a287167e83.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e5935a1306d350cd0ecaf476d6e59a60.NginxMailingListRussian@forum.nginx.org>

И еще вопрос - может ли мастер процесс сам перезапускать воркеров через
какое-то время?

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


From mdounin на mdounin.ru  Wed Sep 13 20:01:29 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 13 Sep 2017 23:01:29 +0300
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <9bee7def236f6dedd40463a287167e83.NginxMailingListRussian@forum.nginx.org>
References: <20170913192722.GJ58595@mdounin.ru>
 <9bee7def236f6dedd40463a287167e83.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170913200129.GL58595@mdounin.ru>

Hello!

On Wed, Sep 13, 2017 at 03:38:55PM -0400, ingtar wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> 
> > Такое может произойти, например, если nginx упёрся в ограничение 
> > по количеству открытых файлов на пользователя, и в этот момент 
> > попытались сделать reload.
> 
> Имеется в виду глобальные ограничения в /etc/security/limits.conf или в
> worker_rlimit_nofile?

Директива worker_rlimit_nofile позволяет увеличить ограничение на 
количество открытых файлов для рабочих процессов.  Для мастера при 
этом действуют ограничения, установленные системой (обычно это 
_не_ limits.conf - он примеряется только для пользовательских 
сессий, а не для демонов).  Наступить можно и на то, и на другое.

-- 
Maxim Dounin
http://nginx.org/

From basil на vpm.net.ua  Thu Sep 14 08:13:32 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Thu, 14 Sep 2017 11:13:32 +0300
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <9ce93b353fde43d3fc7a0b8de14069c3.NginxMailingListRussian@forum.nginx.org>
References: <CAMPJU7DrzkCMzobJBoRy8FAZ2KdV4AD8yuizvePOkNyuZ3EDig@mail.gmail.com>
 <9ce93b353fde43d3fc7a0b8de14069c3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAMPJU7AwrsuOWWME7=w5Fp9LhGt5AJsX6hAYy2N=2ODTJgvSPw@mail.gmail.com>

Поставьте больше, например

worker_rlimit_nofile 102400;
хуже от этого точно не будет

2017-09-13 21:06 GMT+03:00 ingtar <nginx-forum на forum.nginx.org>:

> Да,
>
> proxy_cache_path   /lib/init/rw/proxy_cache  levels=1:2
> keys_zone=static:10m max_size=100m;
>
> Завтра попробую посмотреть дебаг логи
>
> Vasiliy P. Melnik Wrote:
> -------------------------------------------------------
> > кеш используется ?
> >
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276356,276358#msg-276358
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170914/30cd61c1/attachment.html>

From nginx-forum на forum.nginx.org  Thu Sep 14 11:23:56 2017
From: nginx-forum на forum.nginx.org (ingtar)
Date: Thu, 14 Sep 2017 07:23:56 -0400
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <CAMPJU7AwrsuOWWME7=w5Fp9LhGt5AJsX6hAYy2N=2ODTJgvSPw@mail.gmail.com>
References: <CAMPJU7AwrsuOWWME7=w5Fp9LhGt5AJsX6hAYy2N=2ODTJgvSPw@mail.gmail.com>
Message-ID: <f81a6374120be3503941b41eb92f169e.NginxMailingListRussian@forum.nginx.org>

Да, так и сделали. Про openfiles ошибки ушли, а вот висящие процессы в
статусе завершения - остались.
Шаги для повторения - поставить nginx, дать нагрузку (5к rps например),
сделать reload. Процессы не отпустит, но новые поднимутся.
Если убрать нагрузку, то они завершатся через какие-то время корректно.
Проверяю на 1.12.1 с опцией worker_shutdown_timeout 1m
Пока подозреваю keepalive...

Из его настроек только
    keepalive_timeout  75 75;
    keepalive_requests 1000;


Vasiliy P. Melnik Wrote:
-------------------------------------------------------
> Поставьте больше, например
> 
> worker_rlimit_nofile 102400;
> хуже от этого точно не будет
> 
> 2017-09-13 21:06 GMT+03:00 ingtar <nginx-forum на forum.nginx.org>:
> 
> > Да,
> >
> > proxy_cache_path   /lib/init/rw/proxy_cache  levels=1:2
> > keys_zone=static:10m max_size=100m;
> >
> > Завтра попробую посмотреть дебаг логи
> >
> > Vasiliy P. Melnik Wrote:
> > -------------------------------------------------------
> > > кеш используется ?
> > >
> >
> > Posted at Nginx Forum: https://forum.nginx.org/read.
> > php?21,276356,276358#msg-276358
> >
> > _______________________________________________
> > 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

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


From basil на vpm.net.ua  Thu Sep 14 11:47:53 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Thu, 14 Sep 2017 14:47:53 +0300
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <f81a6374120be3503941b41eb92f169e.NginxMailingListRussian@forum.nginx.org>
References: <CAMPJU7AwrsuOWWME7=w5Fp9LhGt5AJsX6hAYy2N=2ODTJgvSPw@mail.gmail.com>
 <f81a6374120be3503941b41eb92f169e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAMPJU7AmkL5HhFYdVPoWdn53GQoo79xTxfvTPR48c8wXS=GQhg@mail.gmail.com>

Syntax: keepalive_timeout timeout [header_timeout];
Default: keepalive_timeout 75s;

Зачем прописывать дефолтные значения не знаю - там и так 75 секунд

у меня прописано 10 секунд, у Вас запросы могут выполняться по 75 секунд?

reset_timedout_connection on - это есть в конфиге?


14 сентября 2017 г., 14:23 пользователь ingtar <nginx-forum на forum.nginx.org>
написал:

> Да, так и сделали. Про openfiles ошибки ушли, а вот висящие процессы в
> статусе завершения - остались.
> Шаги для повторения - поставить nginx, дать нагрузку (5к rps например),
> сделать reload. Процессы не отпустит, но новые поднимутся.
> Если убрать нагрузку, то они завершатся через какие-то время корректно.
> Проверяю на 1.12.1 с опцией worker_shutdown_timeout 1m
> Пока подозреваю keepalive...
>
> Из его настроек только
>     keepalive_timeout  75 75;
>     keepalive_requests 1000;
>
>
> Vasiliy P. Melnik Wrote:
> -------------------------------------------------------
> > Поставьте больше, например
> >
> > worker_rlimit_nofile 102400;
> > хуже от этого точно не будет
> >
> > 2017-09-13 21:06 GMT+03:00 ingtar <nginx-forum на forum.nginx.org>:
> >
> > > Да,
> > >
> > > proxy_cache_path   /lib/init/rw/proxy_cache  levels=1:2
> > > keys_zone=static:10m max_size=100m;
> > >
> > > Завтра попробую посмотреть дебаг логи
> > >
> > > Vasiliy P. Melnik Wrote:
> > > -------------------------------------------------------
> > > > кеш используется ?
> > > >
> > >
> > > Posted at Nginx Forum: https://forum.nginx.org/read.
> > > php?21,276356,276358#msg-276358
> > >
> > > _______________________________________________
> > > 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
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276356,276374#msg-276374
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170914/92998d31/attachment-0001.html>

From nginx-forum на forum.nginx.org  Thu Sep 14 12:05:57 2017
From: nginx-forum на forum.nginx.org (ingtar)
Date: Thu, 14 Sep 2017 08:05:57 -0400
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <CAMPJU7AmkL5HhFYdVPoWdn53GQoo79xTxfvTPR48c8wXS=GQhg@mail.gmail.com>
References: <CAMPJU7AmkL5HhFYdVPoWdn53GQoo79xTxfvTPR48c8wXS=GQhg@mail.gmail.com>
Message-ID: <9c949e8955f84a68f4eec86841046ce2.NginxMailingListRussian@forum.nginx.org>

Некоторые долгие могут. Там конфиг бааальшой %)
reset_timedout_connection on  отсутствует.

Я подцепился стрейсом к зависшему воркеру и там были запросы от websocket.
Их все время держат, гоняя ping-pong запросы по ним. Кажется дело в них.
worker_shutdown_timeout же по идее должен был в этой ситуации решить? 

Vasiliy P. Melnik Wrote:
-------------------------------------------------------
> Syntax: keepalive_timeout timeout [header_timeout];
> Default: keepalive_timeout 75s;
> 
> Зачем прописывать дефолтные значения не знаю - там и так 75 секунд
> 
> у меня прописано 10 секунд, у Вас запросы могут выполняться по 75
> секунд?
> 
> reset_timedout_connection on - это есть в конфиге?
> 
> 
> 14 сентября 2017 г., 14:23 пользователь ingtar
> <nginx-forum на forum.nginx.org>
> написал:
> 
> > Да, так и сделали. Про openfiles ошибки ушли, а вот висящие процессы
> в
> > статусе завершения - остались.
> > Шаги для повторения - поставить nginx, дать нагрузку (5к rps
> например),
> > сделать reload. Процессы не отпустит, но новые поднимутся.
> > Если убрать нагрузку, то они завершатся через какие-то время
> корректно.
> > Проверяю на 1.12.1 с опцией worker_shutdown_timeout 1m
> > Пока подозреваю keepalive...
> >
> > Из его настроек только
> >     keepalive_timeout  75 75;
> >     keepalive_requests 1000;
> >
> >
> > Vasiliy P. Melnik Wrote:
> > -------------------------------------------------------
> > > Поставьте больше, например
> > >
> > > worker_rlimit_nofile 102400;
> > > хуже от этого точно не будет
> > >
> > > 2017-09-13 21:06 GMT+03:00 ingtar <nginx-forum на forum.nginx.org>:
> > >
> > > > Да,
> > > >
> > > > proxy_cache_path   /lib/init/rw/proxy_cache  levels=1:2
> > > > keys_zone=static:10m max_size=100m;
> > > >
> > > > Завтра попробую посмотреть дебаг логи
> > > >
> > > > Vasiliy P. Melnik Wrote:
> > > > -------------------------------------------------------
> > > > > кеш используется ?
> > > > >
> > > >
> > > > Posted at Nginx Forum: https://forum.nginx.org/read.
> > > > php?21,276356,276358#msg-276358
> > > >
> > > > _______________________________________________
> > > > 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
> >
> > Posted at Nginx Forum: https://forum.nginx.org/read.
> > php?21,276356,276374#msg-276374
> >
> > _______________________________________________
> > 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

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


From basil на vpm.net.ua  Thu Sep 14 12:23:58 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Thu, 14 Sep 2017 15:23:58 +0300
Subject: =?UTF-8?B?UmU6ICJ3b3JrZXIgcHJvY2VzcyBpcyBzaHV0dGluZyBkb3duIiDQuCDQvtGI0Lg=?=
 =?UTF-8?B?0LHQutC4IG9wZW4gZmlsZXM=?=
In-Reply-To: <9c949e8955f84a68f4eec86841046ce2.NginxMailingListRussian@forum.nginx.org>
References: <CAMPJU7AmkL5HhFYdVPoWdn53GQoo79xTxfvTPR48c8wXS=GQhg@mail.gmail.com>
 <9c949e8955f84a68f4eec86841046ce2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAMPJU7CME=Y2qViuO2anOO5priu9Eru2fyRWhRV+wPbdFjwKeg@mail.gmail.com>

14 сентября 2017 г., 15:05 пользователь ingtar <nginx-forum на forum.nginx.org>
написал:

> Некоторые долгие могут. Там конфиг бааальшой %)
> reset_timedout_connection on  отсутствует.
>
> Я подцепился стрейсом к зависшему воркеру и там были запросы от websocket.
> Их все время держат, гоняя ping-pong запросы по ним. Кажется дело в них.
> worker_shutdown_timeout же по идее должен был в этой ситуации решить?
>

Не знаю - у меня нет такого :)
не я настраивал - нгингкс мне уже такой достался, фронт держит до 2К
коннекшинов, скорее всего и больше вытянет, но не было больше.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170914/c528cc9b/attachment.html>

From ads на unix4all.com  Thu Sep 14 13:53:43 2017
From: ads на unix4all.com (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdGB0LjQvNC+0LI=?=)
Date: Thu, 14 Sep 2017 16:53:43 +0300
Subject: =?UTF-8?B?0J/Rg9GB0YLQvtC1INC30L3QsNGH0LXQvdC40LUg0LTQu9GPIGFyZ19uYW1lICg=?=
 =?UTF-8?B?0L/QtdGA0LjQvtC00LjRh9C10YHQutC4KQ==?=
Message-ID: <CAK-RTX0Yx6hmivYgOkbG9tvWXSkNJosRToNrK2O=2=BUi9RBAQ@mail.gmail.com>

Иногда сталкиваюсь с ситуацией, когда логируемый аргумент POST-запроса
прописывается прочерком.

Подскажите, пожалуйста, почему такое может быть и на что стоит обратить
внимание.

-- 
Sincerely,
Dmitry Ansimov
freelance system administrator
skype: cardinal-gray
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170914/d9a63d64/attachment.html>

From bobrof на gmail.com  Fri Sep 15 09:25:36 2017
From: bobrof на gmail.com (Paul O)
Date: Fri, 15 Sep 2017 12:25:36 +0300
Subject: upload/multipart + http2
Message-ID: <CAN_=z6wv9Q=tVmDtHy1gX+bwCs=2dc_zDFyfrHToS6vXSKmv-Q@mail.gmail.com>

Делаем сервис через http2. Требуется добавить возможность upload-a
multipart/form-data.
Найденные модули либо не поддерживают multipart, либо переключают nginx в
http1.
Подскажите пожалуйста модуль, который бы позволил искомый функционал в
http2.

С уважением,
Павел
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170915/aa915de9/attachment.html>

From nginx на kinetiksoft.com  Fri Sep 15 10:47:36 2017
From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=)
Date: Fri, 15 Sep 2017 13:47:36 +0300
Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0L7QtSDQt9C90LDRh9C10L3QuNC1INC00LvRjyBhcmdfbmFt?=
 =?UTF-8?B?ZSAo0L/QtdGA0LjQvtC00LjRh9C10YHQutC4KQ==?=
In-Reply-To: <CAK-RTX0Yx6hmivYgOkbG9tvWXSkNJosRToNrK2O=2=BUi9RBAQ@mail.gmail.com>
References: <CAK-RTX0Yx6hmivYgOkbG9tvWXSkNJosRToNrK2O=2=BUi9RBAQ@mail.gmail.com>
Message-ID: <5040134.xlBaHYt0IR@cybernote>

Прошу прощения за оффтопик, но $arg_* разве разбирает аргументы POST-
запроса? Я думал $arg_* только с GET работает.

В письме от четверг, 14 сентября 2017 г. 16:53:43 MSK пользователь Дмитрий 
Ансимов написал:
> Иногда сталкиваюсь с ситуацией, когда логируемый аргумент POST-запроса
> прописывается прочерком.
> 
> Подскажите, пожалуйста, почему такое может быть и на что стоит обратить
> внимание.
> 
> -- 
> Sincerely,
> Dmitry Ansimov
> freelance system administrator
> skype: cardinal-gray


From nginx-forum на forum.nginx.org  Sat Sep 16 20:34:55 2017
From: nginx-forum на forum.nginx.org (S.E.K.T.O.R.)
Date: Sat, 16 Sep 2017 16:34:55 -0400
Subject: =?UTF-8?B?UmU6IG5naW54INC90LUg0L7QsdGA0LDQsdCw0YLRi9Cy0LDQtdGCINC/0L7QtNC0?=
 =?UTF-8?B?0L7QvNC10L0=?=
In-Reply-To: <54946390a76086c64304cfb5bb0e2f39.NginxMailingListRussian@forum.nginx.org>
References: <20130424145523.GO10443@mdounin.ru>
 <54946390a76086c64304cfb5bb0e2f39.NginxMailingListRussian@forum.nginx.org>
Message-ID: <330053d939f8220b98641911a01e3aa3.NginxMailingListRussian@forum.nginx.org>

Kubik129 Wrote:
-------------------------------------------------------
>На самом деле
> имя subdomen2 было зарезервировано для дочернего неймсервера site.com
> и перенаправление происходило на уровне браузера, не доходя до
> собственно nginx'a.
> Так что мораль, проверяйте и еще раз проверяйте, даже если доверяете
> :)

Скажите, как решили проблему? У меня та же история. Был поддомен
sub.mydomain.com. Сейчас создаю sub.mydomain2.com и постоянно получаю
редирект на mydomain2.com. mydomain был на том же IP, что и mydomain2.

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


From mpatutin на gmail.com  Sat Sep 16 20:52:05 2017
From: mpatutin на gmail.com (Mike Patutin)
Date: Sat, 16 Sep 2017 23:52:05 +0300
Subject: ssl renegotiation on nginx 1.13.+
Message-ID: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>

Немного странный вопрос, в чем смысл renegotiation на backend коннектах и
для чего это нужно?

Можно ли применить эти изменения для реализации следующей схемы:

Клиентом является железка, которая умеет ssl соединение с сервером
управления (tomcat).
Железка сначала регистрируется на сервере, и он ей отдает сертификат,
который в последующем используется для  ее авторизации.
Т.е на определенный URL можно сделать запрос по https без корретного
сертификата, на другие - нет
В первый момент железка делает запрос с собственным сертификатом,
выполяняются определенные действия, передается корректный сертификат
авторизации, а потом томкат вызывает тот самый renegotiation и дальнейший
обмен не может быть выполнен без авторизации по сертификату.
Поменять поведение железки - не могу в принципе (жесточайшее legacy, причем
часть просто не обновляемая в принципе)
Томкатом в определенных пределах могу управлять.
Железок много, приходится делать балансировщик. И вот тут я столкнулся с
невозможностью пробросить ssl renegotiation c бекенда на клиента.

Я правильно понимаю что заявленный функционал в 1.13 предназначен для
реализации подобной схемы, или это не так?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170916/94ec27f9/attachment.html>

From nginx-forum на forum.nginx.org  Sun Sep 17 07:08:16 2017
From: nginx-forum на forum.nginx.org (vasiliy586)
Date: Sun, 17 Sep 2017 03:08:16 -0400
Subject: =?UTF-8?B?0JfQsNC/0YDQtdGC0LjRgtGMIFBPU1Qg0LIg0L/QsNC/0LrRgywg0L3QviDRgNCw?=
 =?UTF-8?B?0LfRgNC10YjQuNGC0Ywg0LTQsNC70YzRiNC1?=
Message-ID: <a3eabc392dab46d51aa918e7a401d8d2.NginxMailingListRussian@forum.nginx.org>

Доброго дня! Задача следующая:

Установлен Turtl сервер (бэкенд) и nginx (фронтенд). Требуется закрыть
доступ к location /users с помощью фронтенда, в идеале под пароль, но можно
и просто заблокировать доступ, НО нужен доступ к location
/users/408u30gjejfelf4023fi/ - это папки пользователей Turtl. Пытался такой
конфиг написать:

location /users {
auth_basic "Blah Blah Restricted Content";
auth_basic_user_file /etc/nginx/.passwd;
}

location /users/36bjy346d2h3xs0081000001 {
allow all;
}

Беда в том, что при попытке логина выскакивает запрос на пароль, но пароль
не принимается, этот запрос выскакивает постоянно и дальше не пускает. Как
лучше всего эту проблему решить?

Пробовал так же делать proxy_set_header Authorization "Basic
...(закодировано в Base64)" и proxy_send_header Authorization - никакого
эфекта.

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


From nginx на mva.name  Sun Sep 17 07:57:59 2017
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sun, 17 Sep 2017 14:57:59 +0700
Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCBQT1NUINCyINC/0LDQv9C60YMsINC90L4g?=
 =?UTF-8?B?0YDQsNC30YDQtdGI0LjRgtGMINC00LDQu9GM0YjQtQ==?=
In-Reply-To: <a3eabc392dab46d51aa918e7a401d8d2.NginxMailingListRussian@forum.nginx.org>
References: <a3eabc392dab46d51aa918e7a401d8d2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1870357.xrcvMIVmaC@note>

location = /users {
	deny all;
}

location / {
	...
}

From nginx-forum на forum.nginx.org  Sun Sep 17 09:11:40 2017
From: nginx-forum на forum.nginx.org (vasiliy586)
Date: Sun, 17 Sep 2017 05:11:40 -0400
Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCBQT1NUINCyINC/0LDQv9C60YMsINC90L4g?=
 =?UTF-8?B?0YDQsNC30YDQtdGI0LjRgtGMINC00LDQu9GM0YjQtQ==?=
In-Reply-To: <1870357.xrcvMIVmaC@note>
References: <1870357.xrcvMIVmaC@note>
Message-ID: <6c3a137650dc073fe398f0790e393327.NginxMailingListRussian@forum.nginx.org>

Vadim A. Misbakh-Soloviov Wrote:
-------------------------------------------------------
> location = /users {
> 	deny all;
> }
> 
> location / {
> 	...
> }
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Спасибо, но беда в том, что в данном случае блокируется доступ ВСЕМ
пользователям, включая уже зарегистрированных. А надо только папку /users
блокировать, но разрешать доступ в /users/rjief340fj34jf/

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


From nginx-forum на forum.nginx.org  Sun Sep 17 09:21:52 2017
From: nginx-forum на forum.nginx.org (vasiliy586)
Date: Sun, 17 Sep 2017 05:21:52 -0400
Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCBQT1NUINCyINC/0LDQv9C60YMsINC90L4g?=
 =?UTF-8?B?0YDQsNC30YDQtdGI0LjRgtGMINC00LDQu9GM0YjQtQ==?=
In-Reply-To: <6c3a137650dc073fe398f0790e393327.NginxMailingListRussian@forum.nginx.org>
References: <1870357.xrcvMIVmaC@note>
 <6c3a137650dc073fe398f0790e393327.NginxMailingListRussian@forum.nginx.org>
Message-ID: <317ff40621dfddbf964cf49aea2971f4.NginxMailingListRussian@forum.nginx.org>

И почему-то в логах вот что

access forbidden by rule .... POST /auth HTTP/1.1

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


From mdounin на mdounin.ru  Mon Sep 18 14:18:29 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 18 Sep 2017 17:18:29 +0300
Subject: ssl renegotiation on nginx 1.13.+
In-Reply-To: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>
References: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>
Message-ID: <20170918141829.GA58595@mdounin.ru>

Hello!

On Sat, Sep 16, 2017 at 11:52:05PM +0300, Mike Patutin wrote:

> Немного странный вопрос, в чем смысл renegotiation на backend коннектах и
> для чего это нужно?

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

> Можно ли применить эти изменения для реализации следующей схемы:
> 
> Клиентом является железка, которая умеет ssl соединение с сервером
> управления (tomcat).
> Железка сначала регистрируется на сервере, и он ей отдает сертификат,
> который в последующем используется для  ее авторизации.
> Т.е на определенный URL можно сделать запрос по https без корретного
> сертификата, на другие - нет
> В первый момент железка делает запрос с собственным сертификатом,
> выполяняются определенные действия, передается корректный сертификат
> авторизации, а потом томкат вызывает тот самый renegotiation и дальнейший
> обмен не может быть выполнен без авторизации по сертификату.
> Поменять поведение железки - не могу в принципе (жесточайшее legacy, причем
> часть просто не обновляемая в принципе)
> Томкатом в определенных пределах могу управлять.
> Железок много, приходится делать балансировщик. И вот тут я столкнулся с
> невозможностью пробросить ssl renegotiation c бекенда на клиента.

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

Потому что если клиент прислал сертификат, и сервер управления его 
проверяет - то одной из решаемых задач является защита от 
MitM-атак.  А попытка вставить между ними nginx - это фактически и 
есть MitM-атака.

> Я правильно понимаю что заявленный функционал в 1.13 предназначен для
> реализации подобной схемы, или это не так?

Нет, это не так.

-- 
Maxim Dounin
http://nginx.org/

From mpatutin на gmail.com  Mon Sep 18 14:38:02 2017
From: mpatutin на gmail.com (Mike Patutin)
Date: Mon, 18 Sep 2017 17:38:02 +0300
Subject: ssl renegotiation on nginx 1.13.+
In-Reply-To: <20170918141829.GA58595@mdounin.ru>
References: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>
 <20170918141829.GA58595@mdounin.ru>
Message-ID: <CAOJaRu3xa8Mo5T+wr8w-t8a4PnX9J_=5=_JboZgZ5erKVaLvxQ@mail.gmail.com>

А возможна ли "передача" ssl renegotiation?
Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl
renegotiation от nginx клиенту?.

На данный момент я настроил передачу клиентского ssl сертификата в
заголовке http.
Регистрируюсь напрямую на сервере управления(устройство получает корректный
сертификат), потом подставляю в середину nginx, и схема вполне себе
работает.

Проблема у меня именно в процессе регистрации, поскольку renegotiation с
сервера управления просто теряется.

Буду благодарен за любую информацию. Где в исходниках можно найти связь
между коннектом к backend и коннектом клиента? Как инициировать
renegotiation на клиентском коннекте.
Сейчас уперся в первое. читал Ваши патчи на предмет renegotiation, но
общего понимания внутренней архитектуры у меня пока нет, понять не
получается пока.

Я сознательно оставляю в стороне вопросы безопасности, понимаю, что это
небезопасно, но это внутренняя система, с интернетом не связанная, более
того, работающая в собственной изолированной даже от офиса сети.


18 сентября 2017 г., 17:18 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Sat, Sep 16, 2017 at 11:52:05PM +0300, Mike Patutin wrote:
>
> > Немного странный вопрос, в чем смысл renegotiation на backend коннектах и
> > для чего это нужно?
>
> Это нужно для того, чтобы nginx мог общаться с бекендами, которые
> пытаются инициировать renegotiation для запроса сертификата.
>
> > Можно ли применить эти изменения для реализации следующей схемы:
> >
> > Клиентом является железка, которая умеет ssl соединение с сервером
> > управления (tomcat).
> > Железка сначала регистрируется на сервере, и он ей отдает сертификат,
> > который в последующем используется для  ее авторизации.
> > Т.е на определенный URL можно сделать запрос по https без корретного
> > сертификата, на другие - нет
> > В первый момент железка делает запрос с собственным сертификатом,
> > выполяняются определенные действия, передается корректный сертификат
> > авторизации, а потом томкат вызывает тот самый renegotiation и дальнейший
> > обмен не может быть выполнен без авторизации по сертификату.
> > Поменять поведение железки - не могу в принципе (жесточайшее legacy,
> причем
> > часть просто не обновляемая в принципе)
> > Томкатом в определенных пределах могу управлять.
> > Железок много, приходится делать балансировщик. И вот тут я столкнулся с
> > невозможностью пробросить ssl renegotiation c бекенда на клиента.
>
> Если я правильно понял задачу, то она не решается иначе как
> установлением прямого соединения между клиентом и сервером
> управления.  Ну или сложной логикой, которая бы меняла
> сертификаты, посылаемые клиентом в исходном запросе.
>
> Потому что если клиент прислал сертификат, и сервер управления его
> проверяет - то одной из решаемых задач является защита от
> MitM-атак.  А попытка вставить между ними nginx - это фактически и
> есть MitM-атака.
>
> > Я правильно понимаю что заявленный функционал в 1.13 предназначен для
> > реализации подобной схемы, или это не так?
>
> Нет, это не так.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170918/6f565d3c/attachment.html>

From annulen на yandex.ru  Mon Sep 18 15:23:15 2017
From: annulen на yandex.ru (Konstantin Tokarev)
Date: Mon, 18 Sep 2017 18:23:15 +0300
Subject: ssl renegotiation on nginx 1.13.+
In-Reply-To: <CAOJaRu3xa8Mo5T+wr8w-t8a4PnX9J_=5=_JboZgZ5erKVaLvxQ@mail.gmail.com>
References: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>
 <20170918141829.GA58595@mdounin.ru>
 <CAOJaRu3xa8Mo5T+wr8w-t8a4PnX9J_=5=_JboZgZ5erKVaLvxQ@mail.gmail.com>
Message-ID: <836801505748195@web50j.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170918/5d5fb51e/attachment-0001.html>

From mpatutin на gmail.com  Mon Sep 18 16:05:24 2017
From: mpatutin на gmail.com (Mike Patutin)
Date: Mon, 18 Sep 2017 19:05:24 +0300
Subject: ssl renegotiation on nginx 1.13.+
In-Reply-To: <836801505748195@web50j.yandex.ru>
References: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>
 <20170918141829.GA58595@mdounin.ru>
 <CAOJaRu3xa8Mo5T+wr8w-t8a4PnX9J_=5=_JboZgZ5erKVaLvxQ@mail.gmail.com>
 <836801505748195@web50j.yandex.ru>
Message-ID: <CAOJaRu2WUQzx_2BCoFiE++rKDNuRoOZwb35wOztbH_UwJNttYA@mail.gmail.com>

Это то, что я сделал первым делом.
Но, в этом случае я не могу получить IP клиента, что для меня критично.
Все эти танцы с бубнами затеяны именно для X-Forwarded-For в заголовке.
Если это можно исправить, то будет вполне рабочий вариант.
Вот только можно ли?

18 сентября 2017 г., 18:23 пользователь Konstantin Tokarev <
annulen на yandex.ru> написал:

>
>
> 18.09.2017, 17:38, "Mike Patutin" <mpatutin на gmail.com>:
>
> А возможна ли "передача" ssl renegotiation?
> Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl
> renegotiation от nginx клиенту?.
>
> На данный момент я настроил передачу клиентского ssl сертификата в
> заголовке http.
> Регистрируюсь напрямую на сервере управления(устройство получает
> корректный сертификат), потом подставляю в середину nginx, и схема вполне
> себе работает.
>
> Проблема у меня именно в процессе регистрации, поскольку renegotiation с
> сервера управления просто теряется.
>
> Буду благодарен за любую информацию. Где в исходниках можно найти связь
> между коннектом к backend и коннектом клиента? Как инициировать
> renegotiation на клиентском коннекте.
> Сейчас уперся в первое. читал Ваши патчи на предмет renegotiation, но
> общего понимания внутренней архитектуры у меня пока нет, понять не
> получается пока.
>
> Я сознательно оставляю в стороне вопросы безопасности, понимаю, что это
> небезопасно, но это внутренняя система, с интернетом не связанная, более
> того, работающая в собственной изолированной даже от офиса сети.
>
>
> Можно спроскировать через Nginx TCP-соедине6ние и работать с клиентом
> напрямую
>
>
>
>
> 18 сентября 2017 г., 17:18 пользователь Maxim Dounin <mdounin на mdounin.ru>
> написал:
>
> Hello!
>
> On Sat, Sep 16, 2017 at 11:52:05PM +0300, Mike Patutin wrote:
>
> > Немного странный вопрос, в чем смысл renegotiation на backend коннектах и
> > для чего это нужно?
>
> Это нужно для того, чтобы nginx мог общаться с бекендами, которые
> пытаются инициировать renegotiation для запроса сертификата.
>
> > Можно ли применить эти изменения для реализации следующей схемы:
> >
> > Клиентом является железка, которая умеет ssl соединение с сервером
> > управления (tomcat).
> > Железка сначала регистрируется на сервере, и он ей отдает сертификат,
> > который в последующем используется для  ее авторизации.
> > Т.е на определенный URL можно сделать запрос по https без корретного
> > сертификата, на другие - нет
> > В первый момент железка делает запрос с собственным сертификатом,
> > выполяняются определенные действия, передается корректный сертификат
> > авторизации, а потом томкат вызывает тот самый renegotiation и дальнейший
> > обмен не может быть выполнен без авторизации по сертификату.
> > Поменять поведение железки - не могу в принципе (жесточайшее legacy,
> причем
> > часть просто не обновляемая в принципе)
> > Томкатом в определенных пределах могу управлять.
> > Железок много, приходится делать балансировщик. И вот тут я столкнулся с
> > невозможностью пробросить ssl renegotiation c бекенда на клиента.
>
> Если я правильно понял задачу, то она не решается иначе как
> установлением прямого соединения между клиентом и сервером
> управления.  Ну или сложной логикой, которая бы меняла
> сертификаты, посылаемые клиентом в исходном запросе.
>
> Потому что если клиент прислал сертификат, и сервер управления его
> проверяет - то одной из решаемых задач является защита от
> MitM-атак.  А попытка вставить между ними nginx - это фактически и
> есть MitM-атака.
>
> > Я правильно понимаю что заявленный функционал в 1.13 предназначен для
> > реализации подобной схемы, или это не так?
>
> Нет, это не так.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> 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
>
>
>
> --
> Regards,
> Konstantin
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170918/5f3fcda9/attachment.html>

From mdounin на mdounin.ru  Mon Sep 18 16:41:29 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 18 Sep 2017 19:41:29 +0300
Subject: ssl renegotiation on nginx 1.13.+
In-Reply-To: <CAOJaRu3xa8Mo5T+wr8w-t8a4PnX9J_=5=_JboZgZ5erKVaLvxQ@mail.gmail.com>
References: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>
 <20170918141829.GA58595@mdounin.ru>
 <CAOJaRu3xa8Mo5T+wr8w-t8a4PnX9J_=5=_JboZgZ5erKVaLvxQ@mail.gmail.com>
Message-ID: <20170918164128.GC58595@mdounin.ru>

Hello!

On Mon, Sep 18, 2017 at 05:38:02PM +0300, Mike Patutin wrote:

> А возможна ли "передача" ssl renegotiation?
> Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl
> renegotiation от nginx клиенту?.
> 
> На данный момент я настроил передачу клиентского ssl сертификата в
> заголовке http.
> Регистрируюсь напрямую на сервере управления(устройство получает корректный
> сертификат), потом подставляю в середину nginx, и схема вполне себе
> работает.
> 
> Проблема у меня именно в процессе регистрации, поскольку renegotiation с
> сервера управления просто теряется.

Если бекенд можно научить принимать сертификаты в заголовках - то 
соответствующие сертификаты проще всего запрашивать всегда.  
Честный SSL-клиент тогда просто всегда будет присылать сертификат, 
и его можно будет передать в заголовке не бекенд.

-- 
Maxim Dounin
http://nginx.org/

From mpatutin на gmail.com  Mon Sep 18 16:53:34 2017
From: mpatutin на gmail.com (Mike Patutin)
Date: Mon, 18 Sep 2017 19:53:34 +0300
Subject: ssl renegotiation on nginx 1.13.+
In-Reply-To: <20170918164128.GC58595@mdounin.ru>
References: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>
 <20170918141829.GA58595@mdounin.ru>
 <CAOJaRu3xa8Mo5T+wr8w-t8a4PnX9J_=5=_JboZgZ5erKVaLvxQ@mail.gmail.com>
 <20170918164128.GC58595@mdounin.ru>
Message-ID: <CAOJaRu0JCkvcPZwe_x5dNcSvTcOTFs3dRwF+1JeP1+VVTCysvQ@mail.gmail.com>

Сертификаты я запрашиваю. Бекенд в разумных пределах может быть допилен.
Моя проблема именно в железках, и именно в последовательности регистрации.
Железка генерирует свой запрос сертификата и делает PUT на сервер с первым
запросом, сервер ей генерирует  сертификат по запросу и отдает его назад в
ответе, после чего вызывает renegotiate.
После этого творится некая магия в мозгах железки, и она начинает
использовать свежий сертификат, полученный только что от сервера управления.
Если renegotiate не происходит, железка по второму кругу отдает свой
собственный сертификат и не считает себя зарегистрированной.
Вот как то так. Уже неделю долблюсь в стену. Пока безуспешно. :(

18 сентября 2017 г., 19:41 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Mon, Sep 18, 2017 at 05:38:02PM +0300, Mike Patutin wrote:
>
> > А возможна ли "передача" ssl renegotiation?
> > Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl
> > renegotiation от nginx клиенту?.
> >
> > На данный момент я настроил передачу клиентского ssl сертификата в
> > заголовке http.
> > Регистрируюсь напрямую на сервере управления(устройство получает
> корректный
> > сертификат), потом подставляю в середину nginx, и схема вполне себе
> > работает.
> >
> > Проблема у меня именно в процессе регистрации, поскольку renegotiation с
> > сервера управления просто теряется.
>
> Если бекенд можно научить принимать сертификаты в заголовках - то
> соответствующие сертификаты проще всего запрашивать всегда.
> Честный SSL-клиент тогда просто всегда будет присылать сертификат,
> и его можно будет передать в заголовке не бекенд.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170918/d9508a94/attachment-0001.html>

From mdounin на mdounin.ru  Mon Sep 18 17:44:16 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 18 Sep 2017 20:44:16 +0300
Subject: ssl renegotiation on nginx 1.13.+
In-Reply-To: <CAOJaRu0JCkvcPZwe_x5dNcSvTcOTFs3dRwF+1JeP1+VVTCysvQ@mail.gmail.com>
References: <CAOJaRu2=+nshGQvgkJg-yirRcKPoK2S0JFWsorXdQQ25c5agwg@mail.gmail.com>
 <20170918141829.GA58595@mdounin.ru>
 <CAOJaRu3xa8Mo5T+wr8w-t8a4PnX9J_=5=_JboZgZ5erKVaLvxQ@mail.gmail.com>
 <20170918164128.GC58595@mdounin.ru>
 <CAOJaRu0JCkvcPZwe_x5dNcSvTcOTFs3dRwF+1JeP1+VVTCysvQ@mail.gmail.com>
Message-ID: <20170918174416.GD58595@mdounin.ru>

Hello!

On Mon, Sep 18, 2017 at 07:53:34PM +0300, Mike Patutin wrote:

> Сертификаты я запрашиваю. Бекенд в разумных пределах может быть допилен.
> Моя проблема именно в железках, и именно в последовательности регистрации.
> Железка генерирует свой запрос сертификата и делает PUT на сервер с первым
> запросом, сервер ей генерирует  сертификат по запросу и отдает его назад в
> ответе, после чего вызывает renegotiate.
> После этого творится некая магия в мозгах железки, и она начинает
> использовать свежий сертификат, полученный только что от сервера управления.
> Если renegotiate не происходит, железка по второму кругу отдает свой
> собственный сертификат и не считает себя зарегистрированной.
> Вот как то так. Уже неделю долблюсь в стену. Пока безуспешно. :(

Если железка хочет именно магическую последовательность событий - 
то проще всего прокинуть соединение целиком с помощью модуля 
stream, как тут уже предлагали.  Адрес клиента при этом можно 
прокинуть через PROXY protocol:

http://nginx.org/ru/docs/stream/ngx_stream_proxy_module.html#proxy_protocol

Ну или пытаться воспроизводить эту последовательность в рамках 
nginx'а.  На этом пути потребуется как минимум:

- выпилить детектирование renegotiation и последующее закрытие 
  соединений в src/event/ngx_event_openssl.c;

- как-то выбрать, в какой момент делать renegotiation; если 
  исходить из идеи, что надо делать renegotiation после возврата 
  ответа на запрос регистрации - то, видимо, проще всего сделать 
  body-фильтр, который включать в специальном location'е,
  и там после отправки тела делать SSL_renegotiate().

Пытаться детектировать renegotiation с бекендом и как-то 
транслировать его клиенту - я бы не рекомендовал, возни будет 
много, а толку - чуть.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Wed Sep 20 03:38:18 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Tue, 19 Sep 2017 23:38:18 -0400
Subject: =?UTF-8?B?bmdpbnggY2FjaGUgbWFuYWdlciBwcm9jZXNzINC/0L7RgtGA0LXQsdC70Y/QtdGC?=
 =?UTF-8?B?IENQVSDQsiBuZ3ggcmVzb2x2ZXIgbG9va3VwIG5hbWU=?=
Message-ID: <8872f792a3ffb57b6d66b16c01a1cc47.NginxMailingListRussian@forum.nginx.org>

Дано: nginx 1.13.5 под CentOS 7.3

В perf top:

Children,      Self  Command,          Shared Object,                
Symbol
-   27,63%     0,00%  nginx            [unknown]                     [.]
0000000000000000
   - 0
        24,87% ngx_resolver_lookup_name.isra.1
      - 2,76% __libc_writev

Для ngx_resolver_lookup_name.isra.1 смотрю "Zoom into nginx thread" -- вижу
в списке вызывавшихся функций sys_unlink, ngx_http_file_cache_manager и т.д.
Из этого делаю вывод, что функция потребляет процессор внутри процесса nginx
cache manager.

Смотрю в nginx/src/core/ngx_resolver.c -- вижу, что ngx_resolver_lookup_name
делает только поиск по красно-чёрному дереву.

Вопрос: чем хотя бы примерно может быть вызвано такое большое потребление
процессора этой функцией?

Сервер проксирует ~150 проектов, у каждого свой кэш. Суммарно ~200k файлов
на SSD. Около 300 upstream server's.

Эффект проявляется только на production под большой нагрузкой, поэтому сбор
диагностики несколько затруднён. Непонятно, как применить callgrind или
debug log только к cache manager, не трогая воркеры.

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


From chipitsine на gmail.com  Wed Sep 20 05:00:22 2017
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 20 Sep 2017 10:00:22 +0500
Subject: =?UTF-8?B?UmU6IG5naW54IGNhY2hlIG1hbmFnZXIgcHJvY2VzcyDQv9C+0YLRgNC10LHQu9GP?=
 =?UTF-8?B?0LXRgiBDUFUg0LIgbmd4IHJlc29sdmVyIGxvb2t1cCBuYW1l?=
In-Reply-To: <8872f792a3ffb57b6d66b16c01a1cc47.NginxMailingListRussian@forum.nginx.org>
References: <8872f792a3ffb57b6d66b16c01a1cc47.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGAD2uMBwEO++hFn4BCNtmbHUSHCi1HmBa6=GTT-PuaqA@mail.gmail.com>

привет

мы достаточно успешно запускаем
http://nginx.org/ru/docs/ngx_google_perftools_module.html в продакшене.

заметного оверхеда нет

в результате красивые callgrind-ы

пробовали ?

20 сентября 2017 г., 8:38 пользователь Ilya Evseev <
nginx-forum на forum.nginx.org> написал:

> Дано: nginx 1.13.5 под CentOS 7.3
>
> В perf top:
>
> Children,      Self  Command,          Shared Object,
> Symbol
> -   27,63%     0,00%  nginx            [unknown]                     [.]
> 0000000000000000
>    - 0
>         24,87% ngx_resolver_lookup_name.isra.1
>       - 2,76% __libc_writev
>
> Для ngx_resolver_lookup_name.isra.1 смотрю "Zoom into nginx thread" --
> вижу
> в списке вызывавшихся функций sys_unlink, ngx_http_file_cache_manager и
> т.д.
> Из этого делаю вывод, что функция потребляет процессор внутри процесса
> nginx
> cache manager.
>
> Смотрю в nginx/src/core/ngx_resolver.c -- вижу, что
> ngx_resolver_lookup_name
> делает только поиск по красно-чёрному дереву.
>
> Вопрос: чем хотя бы примерно может быть вызвано такое большое потребление
> процессора этой функцией?
>
> Сервер проксирует ~150 проектов, у каждого свой кэш. Суммарно ~200k файлов
> на SSD. Около 300 upstream server's.
>
> Эффект проявляется только на production под большой нагрузкой, поэтому сбор
> диагностики несколько затруднён. Непонятно, как применить callgrind или
> debug log только к cache manager, не трогая воркеры.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276455,276455#msg-276455
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170920/f1603b64/attachment.html>

From ads на unix4all.com  Wed Sep 20 06:49:04 2017
From: ads на unix4all.com (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdGB0LjQvNC+0LI=?=)
Date: Wed, 20 Sep 2017 09:49:04 +0300
Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0L7QtSDQt9C90LDRh9C10L3QuNC1INC00LvRjyBhcmdfbmFt?=
 =?UTF-8?B?ZSAo0L/QtdGA0LjQvtC00LjRh9C10YHQutC4KQ==?=
In-Reply-To: <5040134.xlBaHYt0IR@cybernote>
References: <CAK-RTX0Yx6hmivYgOkbG9tvWXSkNJosRToNrK2O=2=BUi9RBAQ@mail.gmail.com>
 <5040134.xlBaHYt0IR@cybernote>
Message-ID: <CAK-RTX16q0vDt58y1e5ZQFoHjbscFzg5YtSGcG6pEzKSEcrP8A@mail.gmail.com>

15 сентября 2017 г., 13:47 пользователь Иван <nginx на kinetiksoft.com>
написал:

> Прошу прощения за оффтопик, но $arg_* разве разбирает аргументы POST-
> запроса? Я думал $arg_* только с GET работает.
>

нет, и с POST тоже, по крайней мере нигде не упоминается об ограничениях.

 the $arg_name variable is evaluated to the value of the name URI argument
for the current request


>
> В письме от четверг, 14 сентября 2017 г. 16:53:43 MSK пользователь Дмитрий
> Ансимов написал:
> > Иногда сталкиваюсь с ситуацией, когда логируемый аргумент POST-запроса
> > прописывается прочерком.
> >
> > Подскажите, пожалуйста, почему такое может быть и на что стоит обратить
> > внимание.
> >
> > --
> > Sincerely,
> > Dmitry Ansimov
> > freelance system administrator
> > skype: cardinal-gray
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Sincerely,
Dmitriy Ansimov
freelance system administrator
skype: cardinal-gray
phone: +380505923442
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170920/a082026f/attachment.html>

From ads на unix4all.com  Wed Sep 20 06:53:36 2017
From: ads на unix4all.com (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdGB0LjQvNC+0LI=?=)
Date: Wed, 20 Sep 2017 09:53:36 +0300
Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0L7QtSDQt9C90LDRh9C10L3QuNC1INC00LvRjyBhcmdfbmFt?=
 =?UTF-8?B?ZSAo0L/QtdGA0LjQvtC00LjRh9C10YHQutC4KQ==?=
In-Reply-To: <CAK-RTX16q0vDt58y1e5ZQFoHjbscFzg5YtSGcG6pEzKSEcrP8A@mail.gmail.com>
References: <CAK-RTX0Yx6hmivYgOkbG9tvWXSkNJosRToNrK2O=2=BUi9RBAQ@mail.gmail.com>
 <5040134.xlBaHYt0IR@cybernote>
 <CAK-RTX16q0vDt58y1e5ZQFoHjbscFzg5YtSGcG6pEzKSEcrP8A@mail.gmail.com>
Message-ID: <CAK-RTX1wcGhZip8B=1ke3Lr_f1NWvABZFXDCXcZQWMZ5A8U7Ww@mail.gmail.com>

В документации к nginx URI при этом не упоминается, но описывается так:

argument *name* in the request line

не body. На практике с POST он работает.

20 сентября 2017 г., 9:49 пользователь Дмитрий Ансимов <ads на unix4all.com>
написал:

>
> 15 сентября 2017 г., 13:47 пользователь Иван <nginx на kinetiksoft.com>
> написал:
>
>> Прошу прощения за оффтопик, но $arg_* разве разбирает аргументы POST-
>> запроса? Я думал $arg_* только с GET работает.
>>
>
> нет, и с POST тоже, по крайней мере нигде не упоминается об ограничениях.
>
>  the $arg_name variable is evaluated to the value of the name URI
> argument for the current request
>
>
>>
>> В письме от четверг, 14 сентября 2017 г. 16:53:43 MSK пользователь Дмитрий
>> Ансимов написал:
>> > Иногда сталкиваюсь с ситуацией, когда логируемый аргумент POST-запроса
>> > прописывается прочерком.
>> >
>> > Подскажите, пожалуйста, почему такое может быть и на что стоит обратить
>> > внимание.
>> >
>> > --
>> > Sincerely,
>> > Dmitry Ansimov
>> > freelance system administrator
>> > skype: cardinal-gray
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Sincerely,
> Dmitriy Ansimov
> freelance system administrator
> skype: cardinal-gray
> phone: +380505923442 <+380%2050%20592%203442>
>



-- 
Sincerely,
Dmitriy Ansimov
freelance system administrator
skype: cardinal-gray
phone: +380505923442
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170920/1cfc8df7/attachment-0001.html>

From mdounin на mdounin.ru  Wed Sep 20 12:55:44 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 20 Sep 2017 15:55:44 +0300
Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0L7QtSDQt9C90LDRh9C10L3QuNC1INC00LvRjyBhcmdfbmFt?=
 =?UTF-8?B?ZSAo0L/QtdGA0LjQvtC00LjRh9C10YHQutC4KQ==?=
In-Reply-To: <CAK-RTX1wcGhZip8B=1ke3Lr_f1NWvABZFXDCXcZQWMZ5A8U7Ww@mail.gmail.com>
References: <CAK-RTX0Yx6hmivYgOkbG9tvWXSkNJosRToNrK2O=2=BUi9RBAQ@mail.gmail.com>
 <5040134.xlBaHYt0IR@cybernote>
 <CAK-RTX16q0vDt58y1e5ZQFoHjbscFzg5YtSGcG6pEzKSEcrP8A@mail.gmail.com>
 <CAK-RTX1wcGhZip8B=1ke3Lr_f1NWvABZFXDCXcZQWMZ5A8U7Ww@mail.gmail.com>
Message-ID: <20170920125544.GM58595@mdounin.ru>

Hello!

On Wed, Sep 20, 2017 at 09:53:36AM +0300, Дмитрий Ансимов wrote:

> В документации к nginx URI при этом не упоминается, но описывается так:
> 
> argument *name* in the request line
> 
> не body. На практике с POST он работает.

С POST переменные $arg_* работают только в том смысле, что если 
аргумент есть в _строке_запроса_, то он будет доступен через 
соответствующую переменную вне зависимости от использованного 
метода запроса.

Однако следует иметь в виду, что если написать что-нибудь вроде

<form method="post" action="/foo">
<input type="text" name="bar" value="bazz">
<input type="submit">
</form>

в html-коде, то при отправке формы на сервер уйдёт запрос к /foo с 
содержимым формы в теле запроса.  К полям формы, передаваемым в 
теле запроса, получить доступ через переменные $arg_* нельзя.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Thu Sep 21 06:04:21 2017
From: nginx-forum на forum.nginx.org (emellstornn)
Date: Thu, 21 Sep 2017 02:04:21 -0400
Subject: Nginx+drupal7+redirect
Message-ID: <8f133d43446354a220903a4b65c5b907.NginxMailingListRussian@forum.nginx.org>

Всем привет. Возникла вроде простая задача, но на пути решения столкнулся с
непонятными трудностями.
Есть 4 домена, exapmle.com, example.net, examples.com, examples.net
Надо перенаправить запросы по всем 4 доменам на example.com/?q=example
И тут начинается что-то странное
Если я делаю рерайт через проверку хоста, то все работает прекрасно,
например, так
if ($host !~ example.com) {rewrite ^(.*)$ http://example.com/?q=example?
redirect;}
Но тогда возникает вопрос, что делать, если изначальный хост был
example.com.
Если же делать проверку через аргументы, вида
if (arg_q !~ 'example ) {rewrite ^(.*)$ http://example.com/?q=example?
redirect;}
То все работает, но чертовски медленно, отваливаются все ssl, картинки и
прочее, сайт  возвращается в эпоху web 1.0.
Записи вида rewrite ^(.*)$ http//example.com/?q=example? redirect;
и вовсе приводят к циклическим редиректам.

Подскажите, ЧЯДНТ?
 location @drupal{
         include        fastcgi_params;
         fastcgi_param  QUERY_STRING         q=$uri&$args;
         fastcgi_param  SCRIPT_NAME          /index.php;
    }
 location / {
        try_files $uri /index.php?$query_string; 
        index index.php index.html index.htm;
    }
Спасибо.

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


From lego12239 на yandex.ru  Thu Sep 21 08:35:45 2017
From: lego12239 на yandex.ru (Oleg)
Date: Thu, 21 Sep 2017 11:35:45 +0300
Subject: NGX_POOL_ALIGNMENT
Message-ID: <20170921083544.GA6102@legohost>

  Всем привет.

Кто-нибудь в курсе почему NGX_POOL_ALIGNMENT равен именно 16?

-- 
Олег Неманов (Oleg Nemanov)

From mdounin на mdounin.ru  Thu Sep 21 14:43:12 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 21 Sep 2017 17:43:12 +0300
Subject: NGX_POOL_ALIGNMENT
In-Reply-To: <20170921083544.GA6102@legohost>
References: <20170921083544.GA6102@legohost>
Message-ID: <20170921144312.GX58595@mdounin.ru>

Hello!

On Thu, Sep 21, 2017 at 11:35:45AM +0300, Oleg wrote:

> Кто-нибудь в курсе почему NGX_POOL_ALIGNMENT равен именно 16?

Сколько-нибудь серьёзных причин к тому нет.  Одно время были 
попытки выравнивать пулы по размеру страницы - это хорошо работает 
на FreeBSD, где метаинформация об аллокациях храница отдельно, 
однако плохо показало себя на Линуксе, где метаинформация хранится 
непосредственно перед аллокацией.  В результате выравнивание было 
уменьшено до консервативного значения 16, и с тех пор такое.

-- 
Maxim Dounin
http://nginx.org/

From lego12239 на yandex.ru  Fri Sep 22 08:45:27 2017
From: lego12239 на yandex.ru (Oleg)
Date: Fri, 22 Sep 2017 11:45:27 +0300
Subject: NGX_POOL_ALIGNMENT
In-Reply-To: <20170921144312.GX58595@mdounin.ru>
References: <20170921083544.GA6102@legohost>
 <20170921144312.GX58595@mdounin.ru>
Message-ID: <20170922084527.GA31784@legohost>

On Thu, Sep 21, 2017 at 05:43:12PM +0300, Maxim Dounin wrote:
> On Thu, Sep 21, 2017 at 11:35:45AM +0300, Oleg wrote:
> 
> > Кто-нибудь в курсе почему NGX_POOL_ALIGNMENT равен именно 16?
> 
> Сколько-нибудь серьёзных причин к тому нет.  Одно время были 
> попытки выравнивать пулы по размеру страницы - это хорошо работает 
> на FreeBSD, где метаинформация об аллокациях храница отдельно, 
> однако плохо показало себя на Линуксе, где метаинформация хранится 
> непосредственно перед аллокацией.  В результате выравнивание было 
> уменьшено до консервативного значения 16, и с тех пор такое.

  Т.е. если выставить в 8 (sizeof(void*)), то должно быть норм, так?

-- 
Олег Неманов (Oleg Nemanov)

From eugene.chaykin на i-a-t.net  Fri Sep 22 12:02:32 2017
From: eugene.chaykin на i-a-t.net (Eugene Chaykin)
Date: Fri, 22 Sep 2017 20:02:32 +0800
Subject: =?UTF-8?B?0JrQsNC6INGD0YHQutC+0YDQuNGC0Ywg0L/QtdGA0LXQutC70Y7Rh9C10L3QuNC1?=
 =?UTF-8?B?INCw0L/RgdGC0YDQuNC80L7Qsj8=?=
Message-ID: <0e61a182-b4de-f042-87c3-d17fd0f830bb@i-a-t.net>

Добрый день.

Пытаюсь настроить фэйловер с помощью nginx.
У меня есть два абсолютно аналогичных апстрима.

Хочется получить балансировку нагрузки и фэйловер, если один из 
апстримов по каким-либо причинам отвалится.

Сейчас nginx у меня настроен так:

upstream cdn {
     least_conn;
     server     1.1.1.1:80;
     server     2.2.2.2:80;
}

server {
     listen 3.3.3.3:80;
     server_name cdn.mysite.com;
     proxy_next_upstream error timeout invalid_header http_500 http_502 
http_503 http_504;
…

Пока оба апстрима работают — всё ок, скорость загрузки страницы
примерно 0.5 сек.

Стоит выключить один из них и скорость резко падает, примерно до минуты.

Пробовал прописывать max_fails=1 fail_timeout=30s, но особого эффекта не 
ощутил.
Если в конфиге к отключенному апстриму дописать down, то всё снова 
работает быстро.

Вопрос: ЧЯДНТ и как добиться нормального фэйловера?

--
С уважением,
Евгений

From ek на nginx.com  Sat Sep 23 15:37:41 2017
From: ek на nginx.com (Ekaterina Kukushkina)
Date: Sat, 23 Sep 2017 18:37:41 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0LrQvtGA0LjRgtGMINC/0LXRgNC10LrQu9GO0YfQtdC9?=
 =?UTF-8?B?0LjQtSDQsNC/0YHRgtGA0LjQvNC+0LI/?=
In-Reply-To: <0e61a182-b4de-f042-87c3-d17fd0f830bb@i-a-t.net>
References: <0e61a182-b4de-f042-87c3-d17fd0f830bb@i-a-t.net>
Message-ID: <307EE806-820C-45FF-AB14-A553E45B4B81@nginx.com>

Добрый день.

> On 22 Sep 2017, at 15:02, Eugene Chaykin <eugene.chaykin на i-a-t.net> wrote:
> 
> Стоит выключить один из них и скорость резко падает, примерно до минуты.
> 
> Пробовал прописывать max_fails=1 fail_timeout=30s, но особого эффекта не ощутил.
> Если в конфиге к отключенному апстриму дописать down, то всё снова работает быстро.
> 
> Вопрос: ЧЯДНТ и как добиться нормального фэйловера?

fail_timeout влияет на то, как долго сервер будет считаться недоступным после
фейла. А max_fails=1 так и вовсе дефолтное значение.
А для того, чтобы ускорить переключение, нужно крутить proxy_*_timeout
директивы. По умолчанию все они выставлены в 60 секунд. 

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_read_timeout
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_send_timeout

> 
> --
> С уважением,
> Евгений
> 

--
Ekaterina Kukushkina
NGINX, Inc.


From nginx-forum на forum.nginx.org  Sat Sep 23 18:45:05 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Sat, 23 Sep 2017 14:45:05 -0400
Subject: =?UTF-8?B?0J7Rh9C10L3RjCDQvNC10LTQu9C10L3QvdGL0Lkg0L7RgtCy0LXRgiDQv9C+0YE=?=
 =?UTF-8?B?0LvQtSDQvdC10YHQutC+0LvRjNC60LjRhSDQsdGL0YHRgtGA0YvRhSDQvtGC?=
 =?UTF-8?B?0LLQtdGC0L7Qsg==?=
Message-ID: <233e91c2a7f2a9f51f34c47431157a55.NginxMailingListRussian@forum.nginx.org>

Используется nginx + uwsgi приложение на Python. Первый запрос
обрабатывается медленно в связи с обработкой данных. Но этот запрос не для
клиентов. Запросы от клиентов обрабатываются очень быстро, меньше 10
миллисекунд. Однако после нескольких запросов (6-7)  и быстрых/мгновенных
ответов, после очередного запроса наступает долгая мрачная  тишина на
несколько секунд. Затем вываливаются все ответы. Картина повторяется. Что
может задерживать/блокировать запросы и как с этим бороться?

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


From bgx на protva.ru  Sat Sep 23 19:17:19 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Sat, 23 Sep 2017 22:17:19 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <233e91c2a7f2a9f51f34c47431157a55.NginxMailingListRussian@forum.nginx.org>
References: <233e91c2a7f2a9f51f34c47431157a55.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170923191719.udrc2ky6mljzlax3@protva.ru>

On Sat, Sep 23, 2017 at 02:45:05PM -0400, EugeneNF wrote:
> Используется nginx + uwsgi приложение на Python. Первый запрос
> обрабатывается медленно в связи с обработкой данных. Но этот запрос не для
> клиентов. Запросы от клиентов обрабатываются очень быстро, меньше 10
> миллисекунд. Однако после нескольких запросов (6-7)  и быстрых/мгновенных
> ответов, после очередного запроса наступает долгая мрачная  тишина на
> несколько секунд.

 Чем при этом занят воркер, на каком сисколе висит?

> Затем вываливаются все ответы. Картина повторяется. Что
> может задерживать/блокировать запросы и как с этим бороться?

 Своппинг на хосте с сервером приложений, например. Посмотрите потребление
 памяти, помониторьте обмен с дисками. Посмотрите, нет ли в сообщений от
 ядра об ошибках диска. Попробуйте локализовать место, где происходят
 ожидания, трассировкой системных вызовов nginx.
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Sat Sep 23 19:35:16 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Sat, 23 Sep 2017 15:35:16 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <20170923191719.udrc2ky6mljzlax3@protva.ru>
References: <20170923191719.udrc2ky6mljzlax3@protva.ru>
Message-ID: <9800b322290f7c25f8582518665c031f.NginxMailingListRussian@forum.nginx.org>

Спасибо за ответ.
Сервер пока ничем не занят кроме этой тестовой задачи. 40 ядер, 2Т диск, 32
Г памяти. Во время тишины загрузка нулевая. ОС - CentOS 7. Подскажите как
трассировать nginx. Я - новичок с ним.

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


From bgx на protva.ru  Sat Sep 23 19:43:43 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Sat, 23 Sep 2017 22:43:43 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <9800b322290f7c25f8582518665c031f.NginxMailingListRussian@forum.nginx.org>
References: <20170923191719.udrc2ky6mljzlax3@protva.ru>
 <9800b322290f7c25f8582518665c031f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170923194342.i46f4ky7x62wrt7n@protva.ru>

On Sat, Sep 23, 2017 at 03:35:16PM -0400, EugeneNF wrote:
> Спасибо за ответ.
> Сервер пока ничем не занят кроме этой тестовой задачи. 40 ядер, 2Т диск, 32
> Г памяти. Во время тишины загрузка нулевая. ОС - CentOS 7. Подскажите как
> трассировать nginx. Я - новичок с ним.

 Для CentOS: man strace. В nginx ещё бывает полезен debug log.
-- 
 Eugene Berdnikov

From gmm на csdoc.com  Sat Sep 23 20:37:46 2017
From: gmm на csdoc.com (Gena Makhomed)
Date: Sat, 23 Sep 2017 23:37:46 +0300
Subject: =?UTF-8?B?bmdpbnggbWFpbmxpbmUg0LjQtyDQvtGE0LjRhtC40LDQu9GM0L3QvtCz0L4g0YA=?=
 =?UTF-8?B?0LXQv9C+0LfQuNGC0L7RgNC40Y8gLSDQvdC1INGA0LDQsdC+0YLQsNC10YIg?=
 =?UTF-8?B?SFRUUC8yINCyINCx0YDQsNGD0LfQtdGA0LUgQ2hyb21l?=
Message-ID: <5d43d2bd-8a0f-3025-8431-a8b718ca44f8@csdoc.com>

Здравствуйте, All!

CentOS 7.4 с OpenSSL 1.0.2k-fips (пакет openssl-1.0.2k-8.el7.x86_64)
устанавливаю nginx версии 1.13.5 из официального репозитория mainline
и при этом вижу, что в Google Chrome не работает протокол HTTP/2

почему?

ведь в системе уже установлена новая версия OpenSSL с поддержкой ALPN

# nginx -V
nginx version: nginx/1.13.5
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013

наверное проблема в том, что nginx из официального репозитория mainline
собирается с устаревшей библиотекой OpenSSL 1.0.1e-fips

можно ли как-то исправить эту проблему?

сейчас в nginx.spec прописано Requires: openssl >= 1.0.1

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Sat Sep 23 21:36:19 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Sat, 23 Sep 2017 17:36:19 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <20170923194342.i46f4ky7x62wrt7n@protva.ru>
References: <20170923194342.i46f4ky7x62wrt7n@protva.ru>
Message-ID: <e1d70a787c7ea0c431442aca7f08a722.NginxMailingListRussian@forum.nginx.org>

Я попробовал strace для nginx worker: strace -t -c -p 17630. Но ничего не
печатается до тех пор пока процесс не закончен. Ничего очень долгого я не
вижу. Всё меньше 0.001 сек. Я такжу запустил nginx-debug.  После тягостной
тишины он печатает информацию такую же как и при быстрых ответах (насколько
я могу судить).  И после быстрых ответов и после тишины печатается
epoll_wait() error on fd... Так что эта ошибка, наверное не является
причиной медленного ответа.

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


From mdounin на mdounin.ru  Sat Sep 23 21:56:44 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sun, 24 Sep 2017 00:56:44 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <233e91c2a7f2a9f51f34c47431157a55.NginxMailingListRussian@forum.nginx.org>
References: <233e91c2a7f2a9f51f34c47431157a55.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170923215644.GG58595@mdounin.ru>

Hello!

On Sat, Sep 23, 2017 at 02:45:05PM -0400, EugeneNF wrote:

> Используется nginx + uwsgi приложение на Python. Первый запрос
> обрабатывается медленно в связи с обработкой данных. Но этот запрос не для
> клиентов. Запросы от клиентов обрабатываются очень быстро, меньше 10
> миллисекунд. Однако после нескольких запросов (6-7)  и быстрых/мгновенных
> ответов, после очередного запроса наступает долгая мрачная  тишина на
> несколько секунд. Затем вываливаются все ответы. Картина повторяется. Что
> может задерживать/блокировать запросы и как с этим бороться?

Для начала имеет смысл добавить в логи пременные $request_time и 
$upstream_response_time, их описания тут:

http://nginx.org/r/$request_time/ru
http://nginx.org/r/$upstream_response_time/ru

Подробно о том, как настраивать логгирование, можно прочитать тут:

http://nginx.org/ru/docs/http/ngx_http_log_module.html

По полученным значениям времён будет очевидно, где происходит 
задержка запросов - где-то при общении nginx'а и клиента (время 
$request_time большое, $upstream_response_time - малое), или же 
при общении с бекендом (время $upstream_response_time - большое).

-- 
Maxim Dounin
http://nginx.org/

From bgx на protva.ru  Sat Sep 23 21:56:42 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Sun, 24 Sep 2017 00:56:42 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <e1d70a787c7ea0c431442aca7f08a722.NginxMailingListRussian@forum.nginx.org>
References: <20170923194342.i46f4ky7x62wrt7n@protva.ru>
 <e1d70a787c7ea0c431442aca7f08a722.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170923215642.pv474z5noxa3dd3k@protva.ru>

On Sat, Sep 23, 2017 at 05:36:19PM -0400, EugeneNF wrote:
> Я попробовал strace для nginx worker: strace -t -c -p 17630. Но ничего не
> печатается до тех пор пока процесс не закончен.

 Флаг -c означает "выводить только статистику", потому системные вызовы
 и не печатаются. Уберите его, и поставьте -T (вывод времени, в течение
 которого процесс находился в сисколе), -t замените на -tt.
-- 
 Eugene Berdnikov

From mdounin на mdounin.ru  Sat Sep 23 23:44:13 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sun, 24 Sep 2017 02:44:13 +0300
Subject: NGX_POOL_ALIGNMENT
In-Reply-To: <20170922084527.GA31784@legohost>
References: <20170921083544.GA6102@legohost>
 <20170921144312.GX58595@mdounin.ru>
 <20170922084527.GA31784@legohost>
Message-ID: <20170923234413.GI58595@mdounin.ru>

Hello!

On Fri, Sep 22, 2017 at 11:45:27AM +0300, Oleg wrote:

> On Thu, Sep 21, 2017 at 05:43:12PM +0300, Maxim Dounin wrote:
> > On Thu, Sep 21, 2017 at 11:35:45AM +0300, Oleg wrote:
> > 
> > > Кто-нибудь в курсе почему NGX_POOL_ALIGNMENT равен именно 16?
> > 
> > Сколько-нибудь серьёзных причин к тому нет.  Одно время были 
> > попытки выравнивать пулы по размеру страницы - это хорошо работает 
> > на FreeBSD, где метаинформация об аллокациях храница отдельно, 
> > однако плохо показало себя на Линуксе, где метаинформация хранится 
> > непосредственно перед аллокацией.  В результате выравнивание было 
> > уменьшено до консервативного значения 16, и с тех пор такое.
> 
>   Т.е. если выставить в 8 (sizeof(void*)), то должно быть норм, так?

На практике разницы не будет, в том смысле, что на современных 
64-битных платформах возвращаемая память всё равно будет выровнена 
на 16.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Sun Sep 24 16:06:59 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Sun, 24 Sep 2017 12:06:59 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <20170923215644.GG58595@mdounin.ru>
References: <20170923215644.GG58595@mdounin.ru>
Message-ID: <56e6c206b430945848894959d17185fb.NginxMailingListRussian@forum.nginx.org>

После добавления $request_time и $upstream_response_time стало ясно в чём
проблема. Спасибо!
Клиет посылает запрос, который долго обрабатывается (с AJAX). Затем клиет
посылает второй запрос, который по идее, должен обработаться очень быстро.
Но nginx ждёт пока не закончится первый запрос. Есть ли опция чтобы отменить
первый запрос при получении второго от того же самого клиента?

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


From andriy.tovstik на gmail.com  Sun Sep 24 17:05:48 2017
From: andriy.tovstik на gmail.com (Andriy Tovstik)
Date: Sun, 24 Sep 2017 20:05:48 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0LrQvtGA0LjRgtGMINC/0LXRgNC10LrQu9GO0YfQtdC9?=
 =?UTF-8?B?0LjQtSDQsNC/0YHRgtGA0LjQvNC+0LI/?=
In-Reply-To: <307EE806-820C-45FF-AB14-A553E45B4B81@nginx.com>
References: <0e61a182-b4de-f042-87c3-d17fd0f830bb@i-a-t.net>
 <307EE806-820C-45FF-AB14-A553E45B4B81@nginx.com>
Message-ID: <6BE43936-84DF-4863-859E-5962E812EBF0@gmail.com>

Как вариант , использовать 

https://github.com/yaoweibin/nginx_upstream_check_module
 
Который проверяет живость апстрима и отключает мертвые, а не долбит в них запросами. Ну или купить nginx plus, там это функционал есть. 
Отправлено с iPhone

> 23 сент. 2017 г., в 18:37, Ekaterina Kukushkina <ek на nginx.com> написал(а):
> 
> Добрый день.
> 
>> On 22 Sep 2017, at 15:02, Eugene Chaykin <eugene.chaykin на i-a-t.net> wrote:
>> 
>> Стоит выключить один из них и скорость резко падает, примерно до минуты.
>> 
>> Пробовал прописывать max_fails=1 fail_timeout=30s, но особого эффекта не ощутил.
>> Если в конфиге к отключенному апстриму дописать down, то всё снова работает быстро.
>> 
>> Вопрос: ЧЯДНТ и как добиться нормального фэйловера?
> 
> fail_timeout влияет на то, как долго сервер будет считаться недоступным после
> фейла. А max_fails=1 так и вовсе дефолтное значение.
> А для того, чтобы ускорить переключение, нужно крутить proxy_*_timeout
> директивы. По умолчанию все они выставлены в 60 секунд. 
> 
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_read_timeout
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_send_timeout
> 
>> 
>> --
>> С уважением,
>> Евгений
>> 
> 
> --
> Ekaterina Kukushkina
> NGINX, Inc.
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170924/846b072f/attachment.html>

From koticka на mail.ru  Sun Sep 24 19:17:16 2017
From: koticka на mail.ru (Kostya Alexandrov)
Date: Sun, 24 Sep 2017 22:17:16 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IG1haW5saW5lINC40Lcg0L7RhNC40YbQuNCw0LvRjNC90L7Qs9C+?=
 =?UTF-8?B?INGA0LXQv9C+0LfQuNGC0L7RgNC40Y8gLSDQvdC1INGA0LDQsdC+0YLQsNC1?=
 =?UTF-8?B?0YIgSFRUUC8yINCyINCx0YDQsNGD0LfQtdGA0LUgQ2hyb21l?=
In-Reply-To: <5d43d2bd-8a0f-3025-8431-a8b718ca44f8@csdoc.com>
References: <5d43d2bd-8a0f-3025-8431-a8b718ca44f8@csdoc.com>
Message-ID: <14eefadc-4966-9ca7-2908-a3c813b92052@mail.ru>

This module is not built by default, it should be enabled with 
the|--with-http_v2_module|configuration parameter.


On 23.09.17 23:37, Gena Makhomed wrote:
> Здравствуйте, All!
>
> CentOS 7.4 с OpenSSL 1.0.2k-fips (пакет openssl-1.0.2k-8.el7.x86_64)
> устанавливаю nginx версии 1.13.5 из официального репозитория mainline
> и при этом вижу, что в Google Chrome не работает протокол HTTP/2
>
> почему?
>
> ведь в системе уже установлена новая версия OpenSSL с поддержкой ALPN
>
> # nginx -V
> nginx version: nginx/1.13.5
> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
> built with OpenSSL 1.0.1e-fips 11 Feb 2013
>
> наверное проблема в том, что nginx из официального репозитория mainline
> собирается с устаревшей библиотекой OpenSSL 1.0.1e-fips
>
> можно ли как-то исправить эту проблему?
>
> сейчас в nginx.spec прописано Requires: openssl >= 1.0.1
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170924/c009cdd3/attachment.html>

From alex на vorona.com.ua  Mon Sep 25 07:56:24 2017
From: alex на vorona.com.ua (Alex Vorona)
Date: Mon, 25 Sep 2017 10:56:24 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <56e6c206b430945848894959d17185fb.NginxMailingListRussian@forum.nginx.org>
References: <20170923215644.GG58595@mdounin.ru>
 <56e6c206b430945848894959d17185fb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7279ee3a-1af7-0bdb-569e-cc31f08e4e3f@vorona.com.ua>

Hi,

24.09.17 19:06, EugeneNF wrote:
[...]
> Но nginx ждёт пока не закончится первый запрос. Есть ли опция чтобы отменить
> первый запрос при получении второго от того же самого клиента?
Как вы увидели, что именно nginx "ничего не делает" и просто ждёт ?

--
Alex Vorona

From lego12239 на yandex.ru  Mon Sep 25 08:41:43 2017
From: lego12239 на yandex.ru (lego12239 на yandex.ru)
Date: Mon, 25 Sep 2017 11:41:43 +0300
Subject: NGX_POOL_ALIGNMENT
In-Reply-To: <20170923234413.GI58595@mdounin.ru>
References: <20170921083544.GA6102@legohost>
 <20170921144312.GX58595@mdounin.ru>
 <20170922084527.GA31784@legohost>
 <20170923234413.GI58595@mdounin.ru>
Message-ID: <20170925084143.GA32285@legohost>

On Sun, Sep 24, 2017 at 02:44:13AM +0300, Maxim Dounin wrote:
> On Fri, Sep 22, 2017 at 11:45:27AM +0300, Oleg wrote:
> > 
> >   Т.е. если выставить в 8 (sizeof(void*)), то должно быть норм, так?
> 
> На практике разницы не будет, в том смысле, что на современных 
> 64-битных платформах возвращаемая память всё равно будет выровнена 
> на 16.

  Хм. Максим, я вот что вычитал в man memalign (funtoo linux):

       The glibc malloc(3) always returns 8-byte  aligned  memory  addresses,  so
       these functions are needed only if you require larger alignment values.

  Вы уверены, что 16?

-- 
Олег Неманов (Oleg Nemanov)

From bgx на protva.ru  Mon Sep 25 08:57:24 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 25 Sep 2017 11:57:24 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <7279ee3a-1af7-0bdb-569e-cc31f08e4e3f@vorona.com.ua>
References: <20170923215644.GG58595@mdounin.ru>
 <56e6c206b430945848894959d17185fb.NginxMailingListRussian@forum.nginx.org>
 <7279ee3a-1af7-0bdb-569e-cc31f08e4e3f@vorona.com.ua>
Message-ID: <20170925085724.GB12062@protva.ru>

On Mon, Sep 25, 2017 at 10:56:24AM +0300, Alex Vorona wrote:
> 24.09.17 19:06, EugeneNF wrote:
> [...]
> >Но nginx ждёт пока не закончится первый запрос. Есть ли опция чтобы отменить
> >первый запрос при получении второго от того же самого клиента?
> Как вы увидели, что именно nginx "ничего не делает" и просто ждёт ?

 Гораздо интереснее, как человек представляет себе магию "отмены запроса". :)
-- 
 Eugene Berdnikov

From mdounin на mdounin.ru  Mon Sep 25 11:44:47 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 25 Sep 2017 14:44:47 +0300
Subject: NGX_POOL_ALIGNMENT
In-Reply-To: <20170925084143.GA32285@legohost>
References: <20170921083544.GA6102@legohost>
 <20170921144312.GX58595@mdounin.ru>
 <20170922084527.GA31784@legohost>
 <20170923234413.GI58595@mdounin.ru>
 <20170925084143.GA32285@legohost>
Message-ID: <20170925114447.GB19617@mdounin.ru>

Hello!

On Mon, Sep 25, 2017 at 11:41:43AM +0300, lego12239 на yandex.ru wrote:

> On Sun, Sep 24, 2017 at 02:44:13AM +0300, Maxim Dounin wrote:
> > On Fri, Sep 22, 2017 at 11:45:27AM +0300, Oleg wrote:
> > > 
> > >   Т.е. если выставить в 8 (sizeof(void*)), то должно быть норм, так?
> > 
> > На практике разницы не будет, в том смысле, что на современных 
> > 64-битных платформах возвращаемая память всё равно будет выровнена 
> > на 16.
> 
>   Хм. Максим, я вот что вычитал в man memalign (funtoo linux):
> 
>        The glibc malloc(3) always returns 8-byte  aligned  memory  addresses,  so
>        these functions are needed only if you require larger alignment values.
> 
>   Вы уверены, что 16?

Абсолютно.  Ну то есть это, безусловно, зависит от многих 
факторов, но на Линуксе со штатным аллокатором на 64-битных 
платформах - будет 16:

https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html

: The address of a block returned by malloc or realloc in GNU 
: systems is always a multiple of eight (or sixteen on 64-bit 
: systems).

И на FreeBSD на практике тоже будет 16, причём даже для 32-битных 
платформ - выравнивание 8 возможно только для аллокаций не больше 
8 байт, что в данном случае гарантировано не так.

-- 
Maxim Dounin
http://nginx.org/

From thresh на nginx.com  Mon Sep 25 13:29:26 2017
From: thresh на nginx.com (Konstantin Pavlov)
Date: Mon, 25 Sep 2017 16:29:26 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IG1haW5saW5lINC40Lcg0L7RhNC40YbQuNCw0LvRjNC90L7Qs9C+?=
 =?UTF-8?B?INGA0LXQv9C+0LfQuNGC0L7RgNC40Y8gLSDQvdC1INGA0LDQsdC+0YLQsNC1?=
 =?UTF-8?B?0YIgSFRUUC8yINCyINCx0YDQsNGD0LfQtdGA0LUgQ2hyb21l?=
In-Reply-To: <5d43d2bd-8a0f-3025-8431-a8b718ca44f8@csdoc.com>
References: <5d43d2bd-8a0f-3025-8431-a8b718ca44f8@csdoc.com>
Message-ID: <b7875fa3-84a3-e7f4-8c36-70997a72df9d@nginx.com>

Здравствуйте, Gena,

On 23/09/2017 23:37, Gena Makhomed wrote:
> Здравствуйте, All!
> 
> CentOS 7.4 с OpenSSL 1.0.2k-fips (пакет openssl-1.0.2k-8.el7.x86_64)
> устанавливаю nginx версии 1.13.5 из официального репозитория mainline
> и при этом вижу, что в Google Chrome не работает протокол HTTP/2
> 
> почему?
> 
> ведь в системе уже установлена новая версия OpenSSL с поддержкой ALPN
> 
> # nginx -V
> nginx version: nginx/1.13.5
> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
> built with OpenSSL 1.0.1e-fips 11 Feb 2013
> 
> наверное проблема в том, что nginx из официального репозитория mainline
> собирается с устаревшей библиотекой OpenSSL 1.0.1e-fips
> 
> можно ли как-то исправить эту проблему?
> 
> сейчас в nginx.spec прописано Requires: openssl >= 1.0.1

Тот пакет, что можно установить сейчас собран на более ранней версии CentOS 7, соответственно про ALPN он ничего не знает.

Мы работаем над тем, чтобы пакет для CentOS 7.4+ появился в репозиториях, пока что можно просто собрать вручную как описано в https://nginx.org/en/linux_packages.html#sourcepackages .

-- 
Konstantin Pavlov
www.nginx.com

From mdounin на mdounin.ru  Mon Sep 25 19:24:29 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 25 Sep 2017 22:24:29 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <56e6c206b430945848894959d17185fb.NginxMailingListRussian@forum.nginx.org>
References: <20170923215644.GG58595@mdounin.ru>
 <56e6c206b430945848894959d17185fb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170925192429.GC19617@mdounin.ru>

Hello!

On Sun, Sep 24, 2017 at 12:06:59PM -0400, EugeneNF wrote:

> После добавления $request_time и $upstream_response_time стало ясно в чём
> проблема. Спасибо!
> Клиет посылает запрос, который долго обрабатывается (с AJAX). Затем клиет
> посылает второй запрос, который по идее, должен обработаться очень быстро.
> Но nginx ждёт пока не закончится первый запрос. Есть ли опция чтобы отменить
> первый запрос при получении второго от того же самого клиента?

Скорее всего речь о том, что у бекенда не хватает рабочих 
процессов, и второй запрос просто некому обрабатывать.  И, 
соответственно, второе соединение к бекенду висит и ждёт, пока 
бекенд не закончит обрабатывать первый запрос.  Добавлений рабочих 
процессов бекенду - должно эту проблему решить.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Mon Sep 25 19:27:54 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Mon, 25 Sep 2017 15:27:54 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <20170925085724.GB12062@protva.ru>
References: <20170925085724.GB12062@protva.ru>
Message-ID: <439de56d4aa48463131367754d7e36e7.NginxMailingListRussian@forum.nginx.org>

Представить легко - если кто-то долбит по серверу - отменяется предыдущий
запрос для такого нетерпеливогого клиента. Abort опция. Можно ли что то
такое уровне  nginx, а не не уровне приложения?

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


From annulen на yandex.ru  Mon Sep 25 19:30:29 2017
From: annulen на yandex.ru (Konstantin Tokarev)
Date: Mon, 25 Sep 2017 22:30:29 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <439de56d4aa48463131367754d7e36e7.NginxMailingListRussian@forum.nginx.org>
References: <20170925085724.GB12062@protva.ru>
 <439de56d4aa48463131367754d7e36e7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <180261506367829@web24o.yandex.ru>



25.09.2017, 22:28, "EugeneNF" <nginx-forum на forum.nginx.org>:
> Представить легко - если кто-то долбит по серверу - отменяется предыдущий
> запрос для такого нетерпеливогого клиента. Abort опция. Можно ли что то
> такое уровне nginx, а не не уровне приложения?

http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

Только отменяться будут новые запросы, а не старые

>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,276486,276526#msg-276526
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Regards,
Konstantin

From nginx-forum на forum.nginx.org  Mon Sep 25 23:44:40 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Mon, 25 Sep 2017 19:44:40 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <20170925192429.GC19617@mdounin.ru>
References: <20170925192429.GC19617@mdounin.ru>
Message-ID: <bb19812874f110330e48d8db74b835a0.NginxMailingListRussian@forum.nginx.org>

Пробовал увеличить число вокеров для nginx до 20 и uwsgi тоже до 20. Это не
помогло.

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


From nginx-forum на forum.nginx.org  Mon Sep 25 23:46:35 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Mon, 25 Sep 2017 19:46:35 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <180261506367829@web24o.yandex.ru>
References: <180261506367829@web24o.yandex.ru>
Message-ID: <1bd76ac1898490754e5b4ec1bcabd6ab.NginxMailingListRussian@forum.nginx.org>

Да, это понятно. Я бы хотел противоположное. Старый запрос отменяется, а
новый принимается.

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


From mdounin на mdounin.ru  Tue Sep 26 00:46:35 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 26 Sep 2017 03:46:35 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <bb19812874f110330e48d8db74b835a0.NginxMailingListRussian@forum.nginx.org>
References: <20170925192429.GC19617@mdounin.ru>
 <bb19812874f110330e48d8db74b835a0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170926004635.GG19617@mdounin.ru>

Hello!

On Mon, Sep 25, 2017 at 07:44:40PM -0400, EugeneNF wrote:

> Пробовал увеличить число вокеров для nginx до 20 и uwsgi тоже до 20. Это не
> помогло.

Значит, видимо, проблема где-то глубже в бекенде - какие-то 
блокировки на пользователя, или что-то в этом роде.

Ну или можно предположить, что клиент умудряется слать второй 
запрос в то же соединене, что и первый, но это совсем вряд ли (и 
было бы отчётливо видно по малому $request_time на фоне долгого 
ожидания ответа клиентом).

Отмечу также, что увеличивать количество рабочих процессов nginx'а 
совершенно точно не надо, даже один рабочий процесс способен 
обслуживать тысячи одновременных запросов.

-- 
Maxim Dounin
http://nginx.org/

From bgx на protva.ru  Tue Sep 26 05:53:35 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 26 Sep 2017 08:53:35 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <439de56d4aa48463131367754d7e36e7.NginxMailingListRussian@forum.nginx.org>
References: <20170925085724.GB12062@protva.ru>
 <439de56d4aa48463131367754d7e36e7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170926055335.GA6148@protva.ru>

On Mon, Sep 25, 2017 at 03:27:54PM -0400, EugeneNF wrote:
> Представить легко - если кто-то долбит по серверу - отменяется предыдущий
> запрос для такого нетерпеливогого клиента. Abort опция. Можно ли что то
> такое уровне  nginx, а не не уровне приложения?

 Такое представить легко и просто лишь в виде комбинации слов, за которой
 нет ничего конкретного (в виде механизма или алгоритма).

 Стоит же задуматься о конкретике -- сразу возникают вопросы. Что значит
 "отменить" запрос? Прервать процесс-обработчик? Или убить его? Оборвать
 коннекцию с сервером приложений? Так процесс может продолжить работать,
 и таких может плодиться множество, пока сервер не завалится под нагрузкой.
 А какой статус-код отправить клиенту? Как на него отреагирует браузер?
 И так далее.

 Вообще, это задача не для nginx, а для сервера приложений. Если он видит,
 что пришёл новый запрос, идентичный тому, который обрабатывается, и может
 детектировать ситуацию "результат предыдущего запроса не нужен", то пусть
 свернёт работу по старому запросу и обработает новый.
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Tue Sep 26 08:07:34 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Tue, 26 Sep 2017 04:07:34 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <20170926055335.GA6148@protva.ru>
References: <20170926055335.GA6148@protva.ru>
Message-ID: <3a98c43188eab3f9cf09eaddb74afad2.NginxMailingListRussian@forum.nginx.org>

Тут-то и возникает противоречие - как приложению узнать, что второй запрос
блокирован поскольку nginx ждёт окончания первого запроса?  Решение видится
в два этапа - первое nginx просто обрывает первый запрос. А приложение уже
решает, что же делать при потере связи с клиентом,  т.е. заканчивает работу
с закрытием всего открытого - файлов, баз данных и т.д.

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


From bgx на protva.ru  Tue Sep 26 08:24:29 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 26 Sep 2017 11:24:29 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <3a98c43188eab3f9cf09eaddb74afad2.NginxMailingListRussian@forum.nginx.org>
References: <20170926055335.GA6148@protva.ru>
 <3a98c43188eab3f9cf09eaddb74afad2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170926082429.GP12062@protva.ru>

On Tue, Sep 26, 2017 at 04:07:34AM -0400, EugeneNF wrote:
> Тут-то и возникает противоречие - как приложению узнать, что второй запрос
> блокирован поскольку nginx ждёт окончания первого запроса?  Решение видится
> в два этапа - первое nginx просто обрывает первый запрос.

 Каким образом? Вместо абстрактных фантазий лучше напишите конкретно
 что значит "обрывает запрос" -- какие системные вызовы используются,
 что отправляется клиенту, что серверу приложений? Почему вы думаете,
 что сервер приложений чего-то ждёт от апстрима, чтобы срочно прервать
 свою работу? А если не ждёт, то как он узнает, что запрос нужно
 прекратить обрабатывать?

> А приложение уже решает, что же делать при потере связи с клиентом,

 Как оно узнает о потере связи? Конкретный механизм, pls. Какие вызовы,
 какие пакеты пересылаются, какие сигналы/ошибки/etc получает процесс.

>  т.е. заканчивает работу
> с закрытием всего открытого - файлов, баз данных и т.д.

 А если базе отправлен запрос, который она будет молотить долгое время,
 как его прервать? Это точно такая же проблема, которая возникает при
 взаимодействии сервера приложений и nginx, между которыми нет никакой
 асинхронной коммуникации.
-- 
 Eugene Berdnikov

From lego12239 на yandex.ru  Tue Sep 26 08:33:50 2017
From: lego12239 на yandex.ru (Oleg)
Date: Tue, 26 Sep 2017 11:33:50 +0300
Subject: NGX_POOL_ALIGNMENT
In-Reply-To: <20170925114447.GB19617@mdounin.ru>
References: <20170921083544.GA6102@legohost>
 <20170921144312.GX58595@mdounin.ru>
 <20170922084527.GA31784@legohost>
 <20170923234413.GI58595@mdounin.ru>
 <20170925084143.GA32285@legohost>
 <20170925114447.GB19617@mdounin.ru>
Message-ID: <20170926083350.GA7131@legohost>

On Mon, Sep 25, 2017 at 02:44:47PM +0300, Maxim Dounin wrote:
> 
> Абсолютно.  Ну то есть это, безусловно, зависит от многих 
> факторов, но на Линуксе со штатным аллокатором на 64-битных 
> платформах - будет 16:
> 
> https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html
> 
> : The address of a block returned by malloc or realloc in GNU 
> : systems is always a multiple of eight (or sixteen on 64-bit 
> : systems).

  Спасибо за ссылку. Похоже man для memalign забыли поправить для
64-битных процессоров.
  Для общего понимания, если отвлечься от конкретно ngx_pool,
выравнивания в 8 байт для целых типов(кроме float, double и прочих
SSE/AVX) достаточно для быстрого доступа?
Например, мы выделяем большой кусок памяти и в нём уже выделяем куски
поменьше под всякие char* и выравниваем их на границы 8 байт.

-- 
Олег Неманов (Oleg Nemanov)

From mdounin на mdounin.ru  Tue Sep 26 15:42:33 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 26 Sep 2017 18:42:33 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <3a98c43188eab3f9cf09eaddb74afad2.NginxMailingListRussian@forum.nginx.org>
References: <20170926055335.GA6148@protva.ru>
 <3a98c43188eab3f9cf09eaddb74afad2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170926154233.GO19617@mdounin.ru>

Hello!

On Tue, Sep 26, 2017 at 04:07:34AM -0400, EugeneNF wrote:

> Тут-то и возникает противоречие - как приложению узнать, что второй запрос
> блокирован поскольку nginx ждёт окончания первого запроса?

Тут у вас фактическая ошибка на входе, на которой вы строите свои 
рассуждения, и получаете мусор на выходе.  Нет никакого "второй 
запрос блокирован поскольку nginx ждёт окончания первого запроса".  
С точки зрения nginx'а - запросы независимы, и nginx просто 
передаёт их туда, куда указывает конфигурация.

-- 
Maxim Dounin
http://nginx.org/

From mdounin на mdounin.ru  Wed Sep 27 03:35:19 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 27 Sep 2017 06:35:19 +0300
Subject: NGX_POOL_ALIGNMENT
In-Reply-To: <20170926083350.GA7131@legohost>
References: <20170921083544.GA6102@legohost>
 <20170921144312.GX58595@mdounin.ru>
 <20170922084527.GA31784@legohost>
 <20170923234413.GI58595@mdounin.ru>
 <20170925084143.GA32285@legohost>
 <20170925114447.GB19617@mdounin.ru>
 <20170926083350.GA7131@legohost>
Message-ID: <20170927033518.GS19617@mdounin.ru>

Hello!

On Tue, Sep 26, 2017 at 11:33:50AM +0300, Oleg wrote:

> On Mon, Sep 25, 2017 at 02:44:47PM +0300, Maxim Dounin wrote:
> > 
> > Абсолютно.  Ну то есть это, безусловно, зависит от многих 
> > факторов, но на Линуксе со штатным аллокатором на 64-битных 
> > платформах - будет 16:
> > 
> > https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html
> > 
> > : The address of a block returned by malloc or realloc in GNU 
> > : systems is always a multiple of eight (or sixteen on 64-bit 
> > : systems).
> 
>   Спасибо за ссылку. Похоже man для memalign забыли поправить для
> 64-битных процессоров.
>   Для общего понимания, если отвлечься от конкретно ngx_pool,
> выравнивания в 8 байт для целых типов(кроме float, double и прочих
> SSE/AVX) достаточно для быстрого доступа?
> Например, мы выделяем большой кусок памяти и в нём уже выделяем куски
> поменьше под всякие char* и выравниваем их на границы 8 байт.

Для переменных простых типов - выравнивания на 8 байт AFAIK 
достаточно, чтобы процессор работал быстро (если не брать в расчёт 
SIMD-инструкции).

Дальше могут начинаться всякие нюансы, например, с cacheline size: 
e.g., если мы работаем со структурой в 64 байта размером, и 
cacheline size у нас 64, то выравнивать лучше на те же 64 - тогда 
вся структура будет загружаться в кеш процессора сразу.  Если же 
выравнивать на 8, то одна структура с высокой вероятностью 
разъедется по двум строкам кеша, и соответственно работать это 
будет медленнее, чем могло бы.

-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Wed Sep 27 07:59:31 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Wed, 27 Sep 2017 03:59:31 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <20170926154233.GO19617@mdounin.ru>
References: <20170926154233.GO19617@mdounin.ru>
Message-ID: <31671cc77e78f457d40b3acb25af98bc.NginxMailingListRussian@forum.nginx.org>

Попробую сформулировать по-другому то, что наблюдаю и пробую изменить.
- nginx получает запрос по какому-то IP. Запрос выполняется очень долго.
- посылается второй запрос с того же самого IP, когда предыдыущий запрос ещё
не обработан и ответ не послан. Этот запрос не доходит до приложения, и нет
возможности принять решение внутри приложения, что же делать в таком случае.
Вопрос: можно ли настроить nginx таким образом, чтобы при посылки запроса с
того же самого IP, предыдущий запрос просто обрывался и забывался. Я понимаю
тяжёлые последствия такого сценария, но вопрос сейчас - можно или нельзя с
помощью опции nginx это сделать?

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


From uncleandyv на gmail.com  Wed Sep 27 08:08:42 2017
From: uncleandyv на gmail.com (Andrey Velikoredchanin)
Date: Wed, 27 Sep 2017 11:08:42 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <31671cc77e78f457d40b3acb25af98bc.NginxMailingListRussian@forum.nginx.org>
References: <20170926154233.GO19617@mdounin.ru>
 <31671cc77e78f457d40b3acb25af98bc.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAOrB69MkfgTFBc53YVP1b5yOMgGGzYgjpeF5nQNsijoD=Pw=4w@mail.gmail.com>

С самого начала у меня есть подозрение что приложение запущено в одном
воркере. В таком варианте, если оно не потоковое, запрос и будет
блокироваться до окончания выполнения первого запроса. Может в этом дело?

27 сентября 2017 г., 10:59 пользователь EugeneNF <
nginx-forum на forum.nginx.org> написал:

> Попробую сформулировать по-другому то, что наблюдаю и пробую изменить.
> - nginx получает запрос по какому-то IP. Запрос выполняется очень долго.
> - посылается второй запрос с того же самого IP, когда предыдыущий запрос
> ещё
> не обработан и ответ не послан. Этот запрос не доходит до приложения, и нет
> возможности принять решение внутри приложения, что же делать в таком
> случае.
> Вопрос: можно ли настроить nginx таким образом, чтобы при посылки запроса с
> того же самого IP, предыдущий запрос просто обрывался и забывался. Я
> понимаю
> тяжёлые последствия такого сценария, но вопрос сейчас - можно или нельзя с
> помощью опции nginx это сделать?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276486,276563#msg-276563
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170927/48a693b0/attachment.html>

From nginx-forum на forum.nginx.org  Wed Sep 27 08:12:27 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Wed, 27 Sep 2017 04:12:27 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <20170926082429.GP12062@protva.ru>
References: <20170926082429.GP12062@protva.ru>
Message-ID: <c3400bb45129f3f2bca236519ed10f89.NginxMailingListRussian@forum.nginx.org>

Когда веб сервер получает запрос с какого-то IP, он знает и помнит этот IP.
Если посылается следующий запрос с того же самого IP в тот момент, когда
предыдущий запрос ещё не обработан и ответ не послан, есть ли возможность
настроить nginx, чтобы предыдущий запрос был полностью "разрушен и забыт".
Пока вопрос не о тяжёлых последствия такого сценария, а о принципиальной
возможности.   Мне это реально нужно, поскольку второй запрос не доходит до
приложения и нет возможности правильно завершить первый долгий запрос.

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


From nginx-forum на forum.nginx.org  Wed Sep 27 08:18:25 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Wed, 27 Sep 2017 04:18:25 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <CAOrB69MkfgTFBc53YVP1b5yOMgGGzYgjpeF5nQNsijoD=Pw=4w@mail.gmail.com>
References: <CAOrB69MkfgTFBc53YVP1b5yOMgGGzYgjpeF5nQNsijoD=Pw=4w@mail.gmail.com>
Message-ID: <06f066b3cb228c7e2a9330a9edeb4dd2.NginxMailingListRussian@forum.nginx.org>

Спасибо за ответ. Может быть 20 вокеров было мало. Попробую увеличить до 50.
Но хотелось бы найти вариант застраховаться от "зависания". Поскольку нет
гарантии, что и 50 будет достаточно при посылки запросов со многих IP. Я
хочу для начала просто делать "reset" для зависшего IP и "начинать жизнь
сначала".

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


From nginx на mva.name  Wed Sep 27 08:19:43 2017
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Wed, 27 Sep 2017 15:19:43 +0700
Subject: =?UTF-8?B?0L/QvtCy0YLQvtGA0L3QsNGPINC30LDQs9GA0YPQt9C60LAg0LzQvtC00YPQu9GP?=
Message-ID: <7887439.KFx3pqedfQ@note>

Прошу прощения за глупый вопрос, но, что-то, в коде у меня сходу не получилось 
найти ответ на этот вопрос...

Как NginX относится к повторной загрузке динамического модуля (если 
load_module с тем же самым модулем будет вызван несколько раз)?
Особенно, в случае, когда некоторым другим модулям важно чтобы указанный был 
загружен раньше них (и первый инстанс таки был загружен до них, а потом 
загружен повторно).

Или, наоборот, если модулю важно быть загруженным как можно раньше 
(mod_security, там, какой-нибудь, naxsi и иже с ними), и он таки был, а потом 
был "загружен" повторно.

From uncleandyv на gmail.com  Wed Sep 27 08:33:45 2017
From: uncleandyv на gmail.com (Andrey Velikoredchanin)
Date: Wed, 27 Sep 2017 11:33:45 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <06f066b3cb228c7e2a9330a9edeb4dd2.NginxMailingListRussian@forum.nginx.org>
References: <CAOrB69MkfgTFBc53YVP1b5yOMgGGzYgjpeF5nQNsijoD=Pw=4w@mail.gmail.com>
 <06f066b3cb228c7e2a9330a9edeb4dd2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAOrB69Pru9qP-z3+ni5-YqXuCthMxyj66jQ58EdQuzag_6GyTA@mail.gmail.com>

А пробовали сделать лог своего приложения что-бы определить на каком
моменте останавливается второй запрос? Тогда перед этим местом вы могли-бы,
например, ставить какой-то общедоступный флаг, за которым следил-бы первый
запрос и отрубался при его обнаружении. Т.е. решение тут вообще nginx не
касается - это чисто прикладная задача.

27 сентября 2017 г., 11:18 пользователь EugeneNF <
nginx-forum на forum.nginx.org> написал:

> Спасибо за ответ. Может быть 20 вокеров было мало. Попробую увеличить до
> 50.
> Но хотелось бы найти вариант застраховаться от "зависания". Поскольку нет
> гарантии, что и 50 будет достаточно при посылки запросов со многих IP. Я
> хочу для начала просто делать "reset" для зависшего IP и "начинать жизнь
> сначала".
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276486,276566#msg-276566
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170927/1e406f14/attachment.html>

From chipitsine на gmail.com  Wed Sep 27 08:34:05 2017
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 27 Sep 2017 13:34:05 +0500
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <c3400bb45129f3f2bca236519ed10f89.NginxMailingListRussian@forum.nginx.org>
References: <20170926082429.GP12062@protva.ru>
 <c3400bb45129f3f2bca236519ed10f89.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGrfain1WtGBNZMFTS6VZ4MYnM+ZmSgqXbwgqL6HJMxEw@mail.gmail.com>

привет!

мне кажется, вы сами себя (и всех остальных) загнали в ловушку "я думаю,
что проблема в этом и этом"

не исключено, что это действительно так, но из приведенной диагностики у
меня такой картины не сложилось

можете более подробно объяснить ход вашей диагностики ?

27 сентября 2017 г., 13:12 пользователь EugeneNF <
nginx-forum на forum.nginx.org> написал:

> Когда веб сервер получает запрос с какого-то IP, он знает и помнит этот IP.
> Если посылается следующий запрос с того же самого IP в тот момент, когда
> предыдущий запрос ещё не обработан и ответ не послан, есть ли возможность
> настроить nginx, чтобы предыдущий запрос был полностью "разрушен и забыт".
> Пока вопрос не о тяжёлых последствия такого сценария, а о принципиальной
> возможности.   Мне это реально нужно, поскольку второй запрос не доходит до
> приложения и нет возможности правильно завершить первый долгий запрос.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276486,276565#msg-276565
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170927/b543a7b9/attachment.html>

From ru на nginx.com  Wed Sep 27 08:56:23 2017
From: ru на nginx.com (Ruslan Ermilov)
Date: Wed, 27 Sep 2017 11:56:23 +0300
Subject: =?UTF-8?B?UmU6INC/0L7QstGC0L7RgNC90LDRjyDQt9Cw0LPRgNGD0LfQutCwINC80L7QtNGD?=
 =?UTF-8?B?0LvRjw==?=
In-Reply-To: <7887439.KFx3pqedfQ@note>
References: <7887439.KFx3pqedfQ@note>
Message-ID: <20170927085623.GL55414@lo0.su>

On Wed, Sep 27, 2017 at 03:19:43PM +0700, Vadim A. Misbakh-Soloviov wrote:
> Прошу прощения за глупый вопрос, но, что-то, в коде у меня сходу не получилось 
> найти ответ на этот вопрос...
> Как NginX относится к повторной загрузке динамического модуля (если 
> load_module с тем же самым модулем будет вызван несколько раз)?

nginx: [emerg] module "ngx_http_geoip_module" is already loaded in ./x.conf:6

А у вас не так?

> Особенно, в случае, когда некоторым другим модулям важно чтобы указанный был 
> загружен раньше них (и первый инстанс таки был загружен до них, а потом 
> загружен повторно).
> 
> Или, наоборот, если модулю важно быть загруженным как можно раньше 
> (mod_security, там, какой-нибудь, naxsi и иже с ними), и он таки был, а потом 
> был "загружен" повторно.

From kulmaks на gmail.com  Wed Sep 27 11:44:10 2017
From: kulmaks на gmail.com (Maksim Kulik)
Date: Wed, 27 Sep 2017 14:44:10 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <c3400bb45129f3f2bca236519ed10f89.NginxMailingListRussian@forum.nginx.org>
References: <20170926082429.GP12062@protva.ru>
 <c3400bb45129f3f2bca236519ed10f89.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+zavHkY3fkxLW+jjxvH-6fxAzm+0eEAqMRBrjj2CnMa9iRAEA@mail.gmail.com>

Могу предположить, что нечто подобное вы получите установив
uwsgi_read_timeout в, например, 1-5 секунд (опытным путем подберете удобное
вам значение). Из документации:
"Задаёт таймаут при чтении ответа uwsgi-сервера. Таймаут устанавливается не
на всю передачу ответа, а только между двумя операциями чтения. Если по
истечении этого времени uwsgi-сервер ничего не передаст, соединение
закрывается."

Т.е. при превышении этого лимита nginx просто закроет соединение с вашим
бэкэндом и пусть он (бэкэнд) сам потом решает что делать с обрабатываемым
запросом.

27 сентября 2017 г., 11:12 пользователь EugeneNF <
nginx-forum на forum.nginx.org> написал:

>   Мне это реально нужно, поскольку второй запрос не доходит до
> приложения и нет возможности правильно завершить первый долгий запрос.
>
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170927/abae08dc/attachment.html>

From nginx-forum на forum.nginx.org  Wed Sep 27 15:26:24 2017
From: nginx-forum на forum.nginx.org (neomaq)
Date: Wed, 27 Sep 2017 11:26:24 -0400
Subject: =?UTF-8?B?ZmFzdGNnaSBjYWNoZSB2YWxpZCDQuNCz0L3QvtGA0LjRgNGD0LXRgiDQstGA0LU=?=
 =?UTF-8?B?0LzRjyDQutC10YjQuNGA0L7QstCw0L3QuNGP?=
Message-ID: <c4bff11d59bf49627204f28f921b0285.NginxMailingListRussian@forum.nginx.org>

имеется 

location /ajax/ops {

default_type application/json;
add_header Charset utf-8;

fastcgi_cache_lock on;
fastcgi_cache_lock_timeout 1s;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache MYAPP;
fastcgi_cache_valid 200 20s;
fastcgi_cache_min_uses 0;
add_header X-CACHE $upstream_cache_status;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
fastcgi_hide_header "Set-Cookie";
        root   /var/www
        include         fastcgi_params;
        fastcgi_pass    backend;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME  /var/www/index.php;
access_log  /var/log/nginx/ops.log;
}


при этом по факту все кешируется не на 20 секунд а на 5
в чем может быть дело?

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


From gmm на csdoc.com  Wed Sep 27 16:26:21 2017
From: gmm на csdoc.com (Gena Makhomed)
Date: Wed, 27 Sep 2017 19:26:21 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <31671cc77e78f457d40b3acb25af98bc.NginxMailingListRussian@forum.nginx.org>
References: <20170926154233.GO19617@mdounin.ru>
 <31671cc77e78f457d40b3acb25af98bc.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e3b48d0e-7840-0f50-4950-e28b2755410d@csdoc.com>

On 27.09.2017 10:59, EugeneNF wrote:

Попробую сформулировать по-другому то, что наблюдаю и пробую изменить.
- nginx получает запрос по какому-то IP. Запрос выполняется очень долго.
- посылается второй запрос с того же самого IP, когда предыдыущий запрос ещё
не обработан и ответ не послан. Этот запрос не доходит до приложения, и нет
возможности принять решение внутри приложения, что же делать в таком случае.

В конфиге есть блок upstream
и в этом блоке директива server c параметром max_conns=1 ?

Покажите конфиг на котором воспроизводится эта проблема,
если Вы уверены, что причина проблемы в nginx, а не в бекенде.

Вопрос: можно ли настроить nginx таким образом, чтобы при посылки запроса с
того же самого IP, предыдущий запрос просто обрывался и забывался. Я понимаю
тяжёлые последствия такого сценария, но вопрос сейчас - можно или нельзя с
помощью опции nginx это сделать?

Нельзя.

-- 
Best regards,
  Gena


From lego12239 на yandex.ru  Wed Sep 27 17:59:20 2017
From: lego12239 на yandex.ru (Oleg)
Date: Wed, 27 Sep 2017 20:59:20 +0300
Subject: NGX_POOL_ALIGNMENT
In-Reply-To: <20170927033518.GS19617@mdounin.ru>
References: <20170921083544.GA6102@legohost>
 <20170921144312.GX58595@mdounin.ru>
 <20170922084527.GA31784@legohost>
 <20170923234413.GI58595@mdounin.ru>
 <20170925084143.GA32285@legohost>
 <20170925114447.GB19617@mdounin.ru>
 <20170926083350.GA7131@legohost>
 <20170927033518.GS19617@mdounin.ru>
Message-ID: <20170927175920.GA2776@legohost>

On Wed, Sep 27, 2017 at 06:35:19AM +0300, Maxim Dounin wrote:
> Hello!
> 
> Дальше могут начинаться всякие нюансы, например, с cacheline size: 
> e.g., если мы работаем со структурой в 64 байта размером, и 
> cacheline size у нас 64, то выравнивать лучше на те же 64 - тогда 
> вся структура будет загружаться в кеш процессора сразу.  Если же 
> выравнивать на 8, то одна структура с высокой вероятностью 
> разъедется по двум строкам кеша, и соответственно работать это 
> будет медленнее, чем могло бы.

  Это если на 64 всё выравнивать, то вообще кошмар будет с
утилизацией памяти - сплошные дыры.

-- 
Олег Неманов (Oleg Nemanov)

From nginx-forum на forum.nginx.org  Thu Sep 28 07:51:17 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Thu, 28 Sep 2017 03:51:17 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <CA+zavHkY3fkxLW+jjxvH-6fxAzm+0eEAqMRBrjj2CnMa9iRAEA@mail.gmail.com>
References: <CA+zavHkY3fkxLW+jjxvH-6fxAzm+0eEAqMRBrjj2CnMa9iRAEA@mail.gmail.com>
Message-ID: <7bbe16bc0b88b0c36d31397970d05599.NginxMailingListRussian@forum.nginx.org>

Таймаут не подходит, поскольку в отсутствии второго запроса, первый запрос
должен обработаться до конца независимо от его длительности.

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


From nginx-forum на forum.nginx.org  Thu Sep 28 08:19:26 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Thu, 28 Sep 2017 04:19:26 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <CAFHpkQGrfain1WtGBNZMFTS6VZ4MYnM+ZmSgqXbwgqL6HJMxEw@mail.gmail.com>
References: <CAFHpkQGrfain1WtGBNZMFTS6VZ4MYnM+ZmSgqXbwgqL6HJMxEw@mail.gmail.com>
Message-ID: <cc413c946fc4c17a973970a0821ff617.NginxMailingListRussian@forum.nginx.org>

Как было рекомендовано я добавил  $request_time и $upstream_response_time.
После нескольких запросов и быстрых ответов лог файлы и для nginx и для
uwsgi не показывают ничего. Через время ~1min вываливаются все накопленные
длинные запросы и показывают ожидаемое значения ~1 min для $request_time и 
upstream_response_time. Мой вывод - nginx не принимает новых запросов пока
не обработаются старые длительные. Меня это не устраивает. Я хочу отменить,
сделать reset и т.д.  для старых запросов при получении новых запросов с
того же самого IP.

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


From nginx-forum на forum.nginx.org  Thu Sep 28 08:25:36 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Thu, 28 Sep 2017 04:25:36 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <CAOrB69Pru9qP-z3+ni5-YqXuCthMxyj66jQ58EdQuzag_6GyTA@mail.gmail.com>
References: <CAOrB69Pru9qP-z3+ni5-YqXuCthMxyj66jQ58EdQuzag_6GyTA@mail.gmail.com>
Message-ID: <e0f0893ca88160d3f156f46ffb27a9bc.NginxMailingListRussian@forum.nginx.org>

Конечно я трассирую своё приложение. Проблема в том, что при посылке нового
запроса, он не доходит до приложения. Лог файлы и для nginx и для uwsgi
оживляются только после окончания  долгого запроса.

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


From nginx-forum на forum.nginx.org  Thu Sep 28 08:39:39 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Thu, 28 Sep 2017 04:39:39 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <e3b48d0e-7840-0f50-4950-e28b2755410d@csdoc.com>
References: <e3b48d0e-7840-0f50-4950-e28b2755410d@csdoc.com>
Message-ID: <d74c87e123eb95673d4303aca86c6365.NginxMailingListRussian@forum.nginx.org>

Буду очень признателен, если глянете на мои конфигурационные файлы для nginx
и uwsgi
#########################################################
nginx.conf:

user  nginx;
worker_processes  10;

error_log  /var/log/nginx/error.log debug;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

log_format  main   '$remote_addr| $time_local]| $request| $request_time|
$upstream_response_time| '
                  '$status|$body_bytes_sent|$http_referer|'
                  '$http_user_agent';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;

    keepalive_timeout  100000000;
tcp_nopush on;
tcp_nodelay on;

limit_rate 0;

    disable_symlinks off;

    include /etc/nginx/conf.d/*.conf;
}
###################################################################
nf.conf:

server {
    listen       80;
    server_name  nf.com;
    root   /NF;
 charset win-1251;

    location / {
        index  index.html index.htm;
    }

    location /fs {
        allow all;
        include uwsgi_params;
        uwsgi_pass unix:/run/uwsgi/FS.sock;
        uwsgi_ignore_client_abort on;
        uwsgi_connect_timeout 100000000;
        uwsgi_read_timeout 100000000;
        uwsgi_send_timeout 100000000;

    uwsgi_buffers 64 1M;
    proxy_buffers 64 1M;

tcp_nopush on;
tcp_nodelay on;
limit_rate 0;
#################################################
uwsgi.conf:
[uwsgi]
module = FS:application
master = true
processes = 12
enable-threads
async = 1000
ugreen

max-requests = 5000
post-buffering = false
post-buffering-bufsize = 8192000

listen = 100

uid = nginx
socket = /run/uwsgi/FS.sock
chown-socket = nginx:nginx
chmod-socket = 660
vacuum = true

die-on-term = true

logto = /NF/uwsgi.log

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


From mail на sho0ter.com  Thu Sep 28 09:59:50 2017
From: mail на sho0ter.com (=?UTF-8?B?0JzQsNC60YHQuNC8INCR0LDRiNGC0L7QstC+0Lk=?=)
Date: Thu, 28 Sep 2017 12:59:50 +0300
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSDQv9C+0LTQtNC10YDQttC60L7QuSDRgdGC0LA=?=
 =?UTF-8?B?0YDRi9GFINC/0YDQvtGC0L7QutC+0LvQvtCyINC/0L7RgdC70LUg0L7QsdC9?=
 =?UTF-8?B?0L7QstC70LXQvdC40Y8=?=
Message-ID: <1506592790.64271139@f451.i.mail.ru>


nginx                             1.13.5-1
openssl                           1.1.0f-5
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_certificate /etc/nginx/ssl/chained.crt;
ssl_certificate_key /etc/nginx/ssl/ssl.key;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_prefer_server_ciphers on;
ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4;
ssl_ecdh_curve prime256v1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/ocsp.crt;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
#add_header X-Frame-Options SOMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block;";
SSL тест сообщает:
Protocols
TLS 1.3 No
TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3 No
SSL 2 No

Старые браузеры, соотв., поотваливались
Подскажите, пожалуйста, как вернуть поддержку старых версий TLS?

С уважением,
Максим Баштовой
www.sho0ter.com
mail на sho0ter.com
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170928/fc47358a/attachment.html>

From alex.hha на gmail.com  Thu Sep 28 10:14:12 2017
From: alex.hha на gmail.com (Alex Domoradov)
Date: Thu, 28 Sep 2017 13:14:12 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QvtC00LTQtdGA0LbQutC+0Lkg0YE=?=
 =?UTF-8?B?0YLQsNGA0YvRhSDQv9GA0L7RgtC+0LrQvtC70L7QsiDQv9C+0YHQu9C1INC+?=
 =?UTF-8?B?0LHQvdC+0LLQu9C10L3QuNGP?=
In-Reply-To: <1506592790.64271139@f451.i.mail.ru>
References: <1506592790.64271139@f451.i.mail.ru>
Message-ID: <CAK90gp6BCrTjCCMoig2P67XvuA7raO_DZC80qsEZ67=6QPCR7A@mail.gmail.com>

А у вас только один ssl хост?

On Thu, Sep 28, 2017 at 12:59 PM, Максим Баштовой <mail на sho0ter.com> wrote:

> nginx                             1.13.5-1
> openssl                           1.1.0f-5
>
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
> ssl_certificate /etc/nginx/ssl/chained.crt;
> ssl_certificate_key /etc/nginx/ssl/ssl.key;
> ssl_dhparam /etc/nginx/ssl/dhparam.pem;
> ssl_prefer_server_ciphers on;
> ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4;
> ssl_ecdh_curve prime256v1;
> ssl_session_cache shared:SSL:10m;
> ssl_session_tickets off;
> ssl_stapling on;
> ssl_stapling_verify on;
> ssl_trusted_certificate /etc/nginx/ssl/ocsp.crt;
> resolver 8.8.8.8 8.8.4.4 valid=300s;
> resolver_timeout 5s;
> add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;
> preload";
> #add_header X-Frame-Options SOMEORIGIN;
> add_header X-Content-Type-Options nosniff;
> add_header X-XSS-Protection "1; mode=block;";
>
> SSL тест сообщает:
> Protocols
> TLS 1.3 No
> TLS 1.2 Yes
> TLS 1.1 No
> TLS 1.0 No
> SSL 3 No
> SSL 2 No
>
>
> Старые браузеры, соотв., поотваливались
>
> Подскажите, пожалуйста, как вернуть поддержку старых версий TLS?
>
> С уважением,
> Максим Баштовой
> www.sho0ter.com
> mail на sho0ter.com
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170928/f1e3fa9e/attachment.html>

From mail на sho0ter.com  Thu Sep 28 10:41:35 2017
From: mail на sho0ter.com (=?UTF-8?B?0JzQsNC60YHQuNC8INCR0LDRiNGC0L7QstC+0Lk=?=)
Date: Thu, 28 Sep 2017 13:41:35 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QvtC00LTQtdGA0LbQutC+0Lkg0YE=?=
 =?UTF-8?B?0YLQsNGA0YvRhSDQv9GA0L7RgtC+0LrQvtC70L7QsiDQv9C+0YHQu9C1INC+?=
 =?UTF-8?B?0LHQvdC+0LLQu9C10L3QuNGP?=
In-Reply-To: <CAK90gp6BCrTjCCMoig2P67XvuA7raO_DZC80qsEZ67=6QPCR7A@mail.gmail.com>
References: <1506592790.64271139@f451.i.mail.ru>
 <CAK90gp6BCrTjCCMoig2P67XvuA7raO_DZC80qsEZ67=6QPCR7A@mail.gmail.com>
Message-ID: <01fea7fd-4ea5-255f-ef40-c14ef4e17cb1@sho0ter.com>

Да, только один.
Пробовал еще включать и выключать http2 - ничего не меняется.

28.09.2017 13:14, Alex Domoradov пишет:
> А у вас только один ssl хост?
>
> On Thu, Sep 28, 2017 at 12:59 PM, Максим Баштовой <mail на sho0ter.com 
> <mailto:mail на sho0ter.com>> wrote:
>
>     nginx                             1.13.5-1
>     openssl                           1.1.0f-5
>
>     ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
>     ssl_certificate /etc/nginx/ssl/chained.crt;
>     ssl_certificate_key /etc/nginx/ssl/ssl.key;
>     ssl_dhparam /etc/nginx/ssl/dhparam.pem;
>     ssl_prefer_server_ciphers on;
>     ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4;
>     ssl_ecdh_curve prime256v1;
>     ssl_session_cache shared:SSL:10m;
>     ssl_session_tickets off;
>     ssl_stapling on;
>     ssl_stapling_verify on;
>     ssl_trusted_certificate /etc/nginx/ssl/ocsp.crt;
>     resolver 8.8.8.8 8.8.4.4 valid=300s;
>     resolver_timeout 5s;
>     add_header Strict-Transport-Security "max-age=31536000;
>     includeSubDomains; preload";
>     #add_header X-Frame-Options SOMEORIGIN;
>     add_header X-Content-Type-Options nosniff;
>     add_header X-XSS-Protection "1; mode=block;";
>
>     SSL тест сообщает:
>
>     Protocols
>     TLS 1.3 	No
>     TLS 1.2 	Yes
>     TLS 1.1 	No
>     TLS 1.0 	No
>     SSL 3 	No
>     SSL 2 	No
>
>
>     Старые браузеры, соотв., поотваливались
>
>     Подскажите, пожалуйста, как вернуть поддержку старых версий TLS?
>
>     С уважением,
>     Максим Баштовой
>     www.sho0ter.com <http://www.sho0ter.com>
>     mail на sho0ter.com <mailto:mail на sho0ter.com>
>
>
>     _______________________________________________
>     nginx-ru mailing list
>     nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>     http://mailman.nginx.org/mailman/listinfo/nginx-ru
>     <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
>
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
С уважением,
Максим "Sho0ter" Баштовой
www.sho0ter.com
mail на sho0ter.com

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170928/f0ffa251/attachment-0001.html>

From nginx на mva.name  Thu Sep 28 10:50:13 2017
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 28 Sep 2017 17:50:13 +0700
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <cc413c946fc4c17a973970a0821ff617.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGrfain1WtGBNZMFTS6VZ4MYnM+ZmSgqXbwgqL6HJMxEw@mail.gmail.com>
 <cc413c946fc4c17a973970a0821ff617.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7174268.ldHrQdZANe@note>

В письме от четверг, 28 сентября 2017 г. 15:19:26 +07 пользователь EugeneNF 
написал:
> Как было рекомендовано я добавил  $request_time и $upstream_response_time.
> После нескольких запросов и быстрых ответов лог файлы и для nginx и для
> uwsgi не показывают ничего. Через время ~1min вываливаются все накопленные
> длинные запросы и показывают ожидаемое значения ~1 min для $request_time и
> upstream_response_time. Мой вывод - nginx не принимает новых запросов пока
Неправильный вывод.
Правильный - апстрим (бекенд) ковыряет в носу в течение минуты и только после 
этого отвечает. 
> не обработаются старые длительные. Меня это не устраивает. Я хочу отменить,
> сделать reset и т.д.  для старых запросов при получении новых запросов с
> того же самого IP.
Вам уже как минимум трижды сказали: делайте это на бекенде и всё будет 
работать как вы хотите.

From nginx на mva.name  Thu Sep 28 10:54:31 2017
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 28 Sep 2017 17:54:31 +0700
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <d74c87e123eb95673d4303aca86c6365.NginxMailingListRussian@forum.nginx.org>
References: <e3b48d0e-7840-0f50-4950-e28b2755410d@csdoc.com>
 <d74c87e123eb95673d4303aca86c6365.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2769481.KIhIVK3jXo@note>

1) местами от ваших конфигов возникает чувство что делались по статье "как 
сделать всё в самых bad practices что только есть", но не буду учить, ладно.

2) попробуйте заменить unix-сокет между NgX и uwsgi на tcp

From gmm на csdoc.com  Thu Sep 28 12:03:20 2017
From: gmm на csdoc.com (Gena Makhomed)
Date: Thu, 28 Sep 2017 15:03:20 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <d74c87e123eb95673d4303aca86c6365.NginxMailingListRussian@forum.nginx.org>
References: <e3b48d0e-7840-0f50-4950-e28b2755410d@csdoc.com>
 <d74c87e123eb95673d4303aca86c6365.NginxMailingListRussian@forum.nginx.org>
Message-ID: <6fac062e-6d61-a1a2-1938-65f9cb68808c@csdoc.com>

On 28.09.2017 11:39, EugeneNF wrote:

> error_log  /var/log/nginx/error.log debug;

для того чтобы получить отладочный лог
надо переключить бинарник на nginx-debug
подробнее об этом тут: http://nginx.org/ru/docs/debugging_log.html

для отладки удобно включать только debug_connection
с определенного IP-адреса, чтобы лог не был очень большим.

кроме того, не понятно какая у Вас стоит версия nginx,
что показывает "nginx -V" ?

воспроизводится ли проблема,
если взять nginx из официального репозитория
http://nginx.org/ru/linux_packages.html#mainline ?

>      keepalive_timeout  100000000;

>          uwsgi_connect_timeout 100000000;
>          uwsgi_read_timeout 100000000;
>          uwsgi_send_timeout 100000000;

лучше оставить дефолтовые значения этих параметров.

 >      uwsgi_buffers 64 1M;
 >      proxy_buffers 64 1M;

слишком большие значения, если выделять по 64 мегабайта памяти
на одно клиентское соединение - то память очень быстро закончится.

лучше использовать дефолтовые значения этих параметров.

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Thu Sep 28 19:06:25 2017
From: nginx-forum на forum.nginx.org (EugeneNF)
Date: Thu, 28 Sep 2017 15:06:25 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <2769481.KIhIVK3jXo@note>
References: <2769481.KIhIVK3jXo@note>
Message-ID: <578f81530c77c85c2bd1b5347fc13d67.NginxMailingListRussian@forum.nginx.org>

Так это всё экспериментальные значения, на которые заменялись параметры по
умолчанию.
Я получил ровно один прямой ответ на то, что я бы хотел иметь от nginx:
"Нельзя".

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


From annulen на yandex.ru  Fri Sep 29 11:21:13 2017
From: annulen на yandex.ru (Konstantin Tokarev)
Date: Fri, 29 Sep 2017 14:21:13 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L8=?=
 =?UTF-8?B?0L7RgdC70LUg0L3QtdGB0LrQvtC70YzQutC40YUg0LHRi9GB0YLRgNGL0YUg?=
 =?UTF-8?B?0L7RgtCy0LXRgtC+0LI=?=
In-Reply-To: <578f81530c77c85c2bd1b5347fc13d67.NginxMailingListRussian@forum.nginx.org>
References: <2769481.KIhIVK3jXo@note>
 <578f81530c77c85c2bd1b5347fc13d67.NginxMailingListRussian@forum.nginx.org>
Message-ID: <719441506684073@web51j.yandex.ru>



28.09.2017, 22:06, "EugeneNF" <nginx-forum на forum.nginx.org>:
> Так это всё экспериментальные значения, на которые заменялись параметры по
> умолчанию.
> Я получил ровно один прямой ответ на то, что я бы хотел иметь от nginx:
> "Нельзя".

Просто при виде такого вопроса невольно подозреваешь XY problem

>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,276486,276609#msg-276609
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Regards,
Konstantin