From nginx-forum на forum.nginx.org Thu Nov 3 16:54:36 2016 From: nginx-forum на forum.nginx.org (tester0) Date: Thu, 03 Nov 2016 12:54:36 -0400 Subject: =?UTF-8?B?0L3QtSDQv9C+0L/QsNC00LDRjiDQsiDQvdGD0LbQvdGL0LkgVmlydHVhbCBzZXJ2?= =?UTF-8?B?ZXI=?= Message-ID: <147097ff00906c0bd27eaf9e65bb4754.NginxMailingListRussian@forum.nginx.org> есть несколько virtualhost'ов и есть домен не описанный ни в одном из файлов конфигурации, есть конфигурация, описанная как listen 80 default_server; и... домен попадает в конфигурацию, которая идет первой по алфавитному списку, причем не в default_server почему такое может быть? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270733,270733#msg-270733 From mdounin на mdounin.ru Thu Nov 3 17:20:15 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 3 Nov 2016 20:20:15 +0300 Subject: =?UTF-8?B?UmU6INC90LUg0L/QvtC/0LDQtNCw0Y4g0LIg0L3Rg9C20L3Ri9C5IFZpcnR1YWwg?= =?UTF-8?B?c2VydmVy?= In-Reply-To: <147097ff00906c0bd27eaf9e65bb4754.NginxMailingListRussian@forum.nginx.org> References: <147097ff00906c0bd27eaf9e65bb4754.NginxMailingListRussian@forum.nginx.org> Message-ID: <20161103172015.GU73038@mdounin.ru> Hello! On Thu, Nov 03, 2016 at 12:54:36PM -0400, tester0 wrote: > есть несколько virtualhost'ов > > и есть домен не описанный ни в одном из файлов конфигурации, > есть конфигурация, описанная как listen 80 default_server; > > и... > > домен попадает в конфигурацию, которая идет первой по алфавитному списку, > причем не в default_server > > почему такое может быть? Простейшее объяснение - у вас используется более одного listen-сокета, и вы это не учли. Важно понимать: "listen 80 default_server" задаёт сервер по умолчанию для конкретного listen-сокета, а не для вообще всех listen-сокетов в конфигурации. Соответственно в конфигурации вида server { listen 127.0.0.1:80; server_name one.example.com; ... } server { listen 80 default_server; server_name two.example.com; ... } для соединений, приходящих на 127.0.0.1:80, сервером по умолчанию будет one.example.com, а для всех остальных - two.example.com. Подробнее про всё это можно почитать в документации, например тут: http://nginx.org/ru/docs/http/request_processing.html Если вопросы всё ещё остались - приносите конфиг, работу которого не можете понять, подскажем, что именно происходит. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Fri Nov 4 14:15:26 2016 From: nginx-forum на forum.nginx.org (sysadm) Date: Fri, 04 Nov 2016 10:15:26 -0400 Subject: =?UTF-8?B?0KDQtdC00LjRgNC10LrRgiDQvdCwINC90LXQvtCx0YXQvtC00LjQvNGL0Lkg0YM=?= =?UTF-8?B?0YDQuyDQsiDRgtC+0Lwg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQv9GA?= =?UTF-8?B?0L7RgSDQstC60LvRjtGH0LDQtdGCINC/0LDRgNCw0LzQtdGC0YDRiyDQuCA=?= =?UTF-8?B?0YHQvtC+0YLQstC10YLRgdGC0LLRg9C10YIg0L/QsNGC0YLQtdGA0L3Rgw==?= Message-ID: У меня довольно странный вопрос, не могу что-то нагуглить похожую проблему. Если мне надо организовать обычный редирект с одного урла на другой в котором просто категории или human-readable линк я поступаю так: rewrite ^(/56184-example-link-to-redirect-79e3100/)$ /target/link permanent; Но в последнее время владелец ecommerce хочет делать редиректы типа: rewrite ^(/example-category?collection=collection-name&filter=filter-var1)$ /target/link permanent; причем после знака ? идёт иногда один параметр или два как в примере выше, а иногда гораздо больше. Я прекрасно понимаю и транслирую владельцу сервиса, что параметры могут меняться местами. Ему пофиг, поскольку где-то в гугле закешировалось и фигурирует в таком виде. Соответственно надо заставить нгинкс распознавать весь урл как одно целое. К сожалению для nginx всё что идет после знака ? это массив с аргументами и на каждый такой массив надо было бы клепать костыли с кучей if-ов с учётом каждого параметра по отдельности. С учётом того, что подобных редиректов мне приходит список на пару сотен - сделать что-то подобное руками - нереально. Парсить и генерить конфигурацию с частоколом if-ов тоже не айс. Что делать, граждане дорогие? Можно как-то сломать поведение нгинкса, чтобы он без лишнего анализа и разбора параметров в $ARG сделал то что я хочу? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270765,270765#msg-270765 From bogdar на gmail.com Fri Nov 4 16:23:57 2016 From: bogdar на gmail.com (Bogdan) Date: Fri, 4 Nov 2016 19:23:57 +0300 Subject: =?UTF-8?B?0JrQsNC6INC/0YDQsNCy0LjQu9GM0L3QviDQvdCw0YHRgtGA0L7QuNGC0Ywg0Lw=?= =?UTF-8?B?0L3QvtC20LXRgdGC0LLQviDQvtC00L3QvtGC0LjQv9C90YvRhSBzZXJ2ZXIg?= =?UTF-8?B?0YEgc3NsPw==?= Message-ID: Добрый день! Есть множество однотипных хостов, каждый со своим сертификатом. Хотелось бы сделать что-то типа: server { listen 0.0.0.0:443 ssl; server_name commonserver; ssl_certificate /path/to/*$host*.crt; ssl_certificate_key /path/to/*$host*.key include /path/to/common.conf; { Т.к. сертификат может быть защищён паролем и т.п., раскрытие $host во время обработки запроса невозможно. Вместе с тем, писать множество конфигов отличающихся только сертификатом как-то не хотелось бы. Сливать сертификаты в один большой файл тоже не очень удобно (да и будет ли работать?) т.к. сроки действия у разных сертификатов разные, выдёргивать истекающие из простыни текста не просто. Есть ли какое-то гуманное решение помимо генерации конфигов по шаблону? Спасибо. -- WBR, Bogdan B. Rudas ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From medvedev.yp на gmail.com Fri Nov 4 16:27:23 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Fri, 4 Nov 2016 19:27:23 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L3QsNGB0YLRgNC+0LjRgtGM?= =?UTF-8?B?INC80L3QvtC20LXRgdGC0LLQviDQvtC00L3QvtGC0LjQv9C90YvRhSBzZXJ2?= =?UTF-8?B?ZXIg0YEgc3NsPw==?= In-Reply-To: References: Message-ID: Здравствуйте,Puppet,ansible,certbot, etc... 4 ноября 2016 г., 19:23 пользователь Bogdan написал: > Добрый день! > > Есть множество однотипных хостов, каждый со своим сертификатом. Хотелось > бы сделать что-то типа: > server { > listen 0.0.0.0:443 ssl; > server_name commonserver; > ssl_certificate /path/to/*$host*.crt; > ssl_certificate_key /path/to/*$host*.key > include /path/to/common.conf; > { > > Т.к. сертификат может быть защищён паролем и т.п., раскрытие $host во > время обработки запроса невозможно. Вместе с тем, писать множество конфигов > отличающихся только сертификатом как-то не хотелось бы. Сливать сертификаты > в один большой файл тоже не очень удобно (да и будет ли работать?) т.к. > сроки действия у разных сертификатов разные, выдёргивать истекающие из > простыни текста не просто. > > Есть ли какое-то гуманное решение помимо генерации конфигов по шаблону? > > Спасибо. > -- > WBR, Bogdan B. Rudas > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Fri Nov 4 16:58:54 2016 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 4 Nov 2016 18:58:54 +0200 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQvdC10L7QsdGF0L7QtNC40LzRi9C5?= =?UTF-8?B?INGD0YDQuyDQsiDRgtC+0Lwg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LA=?= =?UTF-8?B?0L/RgNC+0YEg0LLQutC70Y7Rh9Cw0LXRgiDQv9Cw0YDQsNC80LXRgtGA0Ysg?= =?UTF-8?B?0Lgg0YHQvtC+0YLQstC10YLRgdGC0LLRg9C10YIg0L/QsNGC0YLQtdGA0L0=?= =?UTF-8?B?0YM=?= In-Reply-To: References: Message-ID: <1129bc0f-e773-fe19-c43f-6a14a0b95987@csdoc.com> On 04.11.2016 16:15, sysadm wrote: > У меня довольно странный вопрос, не могу что-то нагуглить похожую проблему. > Если мне надо организовать обычный редирект с одного урла на другой в > котором просто категории или human-readable линк я поступаю так: > rewrite ^(/56184-example-link-to-redirect-79e3100/)$ /target/link > permanent; > > Но в последнее время владелец ecommerce хочет делать редиректы типа: > > rewrite ^(/example-category?collection=collection-name&filter=filter-var1)$ > /target/link permanent; > > причем после знака ? идёт иногда один параметр или два как в примере выше, а > иногда гораздо больше. Я прекрасно понимаю и транслирую владельцу сервиса, > что параметры могут меняться местами. Ему пофиг, поскольку где-то в гугле > закешировалось и фигурирует в таком виде. Соответственно надо заставить > нгинкс распознавать весь урл как одно целое. К сожалению для nginx всё что > идет после знака ? это массив с аргументами и на каждый такой массив надо > было бы клепать костыли с кучей if-ов с учётом каждого параметра по > отдельности. С учётом того, что подобных редиректов мне приходит список на > пару сотен - сделать что-то подобное руками - нереально. Парсить и генерить > конфигурацию с частоколом if-ов тоже не айс. Что делать, граждане дорогие? > Можно как-то сломать поведение нгинкса, чтобы он без лишнего анализа и > разбора параметров в $ARG сделал то что я хочу? В модуле http://nginx.org/ru/docs/http/ngx_http_core_module.html есть переменная $request_uri - первоначальный URI запроса целиком (с аргументами) дальше http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html if ( $request_uri ~ "/example-category?collection=collection-name&filter=filter-var1" ) { return 301 /target/link permanent; } -- Best regards, Gena From nginx-forum на forum.nginx.org Sat Nov 5 06:43:01 2016 From: nginx-forum на forum.nginx.org (sysadm) Date: Sat, 05 Nov 2016 02:43:01 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQvdC10L7QsdGF0L7QtNC40LzRi9C5?= =?UTF-8?B?INGD0YDQuyDQsiDRgtC+0Lwg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LA=?= =?UTF-8?B?0L/RgNC+0YEg0LLQutC70Y7Rh9Cw0LXRgiDQv9Cw0YDQsNC80LXRgtGA0Ysg?= =?UTF-8?B?0Lgg0YHQvtC+0YLQstC10YLRgdGC0LLRg9C10YIg0L/QsNGC0YLQtdGA0L0=?= =?UTF-8?B?0YM=?= In-Reply-To: <1129bc0f-e773-fe19-c43f-6a14a0b95987@csdoc.com> References: <1129bc0f-e773-fe19-c43f-6a14a0b95987@csdoc.com> Message-ID: <22524a74c3edd170cdb12d7be59a050b.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ, Гена. Я думал уже над чем-то подобным, но это означает что сколько редиректов - столько ифов у нас появится. Т.е. будет несколько сотен - будет несколько сотен ифов. А если приедет следующий список на несколько тысяч подобных редиректов? Нормально ли это и насколько это скажется на производительности? Помимо этого с такой конструкцией нгинксу не нравится синтаксис: nginx: [emerg] invalid number of arguments in "return" directive in /etc/nginx/redirects/ecommerce.conf:2 nginx: configuration file /etc/nginx/nginx.conf test failed Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270765,270781#msg-270781 From gmm на csdoc.com Sat Nov 5 08:19:49 2016 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 5 Nov 2016 10:19:49 +0200 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQvdC10L7QsdGF0L7QtNC40LzRi9C5?= =?UTF-8?B?INGD0YDQuyDQsiDRgtC+0Lwg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LA=?= =?UTF-8?B?0L/RgNC+0YEg0LLQutC70Y7Rh9Cw0LXRgiDQv9Cw0YDQsNC80LXRgtGA0Ysg?= =?UTF-8?B?0Lgg0YHQvtC+0YLQstC10YLRgdGC0LLRg9C10YIg0L/QsNGC0YLQtdGA0L0=?= =?UTF-8?B?0YM=?= In-Reply-To: <22524a74c3edd170cdb12d7be59a050b.NginxMailingListRussian@forum.nginx.org> References: <1129bc0f-e773-fe19-c43f-6a14a0b95987@csdoc.com> <22524a74c3edd170cdb12d7be59a050b.NginxMailingListRussian@forum.nginx.org> Message-ID: <95a3fd05-e731-90ef-4431-6a3f12fabc1b@csdoc.com> On 05.11.2016 8:43, sysadm wrote: > Спасибо за ответ, Гена. Я думал уже над чем-то подобным, но это означает что > сколько редиректов - столько ифов у нас появится. Т.е. будет несколько сотен > - будет несколько сотен ифов. А если приедет следующий список на несколько > тысяч подобных редиректов? Нормально ли это и насколько это скажется на > производительности? Тогда http://nginx.org/ru/docs/http/ngx_http_map_module.html http { map $request_uri $target_uri { /example-category?col=name&filter=filter-var1 /target/link; # ... } server { if ($target_uri) { return 301 $target_uri; } > Помимо этого с такой конструкцией нгинксу не нравится синтаксис: > nginx: [emerg] invalid number of arguments in "return" directive in > /etc/nginx/redirects/ecommerce.conf:2 > nginx: configuration file /etc/nginx/nginx.conf test failed http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return Синтаксис: return код URL; -- Best regards, Gena From nginx на kinetiksoft.com Sat Nov 5 21:21:43 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Sun, 06 Nov 2016 00:21:43 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQvdC10L7QsdGF0L7QtNC40LzRi9C5?= =?UTF-8?B?INGD0YDQuyDQsiDRgtC+0Lwg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LA=?= =?UTF-8?B?0L/RgNC+0YEg0LLQutC70Y7Rh9Cw0LXRgiDQv9Cw0YDQsNC80LXRgtGA0Ysg?= =?UTF-8?B?0Lgg0YHQvtC+0YLQstC10YLRgdGC0LLRg9C10YIg0L/QsNGC0YLQtdGA0L0=?= =?UTF-8?B?0YM=?= In-Reply-To: <95a3fd05-e731-90ef-4431-6a3f12fabc1b@csdoc.com> References: <1129bc0f-e773-fe19-c43f-6a14a0b95987@csdoc.com> <22524a74c3edd170cdb12d7be59a050b.NginxMailingListRussian@forum.nginx.org> <95a3fd05-e731-90ef-4431-6a3f12fabc1b@csdoc.com> Message-ID: <5690793.vjiSrevIPf@cybernote> Здравствуйте! В письме от 5 ноября 2016 10:19:49 пользователь Gena Makhomed написал: > On 05.11.2016 8:43, sysadm wrote: > > Спасибо за ответ, Гена. Я думал уже над чем-то подобным, но это означает > > что сколько редиректов - столько ифов у нас появится. Т.е. будет > > несколько сотен - будет несколько сотен ифов. А если приедет следующий > > список на несколько тысяч подобных редиректов? Нормально ли это и > > насколько это скажется на производительности? > > Тогда http://nginx.org/ru/docs/http/ngx_http_map_module.html > > http { > > map $request_uri $target_uri { > /example-category?col=name&filter=filter-var1 /target/link; > # ... > } > Если сотни или много тысяч, я бы использовал map $request_uri $target_uri { include manythousandsofinclude.inc; } Тогда файл с инклюдами можно генерировать скриптом и по завершению reloadить nginx. > server { > > if ($target_uri) { > return 301 $target_uri; > } > > > Помимо этого с такой конструкцией нгинксу не нравится синтаксис: > > nginx: [emerg] invalid number of arguments in "return" directive in > > /etc/nginx/redirects/ecommerce.conf:2 > > nginx: configuration file /etc/nginx/nginx.conf test failed > > http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return > > Синтаксис: return код URL; Вы в своем первом сообщении rewrite с return просто перепутали и добавили permanent, чем ввели топикстартера в заблуждение. С уважением, Иван. From gmm на csdoc.com Sun Nov 6 17:00:49 2016 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 6 Nov 2016 19:00:49 +0200 Subject: Installing NGINX and NGINX Plus With Ansible Message-ID: <2f640bad-aa78-6556-4de4-f9d5ec7294d9@csdoc.com> Здравствуйте, All! Как правильно установить nginx на CentOS из официального репозитория с помощью Ansible? В интернете нашел ссылку https://www.nginx.com/blog/installing-nginx-nginx-plus-ansible/ но там сплошные ошибки - в пакете настройки репозитория http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm старый GPG ключ и хотя ключ явно прописан в пакете - он в repo-файле вообще не используется. У кого есть рабочий ansible-конфиг для установки nginx из официального репозитория с проверкой валидности пакета через GPG ключ - поделитесь пожалуйста. -- Best regards, Gena From vladget на gmail.com Sun Nov 6 17:27:19 2016 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Sun, 6 Nov 2016 19:27:19 +0200 Subject: nginx cache issue Message-ID: Добрый вечер, тут какой то ад, не работает кеш, уже более часа потратил: *# *nginx -V nginx version: nginx/1.10.0 (Ubuntu) built with OpenSSL 1.0.2g 1 Mar 2016 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads *# *grep catalog /etc/nginx/conf.d/proxy.conf proxy_cache_path /dev/shm/nginx_cache_*catalog*_microservice levels=1:2 keys_zone=*catalog*_microservice:500m inactive=30d max_size=1G; из vhost: location /v2/categories/parents/ { access_log /var/log/nginx/access_monitoring.log monitoring buffer=16k; proxy_cache catalog_microservice; proxy_cache_key "$request_method$host$request_uri"; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_valid 200 10m; proxy_pass http://app-backend; } *# *curl -XGET -I http://catalog.my.site/v2/categories/parents/1164?country_id=8 HTTP/1.1 200 OK Server: nginx/1.10.0 (Ubuntu) Date: Sun, 06 Nov 2016 17:25:19 GMT Content-Type: application/json; charset=UTF-8 Content-Length: 710 Connection: keep-alive Access-Control-Allow-Origin: * Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization *# *find /dev/shm/nginx_cache_catalog_microservice/ -type f | wc -l 0 -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vladget на gmail.com Sun Nov 6 18:20:12 2016 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Sun, 6 Nov 2016 20:20:12 +0200 Subject: nginx cache issue In-Reply-To: References: Message-ID: Отбой :) On Sun, Nov 6, 2016 at 7:27 PM, Vladimir Getmanshchuk wrote: > Добрый вечер, тут какой то ад, не работает кеш, уже более часа потратил: > > *# *nginx -V > > nginx version: nginx/1.10.0 (Ubuntu) > > built with OpenSSL 1.0.2g 1 Mar 2016 > > TLS SNI support enabled > > configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' > --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro > -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf > --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log > --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid > --http-client-body-temp-path=/var/lib/nginx/body > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi > --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit > --with-ipv6 --with-http_ssl_module --with-http_stub_status_module > --with-http_realip_module --with-http_auth_request_module > --with-http_addition_module --with-http_dav_module --with-http_geoip_module > --with-http_gunzip_module --with-http_gzip_static_module > --with-http_image_filter_module --with-http_v2_module > --with-http_sub_module --with-http_xslt_module --with-stream > --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads > > > *# *grep catalog /etc/nginx/conf.d/proxy.conf > > proxy_cache_path /dev/shm/nginx_cache_*catalog*_microservice levels=1:2 > keys_zone=*catalog*_microservice:500m inactive=30d max_size=1G; > > > из vhost: > > > location /v2/categories/parents/ { > > access_log /var/log/nginx/access_monitoring.log monitoring > buffer=16k; > > proxy_cache catalog_microservice; > > proxy_cache_key "$request_method$host$request_uri"; > > proxy_ignore_headers "Cache-Control" "Expires"; > > proxy_cache_valid 200 10m; > > proxy_pass http://app-backend; > > } > > > > *# *curl -XGET -I http://catalog.my.site/v2/categories/parents/1164? > country_id=8 > > HTTP/1.1 200 OK > > Server: nginx/1.10.0 (Ubuntu) > > Date: Sun, 06 Nov 2016 17:25:19 GMT > > Content-Type: application/json; charset=UTF-8 > > Content-Length: 710 > > Connection: keep-alive > > Access-Control-Allow-Origin: * > > Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS > > Access-Control-Allow-Headers: Content-Type, Authorization > > *# *find /dev/shm/nginx_cache_catalog_microservice/ -type f | wc -l > > 0 > > > > -- > Yours sincerely, > Vladimir Getmanshchuk > -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Nov 9 08:19:15 2016 From: nginx-forum на forum.nginx.org (mortyre) Date: Wed, 09 Nov 2016 03:19:15 -0500 Subject: =?UTF-8?B?0J/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC90LAg0LzQvtCx0LjQu9GM?= =?UTF-8?B?0L3Rg9GOINCy0LXRgNGB0LjRjiDQuCDQvtCx0YDQsNGC0L3Qvg==?= Message-ID: <56c5d0144cea15e4c5781947e6f54bea.NginxMailingListRussian@forum.nginx.org> Необходимо сделать переадресацию на мобильную версию сайта расположенную по адресу site.com/m , но при этом, если заходит на site.com/full то не зависимо от user_agent должен переадресовывать на site.com/ С самой переадресацию на мобильную версию проблем не возникло, а вот с /full есть сложности. Я сделал так: location ^~ full { rewrite ^/full(/.*)$ /$1 break; } Но в этом случае открывается только главная страница, при переходе на остальные попадают в / (корень) и идет обработка user_agent и опять переадресация на мобильную Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270830,270830#msg-270830 From nginx на mva.name Wed Nov 9 10:01:44 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 09 Nov 2016 17:01:44 +0700 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L7QsdC4?= =?UTF-8?B?0LvRjNC90YPRjiDQstC10YDRgdC40Y4g0Lgg0L7QsdGA0LDRgtC90L4=?= In-Reply-To: <56c5d0144cea15e4c5781947e6f54bea.NginxMailingListRussian@forum.nginx.org> References: <56c5d0144cea15e4c5781947e6f54bea.NginxMailingListRussian@forum.nginx.org> Message-ID: <11272915.69GXeyfpy4@note> Cookie From nginx на kinetiksoft.com Wed Nov 9 16:37:35 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Wed, 09 Nov 2016 19:37:35 +0300 Subject: Installing NGINX and NGINX Plus With Ansible In-Reply-To: <2f640bad-aa78-6556-4de4-f9d5ec7294d9@csdoc.com> References: <2f640bad-aa78-6556-4de4-f9d5ec7294d9@csdoc.com> Message-ID: <42259860.2rWLZNN3gN@cybernote> Поищите в ansible-galaxy. Я брал оттуда, но потом дорабатывал под собственные нужды, поэтому не выкладываю конкретику. Но там много разного. В письме от 6 ноября 2016 19:00:49 пользователь Gena Makhomed написал: > Здравствуйте, All! > > Как правильно установить nginx на CentOS > из официального репозитория с помощью Ansible? > > В интернете нашел ссылку > https://www.nginx.com/blog/installing-nginx-nginx-plus-ansible/ > но там сплошные ошибки - в пакете настройки репозитория > http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7. > ngx.noarch.rpm старый GPG ключ и хотя ключ явно прописан в пакете - он в > repo-файле вообще не используется. > > У кого есть рабочий ansible-конфиг для установки nginx из официального > репозитория с проверкой валидности пакета через GPG ключ - поделитесь > пожалуйста. From nginx-forum на forum.nginx.org Thu Nov 10 07:55:28 2016 From: nginx-forum на forum.nginx.org (mortyre) Date: Thu, 10 Nov 2016 02:55:28 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L7QsdC4?= =?UTF-8?B?0LvRjNC90YPRjiDQstC10YDRgdC40Y4g0Lgg0L7QsdGA0LDRgtC90L4=?= In-Reply-To: <56c5d0144cea15e4c5781947e6f54bea.NginxMailingListRussian@forum.nginx.org> References: <56c5d0144cea15e4c5781947e6f54bea.NginxMailingListRussian@forum.nginx.org> Message-ID: а можно пример конфига? что-то у меня не выходит сделать правильно Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270830,270851#msg-270851 From dmitry.goryainov на gmail.com Fri Nov 11 13:52:20 2016 From: dmitry.goryainov на gmail.com (Dmitry) Date: Fri, 11 Nov 2016 16:52:20 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L7QsdC4?= =?UTF-8?B?0LvRjNC90YPRjiDQstC10YDRgdC40Y4g0Lgg0L7QsdGA0LDRgtC90L4=?= In-Reply-To: References: <56c5d0144cea15e4c5781947e6f54bea.NginxMailingListRussian@forum.nginx.org> Message-ID: Пример: location /full/ { rewrite ^/full/(.*)$ /$1 permanent; } Чтобы не было перенаправления на мобильную, в зависимости от UA правило должно быть выше, чем обработка перенаправления на мобильную для UA. 2016-11-10 10:55 GMT+03:00 mortyre : > а можно пример конфига? что-то у меня не выходит сделать правильно > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,270830,270851#msg-270851 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Dmitry Goryainov -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Mon Nov 14 05:21:29 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 14 Nov 2016 10:21:29 +0500 Subject: =?UTF-8?B?c3NsIHN0YXBsaW5nIC0g0YDQsNC30YDQtdGI0LXQvdC40LUg0LjQvNC10L0g0L0=?= =?UTF-8?B?0LAg0YHRgtCw0LTQuNC4INGH0YLQtdC90LjQuCDQutC+0L3RhNC40LPQsA==?= Message-ID: Добрый день! у нас такая ситуация, что в момент запуска nginx может не быть днс-ресолвера. поскольку мы проксируем на ip-адреса, ничего страшного в этом не видим. И хотим, чтобы nginx стартовал. Однако, при включенном ssl stapling происходит вот такое nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder " gp.symcd.com" скажите, в чем целесообразность такого поведения ? ведь обращение к механизму stapling происходит на более поздней стадии, почему считается правильным отключить этот механизм на стадии чтения конфига ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 14 12:54:24 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 14 Nov 2016 15:54:24 +0300 Subject: =?UTF-8?B?UmU6IHNzbCBzdGFwbGluZyAtINGA0LDQt9GA0LXRiNC10L3QuNC1INC40LzQtdC9?= =?UTF-8?B?INC90LAg0YHRgtCw0LTQuNC4INGH0YLQtdC90LjQuCDQutC+0L3RhNC40LM=?= =?UTF-8?B?0LA=?= In-Reply-To: References: Message-ID: <20161114125424.GC8196@mdounin.ru> Hello! On Mon, Nov 14, 2016 at 10:21:29AM +0500, Илья Шипицин wrote: > Добрый день! > > у нас такая ситуация, что в момент запуска nginx может не быть > днс-ресолвера. > > поскольку мы проксируем на ip-адреса, ничего страшного в этом не видим. И > хотим, чтобы nginx стартовал. > > Однако, при включенном ssl stapling происходит вот такое > > nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder " > gp.symcd.com" > > скажите, в чем целесообразность такого поведения ? ведь обращение к > механизму stapling происходит на более поздней стадии, почему считается > правильным отключить этот механизм на стадии чтения конфига ? Адрес, полученный в процессе чтения конфигурации, используется в случае, если resolver в конфиге не задан. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Nov 15 15:24:15 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 15 Nov 2016 18:24:15 +0300 Subject: nginx-1.11.6 Message-ID: <20161115152415.GO8196@mdounin.ru> Изменения в nginx 1.11.6 15.11.2016 *) Изменение: формат переменных $ssl_client_s_dn и $ssl_client_i_dn изменён на соответствующий RFC 2253 (RFC 4514); значения в старом формате доступны через переменные $ssl_client_s_dn_legacy и $ssl_client_i_dn_legacy. *) Изменение: при сохранении временных файлов в каталоге кэша они теперь располагаются не в отдельном подкаталоге для временных файлов, а в том же подкаталоге, что и соответствующие файлы в кэше. *) Добавление: поддержка метода аутентификации EXTERNAL в почтовом прокси-сервере. Спасибо Robert Norris. *) Добавление: поддержка WebP в модуле ngx_http_image_filter_module. *) Добавление: директива proxy_method поддерживает переменные. Спасибо Дмитрию Лазуркину. *) Добавление: директива http2_max_requests в модуле ngx_http_v2_module. *) Добавление: директивы proxy_cache_max_range_offset, fastcgi_cache_max_range_offset, scgi_cache_max_range_offset и uwsgi_cache_max_range_offset. *) Исправление: плавное завершение старых рабочих процессов могло занимать бесконечное время при использовании HTTP/2. *) Исправление: в модуле ngx_http_mp4_module. *) Исправление: при проксировании WebSocket-соединений и включённом кэшировании в логах могли появляться сообщения "ignore long locked inactive cache entry". *) Исправление: если во время SSL handshake с бэкендом происходил таймаут, nginx ничего не писал в лог и возвращал ответ с кодом 502 вместо 504. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Nov 16 06:58:43 2016 From: nginx-forum на forum.nginx.org (Odissey) Date: Wed, 16 Nov 2016 01:58:43 -0500 Subject: =?UTF-8?B?0J3Rg9C20L3QsCDQv9C+0LzQvtGJ0Ywg0L3QvtCy0LjRh9C60YMg0L/QviDRg9GB?= =?UTF-8?B?0YLQsNC90L7QstC60LUg0L3QsCDRgdC10YDQstC10YAgU1NM?= Message-ID: <572dd27057d9ba39bd6dcf144a47a3c0.NginxMailingListRussian@forum.nginx.org> У меня сайт на старом хостинге был на https, а теперь перенес его на свой сервер и ни в какую не получается правильно настроить сайт под ssl. По http сайт доступен и работает корректно, а вот с https - проблема. По документации конфиг сайта откорректировал: http://dl2.joxi.net/drive/2016/11/16/0001/1278/79102/02/a48d602ca5.jpg Но сервер nginx ругается: http://dl1.joxi.net/drive/2016/11/16/0001/1278/79102/02/7032c18c44.jpg Как я понимаю что-то не так с ключами... Если кто в готов помочь - пишите в личку. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270977,270977#msg-270977 From medvedev.yp на gmail.com Wed Nov 16 07:13:32 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Wed, 16 Nov 2016 10:13:32 +0300 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <572dd27057d9ba39bd6dcf144a47a3c0.NginxMailingListRussian@forum.nginx.org> References: <572dd27057d9ba39bd6dcf144a47a3c0.NginxMailingListRussian@forum.nginx.org> Message-ID: Ключ добавьте в сертификат 16 ноября 2016 г., 9:58 пользователь Odissey написал: > У меня сайт на старом хостинге был на https, а теперь перенес его на свой > сервер и ни в какую не получается правильно настроить сайт под ssl. По http > сайт доступен и работает корректно, а вот с https - проблема. > По документации конфиг сайта откорректировал: > http://dl2.joxi.net/drive/2016/11/16/0001/1278/79102/02/a48d602ca5.jpg > Но сервер nginx ругается: > http://dl1.joxi.net/drive/2016/11/16/0001/1278/79102/02/7032c18c44.jpg > Как я понимаю что-то не так с ключами... > Если кто в готов помочь - пишите в личку. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,270977,270977#msg-270977 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Nov 16 09:03:11 2016 From: nginx-forum на forum.nginx.org (Odissey) Date: Wed, 16 Nov 2016 04:03:11 -0500 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: References: Message-ID: В том-то и дело, что ключ на сервер я положил в ту самую директорию, которая указана в конфиге сайта (на скрине в первом сообщении). Но проблема существует. Может надо еще какие-то "танцы с бубном" произвести на сервере? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270977,270980#msg-270980 From nginx-forum на forum.nginx.org Wed Nov 16 09:03:46 2016 From: nginx-forum на forum.nginx.org (Odissey) Date: Wed, 16 Nov 2016 04:03:46 -0500 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: References: Message-ID: Odissey Wrote: ------------------------------------------------------- > В том-то и дело, что ключ на сервер я положил в ту самую директорию, > которая указана в конфиге сайта (на скрине в первом сообщении). Но > проблема существует. Может надо еще какие-то "танцы с бубном" > произвести на сервере? вот так выглядит файл ключа: http://dl2.joxi.net/drive/2016/11/16/0001/1278/79102/02/51388e0d4c.jpg Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270977,270981#msg-270981 From mdounin на mdounin.ru Wed Nov 16 12:19:58 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 16 Nov 2016 15:19:58 +0300 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: References: Message-ID: <20161116121958.GT8196@mdounin.ru> Hello! On Wed, Nov 16, 2016 at 04:03:46AM -0500, Odissey wrote: > Odissey Wrote: > ------------------------------------------------------- > > В том-то и дело, что ключ на сервер я положил в ту самую директорию, > > которая указана в конфиге сайта (на скрине в первом сообщении). Но > > проблема существует. Может надо еще какие-то "танцы с бубном" > > произвести на сервере? > вот так выглядит файл ключа: > http://dl2.joxi.net/drive/2016/11/16/0001/1278/79102/02/51388e0d4c.jpg Посмотрите на ключ чем-нибудь приличным, и уберите оттуда UTF-8 BOM (Byte Order Mark) - он там, судя по всему, есть. Файл должен быть в US-ASCII, наличие UTF-8 BOM'а будет приводить именно к ругани "no start line" от OpenSSL. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Nov 16 13:33:38 2016 From: nginx-forum на forum.nginx.org (scriptracer) Date: Wed, 16 Nov 2016 08:33:38 -0500 Subject: =?UTF-8?B?0J7QsdC90L7QstC70LXQvdC40LUg0LTQsNC90L3Ri9GFINCyINC60Y3RiNC1INGB?= =?UTF-8?B?0YLQsNGC0LjQutC4?= Message-ID: <6bdbe015921d869f6c3fdd43dbd268bf.NginxMailingListRussian@forum.nginx.org> Как можно обновлять данные в кэше при обновлении файлов? Например, у нас есть изображения, они уже в кэше. Изображение обновили, имя файла осталось такое же. Как обновить это изменение в кэше? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270991,270991#msg-270991 From andriy.tovstik на gmail.com Wed Nov 16 14:39:35 2016 From: andriy.tovstik на gmail.com (Andriy Tovstik) Date: Wed, 16 Nov 2016 14:39:35 +0000 Subject: =?UTF-8?B?Y29yZSBkdW1wINC/0YDQuCDQvtCx0L3QvtCy0LvQtdC90LjQuCDQvdCwINC70LU=?= =?UTF-8?B?0YLRgw==?= Message-ID: Добрый день! Столкнулся со следующей ситуацией. Платформа: # uname -a SunOS sunos 5.11 11.3 i86pc i386 i86pc Пытаюсь обновить бинарник на лету, согласно http://nginx.org/ru/docs/control.html#upgrade исходная версия nginx 1.11.3 целевой бинарник nginx 1.11.5 конфигурационный файл - дефолтный, без изменений. опции сборки: nginx version: nginx/1.11.3 built by gcc 4.8.2 (GCC) configure arguments: --with-cc=gcc nginx version: nginx/1.11.5 built by gcc 4.8.2 (GCC) configure arguments: --with-cc=gcc Как указано в мануале, заменяю бинарный файл, делаю kill -USR2 `cat /usr/local/nginx/logs/nginx.pid` после чего nginx падает в core dump: Backtrace: GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-pc-solaris2.11". For bug reporting instructions, please see: ... Reading symbols from /export/home/at/Build/nginx-1.11.3/objs/nginx...done. [New LWP 1] [New LWP 1] [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] Core was generated by `/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf'. Program terminated with signal 11, Segmentation fault. #0 0x0808f4c8 in ngx_signal_handler (signo=17) at src/os/unix/ngx_process.c:329 329 action = ""; (gdb) bt full #0 0x0808f4c8 in ngx_signal_handler (signo=17) at src/os/unix/ngx_process.c:329 action = 0x8068858 "he_key\" for \"scgi_cache\"" ignore = 0 err = 0 sig = #1 0x075499fe in call_user_handler () from /lib/libc.so.1 No symbol table info available. #2 No symbol table info available. #3 0x0755b565 in __sigsuspend () from /lib/libc.so.1 No symbol table info available. #4 0x07547e0b in sigsuspend () from /lib/libc.so.1 No symbol table info available. #5 0x08091d21 in ngx_master_process_cycle (cycle=cycle на entry=0x8114628) at src/os/unix/ngx_process_cycle.c:163 title = p = size = i = n = sigio = 0 set = {__sigbits = {0, 0, 0, 0}} itv = {it_interval = {tv_sec = 7, tv_usec = 9}, it_value = {tv_sec = 2, tv_usec = -16781864}} live = delay = 0 ls = ccf = 0x81153b4 #6 0x08070f4f in main (argc=3, argv=0xfeffecac) at src/core/nginx.c:367 b = log = i = cycle = 0x8114628 init_cycle = {conf_ctx = 0x0, pool = 0x8113e00, log = 0x80f50e0 , new_log = {log_level = 0, file = 0x0, connection = 0, disk_full_time = 0, handler = 0x0, data = 0x0, writer = 0x0, wdata = 0x0, action = 0x0, next = 0x0}, log_use_stderr = 0, files = 0x0, free_connections = 0x0, free_connection_n = 0, modules = 0x0, modules_n = 0, modules_used = 0, reusable_connections_queue = {prev = 0x0, next = 0x0}, listening = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, paths = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, config_dump = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, open_files = {last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, shared_memory = {last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, connection_n = 0, files_n = 0, connections = 0x0, read_events = 0x0, write_events = 0x0, old_cycle = 0x0, conf_file = {len = 32, data = 0xfeffedb7 "l/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf", ' ' ...}, conf_param = {len = 0, data = 0x0}, conf_prefix = {len = 22, data = 0xfeffedb7 "l/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf", ' ' ...}, prefix = {len = 17, data = 0x8068c39 "tream"}, lock_file = {len = 0, data = 0x0}, hostname = {len = 0, data = 0x0}} cd = ccf = 0x81153b4 что я делаю не правильно? -- WBR, Andriy Tovstik ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Nov 16 15:37:24 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 16 Nov 2016 18:37:24 +0300 Subject: =?UTF-8?B?UmU6IGNvcmUgZHVtcCDQv9GA0Lgg0L7QsdC90L7QstC70LXQvdC40Lgg0L3QsCA=?= =?UTF-8?B?0LvQtdGC0YM=?= In-Reply-To: References: Message-ID: <20161116153724.GW8196@mdounin.ru> Hello! On Wed, Nov 16, 2016 at 02:39:35PM +0000, Andriy Tovstik wrote: > Добрый день! > > Столкнулся со следующей ситуацией. > Платформа: > # uname -a > SunOS sunos 5.11 11.3 i86pc i386 i86pc > > Пытаюсь обновить бинарник на лету, согласно > http://nginx.org/ru/docs/control.html#upgrade > исходная версия nginx 1.11.3 > целевой бинарник nginx 1.11.5 > > конфигурационный файл - дефолтный, без изменений. > > опции сборки: > nginx version: nginx/1.11.3 > built by gcc 4.8.2 (GCC) > configure arguments: --with-cc=gcc > > nginx version: nginx/1.11.5 > built by gcc 4.8.2 (GCC) > configure arguments: --with-cc=gcc > > Как указано в мануале, заменяю бинарный файл, делаю > kill -USR2 `cat /usr/local/nginx/logs/nginx.pid` > после чего nginx падает в core dump: [...] > что я делаю не правильно? Не раскрыта процедура "заменяю бинарный файл". Если новый файл просто скопировать поверх старого с помощью cp - будет как раз core dump скорее всего. Нужно убрать старый файл в сторону (или удалить), после чего положить новый с тем же именем: mv /path/to/nginx /path/to/nginx.old cp objs/nginx /path/to/nginx Ну или положить рядом новый файл, а потом атомарно переименовать: cp objs/nginx /path/to/nginx.new mv /path/to/nginx.new /path/to/nginx Важно, чтобы в результате не получилось так, что работающий бинарник переписали по живому (и именно это сделает стандартный cp), а вместо этого был создан новый файл с тем же именем. При установке из исходников - правильные операции умеет проделывать "make install", им и имеет смысл пользоваться. -- Maxim Dounin http://nginx.org/ From andriy.tovstik на gmail.com Wed Nov 16 16:57:05 2016 From: andriy.tovstik на gmail.com (Andriy Tovstik) Date: Wed, 16 Nov 2016 16:57:05 +0000 Subject: =?UTF-8?B?UmU6IGNvcmUgZHVtcCDQv9GA0Lgg0L7QsdC90L7QstC70LXQvdC40Lgg0L3QsCA=?= =?UTF-8?B?0LvQtdGC0YM=?= In-Reply-To: <20161116153724.GW8196@mdounin.ru> References: <20161116153724.GW8196@mdounin.ru> Message-ID: Спасибо, Максим. Уже сам понял, что глупость делаю. replace выполнялся через cp, пока не сообразил, к чему, собственно, это приводит :) ср, 16 нояб. 2016, 17:37 Maxim Dounin : > Hello! > > On Wed, Nov 16, 2016 at 02:39:35PM +0000, Andriy Tovstik wrote: > > > Добрый день! > > > > Столкнулся со следующей ситуацией. > > Платформа: > > # uname -a > > SunOS sunos 5.11 11.3 i86pc i386 i86pc > > > > Пытаюсь обновить бинарник на лету, согласно > > http://nginx.org/ru/docs/control.html#upgrade > > исходная версия nginx 1.11.3 > > целевой бинарник nginx 1.11.5 > > > > конфигурационный файл - дефолтный, без изменений. > > > > опции сборки: > > nginx version: nginx/1.11.3 > > built by gcc 4.8.2 (GCC) > > configure arguments: --with-cc=gcc > > > > nginx version: nginx/1.11.5 > > built by gcc 4.8.2 (GCC) > > configure arguments: --with-cc=gcc > > > > Как указано в мануале, заменяю бинарный файл, делаю > > kill -USR2 `cat /usr/local/nginx/logs/nginx.pid` > > после чего nginx падает в core dump: > > [...] > > > что я делаю не правильно? > > Не раскрыта процедура "заменяю бинарный файл". > > Если новый файл просто скопировать поверх старого с помощью cp - > будет как раз core dump скорее всего. > > Нужно убрать старый файл в сторону (или удалить), после чего > положить новый с тем же именем: > > mv /path/to/nginx /path/to/nginx.old > cp objs/nginx /path/to/nginx > > Ну или положить рядом новый файл, а потом атомарно переименовать: > > cp objs/nginx /path/to/nginx.new > mv /path/to/nginx.new /path/to/nginx > > Важно, чтобы в результате не получилось так, что работающий > бинарник переписали по живому (и именно это сделает стандартный > cp), а вместо этого был создан новый файл с тем же именем. > > При установке из исходников - правильные операции умеет > проделывать "make install", им и имеет смысл пользоваться. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR, Andriy Tovstik ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Wed Nov 16 17:05:42 2016 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 16 Nov 2016 19:05:42 +0200 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQu9C10L3QuNC1INC00LDQvdC90YvRhSDQsiDQutGN0Yg=?= =?UTF-8?B?0LUg0YHRgtCw0YLQuNC60Lg=?= In-Reply-To: <6bdbe015921d869f6c3fdd43dbd268bf.NginxMailingListRussian@forum.nginx.org> References: <6bdbe015921d869f6c3fdd43dbd268bf.NginxMailingListRussian@forum.nginx.org> Message-ID: <35d24164-182b-2708-f0b2-8624adb3a9e8@csdoc.com> On 16.11.2016 15:33, scriptracer wrote: > Как можно обновлять данные в кэше при обновлении файлов? > Например, у нас есть изображения, они уже в кэше. Изображение обновили, имя > файла осталось такое же. > Как обновить это изменение в кэше? с помощью запроса, для которого будет выполняться условие proxy_cache_bypass и не выполняется условие proxy_no_cache - ответ не будет взят из кеша, запрос уйдет на бекенд, и ответа бекенда на этот запрос обновит контент в кеше. второй метод - с помощью proxy_cache_purge, но эта функциональность доступна только в платной версии. документация: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html или: http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html во втором случае директивы fastcgi_cache_bypass, fastcgi_no_cache, fastcgi_cache_purge. -- Best regards, Gena From nginx-forum на forum.nginx.org Thu Nov 17 03:53:27 2016 From: nginx-forum на forum.nginx.org (Odissey) Date: Wed, 16 Nov 2016 22:53:27 -0500 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <20161116121958.GT8196@mdounin.ru> References: <20161116121958.GT8196@mdounin.ru> Message-ID: <609a91448021fece10ad2521f83e41f3.NginxMailingListRussian@forum.nginx.org> А чем "приличным" посмотреть на файл? Я смотрю Notepad++ Кодировку поменял: http://dl2.joxi.net/drive/2016/11/17/0001/1278/79102/02/aa78442aa9.jpg Но ошибка в консоли таже самая. Что еще можно попробовать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270977,271001#msg-271001 From nginx-forum на forum.nginx.org Thu Nov 17 04:09:32 2016 From: nginx-forum на forum.nginx.org (Odissey) Date: Wed, 16 Nov 2016 23:09:32 -0500 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <609a91448021fece10ad2521f83e41f3.NginxMailingListRussian@forum.nginx.org> References: <20161116121958.GT8196@mdounin.ru> <609a91448021fece10ad2521f83e41f3.NginxMailingListRussian@forum.nginx.org> Message-ID: <65aa29c9adcfe20ae74fae524bab7964.NginxMailingListRussian@forum.nginx.org> Odissey Wrote: ------------------------------------------------------- > А чем "приличным" посмотреть на файл? Я смотрю Notepad++ > Кодировку поменял: > http://dl2.joxi.net/drive/2016/11/17/0001/1278/79102/02/aa78442aa9.jpg > > Но ошибка в консоли таже самая. Что еще можно попробовать? Извиняюсь, ошибка в консоли уже не таже самая: http://dl2.joxi.net/drive/2016/11/17/0001/1278/79102/02/2f8d97be80.jpg Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270977,271002#msg-271002 From swood на fotofor.biz Thu Nov 17 12:23:58 2016 From: swood на fotofor.biz (Anton Kiryushkin) Date: Thu, 17 Nov 2016 15:23:58 +0300 Subject: SIGSEGV Message-ID: Здравствуйте. Не подскажете, почему может вот так падать nginx: # gdb nginx Starting program: /usr/sbin/nginx -t Program received signal SIGSEGV, Segmentation fault. 0xffffffffff600000 in ?? () (gdb) bt #0 0xffffffffff600000 in ?? () #1 0x0000000000709e5d in gettimeofday () #2 0x000000000040e315 in ngx_time_update () at src/core/ngx_times.c:91 #3 0x000000000040e7ba in ngx_time_init () at src/core/ngx_times.c:73 #4 0x00000000004016e3 in main (argc=2, argv=0x7fffffffec78) at src/core/nginx.c:216 -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From swood на fotofor.biz Thu Nov 17 12:24:52 2016 From: swood на fotofor.biz (Anton Kiryushkin) Date: Thu, 17 Nov 2016 15:24:52 +0300 Subject: SIGSEGV In-Reply-To: References: Message-ID: Простите, забыл уточнить, что версия 1.11.1, а версия ядра linux 4.8.0-1. 2016-11-17 15:23 GMT+03:00 Anton Kiryushkin : > Здравствуйте. > > Не подскажете, почему может вот так падать nginx: > > # gdb nginx > > Starting program: /usr/sbin/nginx -t > > > Program received signal SIGSEGV, Segmentation fault. > > 0xffffffffff600000 in ?? () > > (gdb) bt > > #0 0xffffffffff600000 in ?? () > > #1 0x0000000000709e5d in gettimeofday () > > #2 0x000000000040e315 in ngx_time_update () at src/core/ngx_times.c:91 > > #3 0x000000000040e7ba in ngx_time_init () at src/core/ngx_times.c:73 > > #4 0x00000000004016e3 in main (argc=2, argv=0x7fffffffec78) at > src/core/nginx.c:216 > > -- > Best regards, > Anton Kiryushkin > > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From borepstein на gmail.com Thu Nov 17 12:36:41 2016 From: borepstein на gmail.com (Boris Epstein) Date: Thu, 17 Nov 2016 07:36:41 -0500 Subject: SIGSEGV In-Reply-To: References: Message-ID: Это занятно. А не в дебаггере, напрямую, он тоже падает? 2016-11-17 7:24 GMT-05:00 Anton Kiryushkin : > Простите, забыл уточнить, что версия 1.11.1, а версия ядра linux 4.8.0-1. > > 2016-11-17 15:23 GMT+03:00 Anton Kiryushkin : > >> Здравствуйте. >> >> Не подскажете, почему может вот так падать nginx: >> >> # gdb nginx >> >> Starting program: /usr/sbin/nginx -t >> >> >> Program received signal SIGSEGV, Segmentation fault. >> >> 0xffffffffff600000 in ?? () >> >> (gdb) bt >> >> #0 0xffffffffff600000 in ?? () >> >> #1 0x0000000000709e5d in gettimeofday () >> >> #2 0x000000000040e315 in ngx_time_update () at src/core/ngx_times.c:91 >> >> #3 0x000000000040e7ba in ngx_time_init () at src/core/ngx_times.c:73 >> >> #4 0x00000000004016e3 in main (argc=2, argv=0x7fffffffec78) at >> src/core/nginx.c:216 >> >> -- >> Best regards, >> Anton Kiryushkin >> >> > > > -- > Best regards, > Anton Kiryushkin > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Thu Nov 17 12:38:50 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 17 Nov 2016 15:38:50 +0300 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <65aa29c9adcfe20ae74fae524bab7964.NginxMailingListRussian@forum.nginx.org> References: <20161116121958.GT8196@mdounin.ru> <609a91448021fece10ad2521f83e41f3.NginxMailingListRussian@forum.nginx.org> <65aa29c9adcfe20ae74fae524bab7964.NginxMailingListRussian@forum.nginx.org> Message-ID: <20161117123850.GX8196@mdounin.ru> Hello! On Wed, Nov 16, 2016 at 11:09:32PM -0500, Odissey wrote: > Odissey Wrote: > ------------------------------------------------------- > > А чем "приличным" посмотреть на файл? Я смотрю Notepad++ > > Кодировку поменял: > > http://dl2.joxi.net/drive/2016/11/17/0001/1278/79102/02/aa78442aa9.jpg > > > > Но ошибка в консоли таже самая. Что еще можно попробовать? > > Извиняюсь, ошибка в консоли уже не таже самая: > http://dl2.joxi.net/drive/2016/11/17/0001/1278/79102/02/2f8d97be80.jpg У вас ключ - от другого сертификата, "key values mismatch" как бы намекает. (Совет - ошибки, которые выводит nginx - они текстовые, их можно просто копировать в сообщение как текст. Картинки - только усложняют процесс и уменьшают вероятность того, что на ваше сообщение кто-либо ответит.)) -- Maxim Dounin http://nginx.org/ From swood на fotofor.biz Thu Nov 17 12:43:56 2016 From: swood на fotofor.biz (Anton Kiryushkin) Date: Thu, 17 Nov 2016 15:43:56 +0300 Subject: SIGSEGV In-Reply-To: References: Message-ID: Да, в segmentation fault. 17 ноября 2016 г., 15:36 пользователь Boris Epstein написал: > Это занятно. А не в дебаггере, напрямую, он тоже падает? > > 2016-11-17 7:24 GMT-05:00 Anton Kiryushkin : > >> Простите, забыл уточнить, что версия 1.11.1, а версия ядра linux 4.8.0-1. >> >> 2016-11-17 15:23 GMT+03:00 Anton Kiryushkin : >> >>> Здравствуйте. >>> >>> Не подскажете, почему может вот так падать nginx: >>> >>> # gdb nginx >>> >>> Starting program: /usr/sbin/nginx -t >>> >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> >>> 0xffffffffff600000 in ?? () >>> >>> (gdb) bt >>> >>> #0 0xffffffffff600000 in ?? () >>> >>> #1 0x0000000000709e5d in gettimeofday () >>> >>> #2 0x000000000040e315 in ngx_time_update () at src/core/ngx_times.c:91 >>> >>> #3 0x000000000040e7ba in ngx_time_init () at src/core/ngx_times.c:73 >>> >>> #4 0x00000000004016e3 in main (argc=2, argv=0x7fffffffec78) at >>> src/core/nginx.c:216 >>> >>> -- >>> Best regards, >>> Anton Kiryushkin >>> >>> >> >> >> -- >> Best regards, >> Anton Kiryushkin >> >> >> _______________________________________________ >> 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 > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Thu Nov 17 12:55:06 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 17 Nov 2016 15:55:06 +0300 Subject: SIGSEGV In-Reply-To: References: Message-ID: <20161117125506.GY8196@mdounin.ru> Hello! On Thu, Nov 17, 2016 at 03:23:58PM +0300, Anton Kiryushkin wrote: > Здравствуйте. > > Не подскажете, почему может вот так падать nginx: > > # gdb nginx > > Starting program: /usr/sbin/nginx -t > > > Program received signal SIGSEGV, Segmentation fault. > > 0xffffffffff600000 in ?? () > > (gdb) bt > > #0 0xffffffffff600000 in ?? () > > #1 0x0000000000709e5d in gettimeofday () > > #2 0x000000000040e315 in ngx_time_update () at src/core/ngx_times.c:91 > > #3 0x000000000040e7ba in ngx_time_init () at src/core/ngx_times.c:73 > > #4 0x00000000004016e3 in main (argc=2, argv=0x7fffffffec78) at > src/core/nginx.c:216 У вас что-то в ядре сломано и/или libc не соответствует ядру, 0xffffffffff600000 - это адрес vsyscall page в ядре. (http://stackoverflow.com/questions/7266813/anyone-can-understand-how-gettimeofday-works) -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Thu Nov 17 15:49:58 2016 From: nginx-forum на forum.nginx.org (permyakovsv) Date: Thu, 17 Nov 2016 10:49:58 -0500 Subject: fastcgi_cache_lock doesnt work Message-ID: <06275492e4242fd7c113895af0f189cd.NginxMailingListRussian@forum.nginx.org> I have further configuration: fastcgi_cache fastcgi_cache_products; fastcgi_cache_valid 200 302 304 404 25m; fastcgi_cache_valid 301 5m; fastcgi_cache_valid 500 502 20s; fastcgi_cache_lock on; fastcgi_cache_lock_timeout 25s; fastcgi_cache_use_stale updating error timeout invalid_header http_500 http_503; And I see netx picture: date http_code http_cache_status backend_responce ... 17/Nov/2016:17:19:54 +0200 200 cs=HIT 0 17/Nov/2016:17:19:14 +0200 200 cs=EXPIRED 8.041 17/Nov/2016:17:18:07 +0200 200 cs=EXPIRED 3.218 17/Nov/2016:17:17:24 +0200 200 cs=EXPIRED 3.291 17/Nov/2016:17:17:21 +0200 200 cs=UPDATING 0 17/Nov/2016:17:16:14 +0200 200 cs=EXPIRED 3.538 17/Nov/2016:17:15:53 +0200 200 cs=EXPIRED 2.977 17/Nov/2016:17:14:32 +0200 200 cs=EXPIRED 4.119 17/Nov/2016:17:13:49 +0200 200 cs=EXPIRED 4.784 17/Nov/2016:17:13:04 +0200 200 cs=HIT 0 ... 17/Nov/2016:16:48:44 +0200 200 cs=HIT 0 17/Nov/2016:16:48:37 +0200 200 cs=EXPIRED 4.279 17/Nov/2016:16:47:57 +0200 200 cs=EXPIRED 3.936 17/Nov/2016:16:47:46 +0200 200 cs=EXPIRED 3.447 17/Nov/2016:16:46:53 +0200 200 cs=EXPIRED 3.287 ... But I expect only one request to backend, and why first request didn't update cache? Maybe Anybody faced the same problem? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271014,271014#msg-271014 From nginx-forum на forum.nginx.org Thu Nov 17 16:15:08 2016 From: nginx-forum на forum.nginx.org (Odissey) Date: Thu, 17 Nov 2016 11:15:08 -0500 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <20161117123850.GX8196@mdounin.ru> References: <20161117123850.GX8196@mdounin.ru> Message-ID: <41c0d08af023a98d1d3940e4a8aa9d85.NginxMailingListRussian@forum.nginx.org> Спасибо! Ключ был правильный, но видимо что-то все же было с кодировкой или со скрытыми символами. Решил проблему таким образом: нашел ключ и сертификат на старом хостинге, где лежал этот сайт и просто их скопировал на свой сервер. Визуально содержание ключа идентично, но со старого хостинго сразу все заработало. Подскажите каким редактором лучше смотреть такие файлы? Чтоб видны были бы скрытые символы. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,270977,271015#msg-271015 From nginx на mva.name Thu Nov 17 16:22:41 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 17 Nov 2016 23:22:41 +0700 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <41c0d08af023a98d1d3940e4a8aa9d85.NginxMailingListRussian@forum.nginx.org> References: <20161117123850.GX8196@mdounin.ru> <41c0d08af023a98d1d3940e4a8aa9d85.NginxMailingListRussian@forum.nginx.org> Message-ID: <6372254.zrhxgfoB2G@note> head -c3 filename | xxd From universite на ukr.net Thu Nov 17 16:42:59 2016 From: universite на ukr.net (Vladislav Prodan) Date: Thu, 17 Nov 2016 18:42:59 +0200 Subject: =?UTF-8?B?UmVbMl06INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/?= =?UTF-8?B?0L4g0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <6372254.zrhxgfoB2G@note> References: <20161117123850.GX8196@mdounin.ru> <41c0d08af023a98d1d3940e4a8aa9d85.NginxMailingListRussian@forum.nginx.org> <6372254.zrhxgfoB2G@note> Message-ID: <1479400968.954525688.a8ga3g8h@frv35.fwdcdn.com> --- Original message --- From: "Vadim A. Misbakh-Soloviov" Date: 17 November 2016, 18:22:58 > head -c3 filename | xxd > Или использовать кроссплатформенный hexdump head -c3 filename | hexdump -C -- Vladislav V. Prodan System & Network Administrator support.od.ua From annulen на yandex.ru Thu Nov 17 16:48:32 2016 From: annulen на yandex.ru (Konstantin Tokarev) Date: Thu, 17 Nov 2016 19:48:32 +0300 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <1479400968.954525688.a8ga3g8h@frv35.fwdcdn.com> References: <20161117123850.GX8196@mdounin.ru> <41c0d08af023a98d1d3940e4a8aa9d85.NginxMailingListRussian@forum.nginx.org> <6372254.zrhxgfoB2G@note> <1479400968.954525688.a8ga3g8h@frv35.fwdcdn.com> Message-ID: <4993681479401312@web30o.yandex.ru> Или любой hex-реадктор, или текстовый редактор с поддержкой hex 17.11.2016, 19:43, "Vladislav Prodan" : >  --- Original message --- >  From: "Vadim A. Misbakh-Soloviov" >  Date: 17 November 2016, 18:22:58 > >>  head -c3 filename | xxd > > Или использовать кроссплатформенный hexdump > > head -c3 filename | hexdump -C > > -- >  Vladislav V. Prodan >  System & Network Administrator >  support.od.ua > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum на forum.nginx.org Thu Nov 17 20:47:08 2016 From: nginx-forum на forum.nginx.org (atway) Date: Thu, 17 Nov 2016 15:47:08 -0500 Subject: nginx performance problem on linux Message-ID: <18d8955cbb149e6352184c128422bc38.NginxMailingListRussian@forum.nginx.org> Добрый день. Столкнулись с проблемой такого рода: На проксирующем в апач нжинксе со временем скорость обработки запросов падает. Посмотрели стрейсом и увидели, что увеличивается выполнение сисколв connect. Когда нжинкс только только запущен сисколл обрабатывается менее чем за 100 usecs на следующий день, уже за 800 usecs, за следующие дни время обработки сискола увеличивается до 10000 usecs, и замедление обработки уже заметно для пользователей. Ещё из подозрительного - в выводе perf top на первом месте с 5% висит dst_ops_extend_get_rcu [root на bitrix /]# nginx -V nginx version: nginx/1.10.2 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled Linux bitrix.shmosting.ru 2.6.32-042stab120.2 #1 SMP Wed Oct 5 18:45:37 MSK 2016 x86_64 x86_64 x86_64 GNU/Linux Я понимаю, что возможно в ядре где или нехватки ресурсов засада, но самостоятельно её найти не получается. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271025,271025#msg-271025 From nginx-forum на forum.nginx.org Thu Nov 17 20:49:20 2016 From: nginx-forum на forum.nginx.org (atway) Date: Thu, 17 Nov 2016 15:49:20 -0500 Subject: nginx performance problem on linux In-Reply-To: <18d8955cbb149e6352184c128422bc38.NginxMailingListRussian@forum.nginx.org> References: <18d8955cbb149e6352184c128422bc38.NginxMailingListRussian@forum.nginx.org> Message-ID: нжинкс запускается в контейнере openvz, и перезапуск контейнера не спасает, только перезагрузка машины полностью лечит Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271025,271026#msg-271026 From basil на vpm.net.ua Thu Nov 17 20:53:43 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Thu, 17 Nov 2016 22:53:43 +0200 Subject: nginx performance problem on linux In-Reply-To: <18d8955cbb149e6352184c128422bc38.NginxMailingListRussian@forum.nginx.org> References: <18d8955cbb149e6352184c128422bc38.NginxMailingListRussian@forum.nginx.org> Message-ID: попробуйте прибивать процессы апача, нжинкс тут врядли виноват у меня так MinSpareServers 512 ServerLimit 1024 MaxClients 1024 MaxRequestsPerChild 32 17 ноября 2016 г., 22:47 пользователь atway написал: > Добрый день. > Столкнулись с проблемой такого рода: > На проксирующем в апач нжинксе со временем скорость обработки запросов > падает. > Посмотрели стрейсом и увидели, что увеличивается выполнение сисколв > connect. > Когда нжинкс только только запущен сисколл обрабатывается менее чем за 100 > usecs > на следующий день, уже за 800 usecs, за следующие дни время обработки > сискола > увеличивается до 10000 usecs, и замедление обработки уже заметно для > пользователей. > Ещё из подозрительного - в выводе perf top > на первом месте с 5% висит dst_ops_extend_get_rcu > > [root на bitrix /]# nginx -V > nginx version: nginx/1.10.2 > built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) > built with OpenSSL 1.0.1e-fips 11 Feb 2013 > TLS SNI support enabled > > Linux bitrix.shmosting.ru 2.6.32-042stab120.2 #1 SMP Wed Oct 5 18:45:37 > MSK > 2016 x86_64 x86_64 x86_64 GNU/Linux > > Я понимаю, что возможно в ядре где или нехватки ресурсов засада, но > самостоятельно её найти не получается. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,271025,271025#msg-271025 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Thu Nov 17 21:31:17 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 18 Nov 2016 00:31:17 +0300 Subject: nginx performance problem on linux In-Reply-To: <18d8955cbb149e6352184c128422bc38.NginxMailingListRussian@forum.nginx.org> References: <18d8955cbb149e6352184c128422bc38.NginxMailingListRussian@forum.nginx.org> Message-ID: <20161117213117.enenfeh62clsfd23@sie.protva.ru> On Thu, Nov 17, 2016 at 03:47:08PM -0500, atway wrote: > На проксирующем в апач нжинксе со временем скорость обработки запросов > падает. > Посмотрели стрейсом и увидели, что увеличивается выполнение сисколв > connect. > Когда нжинкс только только запущен сисколл обрабатывается менее чем за 100 > usecs > на следующий день, уже за 800 usecs, за следующие дни время обработки > сискола > увеличивается до 10000 usecs, и замедление обработки уже заметно для > пользователей. Посмотрите, не накапливаются ли в ядре дохлые сокеты (например, в состоянии CLOSE_WAIT). Посмотреть можно через "lsof -n -i tcp" или "ss -nt". -- Eugene Berdnikov From nginx-forum на forum.nginx.org Thu Nov 17 21:55:13 2016 From: nginx-forum на forum.nginx.org (atway) Date: Thu, 17 Nov 2016 16:55:13 -0500 Subject: nginx performance problem on linux In-Reply-To: <20161117213117.enenfeh62clsfd23@sie.protva.ru> References: <20161117213117.enenfeh62clsfd23@sie.protva.ru> Message-ID: <1cb8f2e7a6b1f24f0abbfbedd060df6b.NginxMailingListRussian@forum.nginx.org> Спасибо, буду снимать статистику по мере замедления. Хотя в прошлый раз при обострении проблемы вывод netstat -np выдавал менее 5к строк в общем пробовал так же делать ip ro flush cache - тоже не помогло перезапуск контейнера не помогал перезапуск iptables не помогал пока что откатил ядро, но судя по тенденции это не поможет) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271025,271029#msg-271029 From nginx-forum на forum.nginx.org Thu Nov 17 22:01:18 2016 From: nginx-forum на forum.nginx.org (atway) Date: Thu, 17 Nov 2016 17:01:18 -0500 Subject: nginx performance problem on linux In-Reply-To: References: Message-ID: у нас не такой нагруженный проект, и железка не выдержит 1024 maxclients ) собсно это и обидно, нагрузка то небольшая, и страшно подумать что было бы если она таковой была Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271025,271030#msg-271030 From basil на vpm.net.ua Fri Nov 18 05:07:57 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Fri, 18 Nov 2016 07:07:57 +0200 Subject: nginx performance problem on linux In-Reply-To: References: Message-ID: там вот это главное MaxRequestsPerChild 32 даже 64 уже критично у меня, понятно что проблема с кодом, но кто ж это будет чинить, если работает таким образом 18 ноября 2016 г., 0:01 пользователь atway написал: > у нас не такой нагруженный проект, и железка не выдержит 1024 maxclients ) > собсно это и обидно, нагрузка то небольшая, и страшно подумать что было бы > если она таковой была > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,271025,271030#msg-271030 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Nov 18 07:23:32 2016 From: nginx-forum на forum.nginx.org (atway) Date: Fri, 18 Nov 2016 02:23:32 -0500 Subject: nginx performance problem on linux In-Reply-To: References: Message-ID: <7b5c2b29b4ef4de7aff197adadcafd39.NginxMailingListRussian@forum.nginx.org> А, понял, спасибо, попробуем. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271025,271034#msg-271034 From alex.hha на gmail.com Fri Nov 18 11:18:58 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Fri, 18 Nov 2016 13:18:58 +0200 Subject: =?UTF-8?B?UmU6INCd0YPQttC90LAg0L/QvtC80L7RidGMINC90L7QstC40YfQutGDINC/0L4g?= =?UTF-8?B?0YPRgdGC0LDQvdC+0LLQutC1INC90LAg0YHQtdGA0LLQtdGAIFNTTA==?= In-Reply-To: <4993681479401312@web30o.yandex.ru> References: <20161117123850.GX8196@mdounin.ru> <41c0d08af023a98d1d3940e4a8aa9d85.NginxMailingListRussian@forum.nginx.org> <6372254.zrhxgfoB2G@note> <1479400968.954525688.a8ga3g8h@frv35.fwdcdn.com> <4993681479401312@web30o.yandex.ru> Message-ID: Или можно проверить, что ключ и сертификат это единое целое $ openssl rsa -noout -modulus -in example.net.key | openssl md5 (stdin)= 496d0967f7fab3d64e3ef9307f27046f $ openssl x509 -noout -modulus -in example.net.crt | openssl md5 (stdin)= 496d0967f7fab3d64e3ef9307f27046f Соответственно хеши должны совпадать 2016-11-17 18:48 GMT+02:00 Konstantin Tokarev : > Или любой hex-реадктор, или текстовый редактор с поддержкой hex > > 17.11.2016, 19:43, "Vladislav Prodan" : > > --- Original message --- > > From: "Vadim A. Misbakh-Soloviov" > > Date: 17 November 2016, 18:22:58 > > > >> head -c3 filename | xxd > > > > Или использовать кроссплатформенный hexdump > > > > head -c3 filename | hexdump -C > > > > -- > > Vladislav V. Prodan > > System & Network Administrator > > support.od.ua > > > > _______________________________________________ > > 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 было извлечено… URL: From nginx-forum на forum.nginx.org Sat Nov 19 07:46:53 2016 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Sat, 19 Nov 2016 02:46:53 -0500 Subject: =?UTF-8?B?0JrQsNC6INCyIGhlbHBlci3Qv9GA0L7RhtC10YHRgdC1INC30LDQutGA0YvRgtGM?= =?UTF-8?B?INC70LjRiNC90LjQtSBsb2ct0YTQsNC50LvRiz8=?= Message-ID: Имеется плагин, который через fork запускает NGX_PROCESS_HELPER для выполнения долгой операции. Фоновый процесс иногда не реагирует на "nginx -s reopen" и продолжает держать открытыми все log-файлы. Это мешает их ротации и парсингу. Поэтому в качестве временного решения хотелось бы закрывать log-файлы перед for ( ;; ) { ngx_process_events_and_timers(cycle); } Будет рабочим такой код? https://gist.github.com/ilyaevseev/840338bb44ef061b9ed8ad52f9ec6ff0 Есть ли более оптимальные варианты? Фоновый процесс пишет логи только вызовами ngx_log_error(NGX_LOG_xx, ngx_cycle->log, ...) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271047,271047#msg-271047 From nginx-forum на forum.nginx.org Sun Nov 20 06:55:40 2016 From: nginx-forum на forum.nginx.org (dblokhin) Date: Sun, 20 Nov 2016 01:55:40 -0500 Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QviDQsdCw0LM/INCe0YLQutCw0LfRi9Cy0LDQtdGC0YE=?= =?UTF-8?B?0Y8g0LrQtdGI0LjRgNC+0LLQsNGC0Ywg0LTQu9GPINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= Message-ID: Добрый день. В server_name указаны 5 доменов, настроен proxy-кэш для отдельных страниц. Для одного из доменов в списке server_name Nginx отказывается создавать кэш от бэкенда. Для остальных доменов кэш генерируется отлично. Конфигурация: proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m; proxy_temp_path /data/nginx/tmp; server { listen 80; server_name русский_домен.xn--p1ai www.русский_домен.xn--p1ai domain.ru www.domain.ru domain-test.ru; charset utf-8; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600; proxy_connect_timeout 600; location = / { proxy_pass http://backend; proxy_cache one; proxy_cache_key $request_uri; proxy_cache_valid 200 10m; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header Connection ""; } // else } Кэш для главной успешно создается во всех случаях, кроме домена domain.ru proxy_cache_key только от URI - т.к. все домены - зеркала основного. Пробовал использовать вариант: server_name .русский_домен.xn--p1ai .domain.ru domain-test.ru; Тоже не кэшит именно для домена domain.ru. С чем это может быть связано? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271055,271055#msg-271055 From vbart на nginx.com Sun Nov 20 08:11:48 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 20 Nov 2016 11:11:48 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: References: Message-ID: <2058933.aWAm0Vs5gD@vbart-laptop> On Sunday 20 November 2016 01:55:40 dblokhin wrote: > Добрый день. > > В server_name указаны 5 доменов, настроен proxy-кэш для отдельных страниц. > Для одного из доменов в списке server_name Nginx отказывается создавать кэш > от бэкенда. Для остальных доменов кэш генерируется отлично. > > Конфигурация: > > proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m; > proxy_temp_path /data/nginx/tmp; > > server { > listen 80; > server_name русский_домен.xn--p1ai www.русский_домен.xn--p1ai domain.ru > www.domain.ru domain-test.ru; > charset utf-8; > > proxy_send_timeout 600; > proxy_read_timeout 600; > send_timeout 600; > proxy_connect_timeout 600; > > location = / { > proxy_pass http://backend; > proxy_cache one; > proxy_cache_key $request_uri; > proxy_cache_valid 200 10m; > > proxy_http_version 1.1; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header Connection ""; > } > > // else > } > > Кэш для главной успешно создается во всех случаях, кроме домена domain.ru > proxy_cache_key только от URI - т.к. все домены - зеркала основного. > > Пробовал использовать вариант: > server_name .русский_домен.xn--p1ai .domain.ru domain-test.ru; > > Тоже не кэшит именно для домена domain.ru. С чем это может быть связано? > С заголовками ответа вашего бэкенда, которые запрещают кэшировать. -- Валентин Бартенев From nginx-forum на forum.nginx.org Sun Nov 20 09:24:10 2016 From: nginx-forum на forum.nginx.org (dblokhin) Date: Sun, 20 Nov 2016 04:24:10 -0500 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: <2058933.aWAm0Vs5gD@vbart-laptop> References: <2058933.aWAm0Vs5gD@vbart-laptop> Message-ID: <339e413510f2545c9712da4117cafecc.NginxMailingListRussian@forum.nginx.org> Валентин, предположу, вы не поняли вопрос. Если бы от бэкенда шли запрещающие заголовки, то на всех доменах не работало кэширование. Бэкенд один и тот же, логики на особую обработку какого-то домена нет. Заголовки (от бэкенда) самые обычные: 200 OK Connection: close Date: Sun, 20 Nov 2016 06:09:47 GMT Content-Type: text/html; charset=utf-8 Client-Date: Sun, 20 Nov 2016 09:09:48 GMT Client-Peer: Х.Х.Х.Х Client-Response-Num: 1 Client-Transfer-Encoding: chunked X-Content-Type-Options: nosniff X-Xss-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Сейчас обнаружилась важная деталь. Дело в том, что доменные имена переведены на сервис Сloudflare. Nginx, таким образом, за Сloudflare. И если обращаться к серверу напрямую по имени domain.ltd, то кэш успешно создается. Если же обычным путем (через Cloudflare), то при обращении именно на определенный домен кэш не создается. С чем это может быть связано? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271056,271057#msg-271057 From nginx-ru на sadok.spb.ru Sun Nov 20 09:43:43 2016 From: nginx-ru на sadok.spb.ru (Dmitry Ivanov) Date: Sun, 20 Nov 2016 12:43:43 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: <339e413510f2545c9712da4117cafecc.NginxMailingListRussian@forum.nginx.org> References: <2058933.aWAm0Vs5gD@vbart-laptop> <339e413510f2545c9712da4117cafecc.NginxMailingListRussian@forum.nginx.org> Message-ID: <432840954.20161120124343@sadok.spb.ru> Здравствуйте, dblokhin. Вы писали 20 ноября 2016 г., 12:24:10: > к серверу напрямую по имени domain.ltd, то кэш успешно создается. Если же > обычным путем (через Cloudflare), то при обращении именно на определенный > домен кэш не создается. С чем это может быть связано? А подумать? -- С уважением, Dmitry nginx-ru на sadok.spb.ru From nginx-forum на forum.nginx.org Sun Nov 20 10:34:15 2016 From: nginx-forum на forum.nginx.org (dblokhin) Date: Sun, 20 Nov 2016 05:34:15 -0500 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: <432840954.20161120124343@sadok.spb.ru> References: <432840954.20161120124343@sadok.spb.ru> Message-ID: > А подумать? Может просветите? Чем же особенным может выделятся 1 домен из одного ряда доменов? Только в России так могут отвечать. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271056,271059#msg-271059 From onokonem на gmail.com Sun Nov 20 11:09:52 2016 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 20 Nov 2016 14:09:52 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: References: <432840954.20161120124343@sadok.spb.ru> Message-ID: > Может просветите? Чем же особенным может выделятся 1 домен из одного ряда > доменов? снимите снифером заголовки ответов для этого и другого какого-нибудь домена, да и выясните, в чем разница. > Только в России так могут отвечать. это правда. наши западные коллеги тихо проигнорили бы вас. From nginx-forum на forum.nginx.org Sun Nov 20 11:24:02 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sun, 20 Nov 2016 06:24:02 -0500 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: <339e413510f2545c9712da4117cafecc.NginxMailingListRussian@forum.nginx.org> References: <2058933.aWAm0Vs5gD@vbart-laptop> <339e413510f2545c9712da4117cafecc.NginxMailingListRussian@forum.nginx.org> Message-ID: <61915068e2db773b2268762a61c7d061.NginxMailingListRussian@forum.nginx.org> Nginx, таким образом, за Сloudflare. > И если обращаться к серверу напрямую по имени domain.ltd, то кэш > успешно создается. Если же обычным путем (через Cloudflare), то при > обращении именно на определенный домен кэш не создается. С чем это > может быть связано? Возможно Cloudflare не отправляет запрос к Nginx и выдает ответ из своего кеша, или отправляет запрос к вашему Nginx, но в запросе есть какие то параметры которые не позволяют Nginx создавать кеш. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271056,271061#msg-271061 From endo.mulo на gmail.com Sun Nov 20 13:40:11 2016 From: endo.mulo на gmail.com (Dmitriy M.) Date: Sun, 20 Nov 2016 15:40:11 +0200 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler Message-ID: Добрый день, у нас включен HTTP/2, обслуживаются до 2000 req/s и до 300 conn/s в пике, после обновления OS и nginx до nginx/1.10.2 за несколько суток получили около 10 крашей с одинаковыми 2мя бектрейсами: Первый : #0 0x00000000004a86c4 in ngx_http_v2_write_handler (wev=) at src/http/v2/ngx_http_v2.c:435 435 ngx_queue_remove(q); [New Thread 801c16000 (LWP 100654/)] (gdb) bt #0 0x00000000004a86c4 in ngx_http_v2_write_handler (wev=) at src/http/v2/ngx_http_v2.c:435 #1 0x000000000046d776 in ngx_kqueue_process_events (cycle=, timer=, flags=0) at src/event/modules/ngx_kqueue_module.c:669 #2 0x0000000000464ac4 in ngx_process_events_and_timers (cycle=0x85c1e6050) at src/event/ngx_event.c:242 #3 0x000000000046bf68 in ngx_worker_process_cycle (cycle=, data=) at src/os/unix/ngx_process_cycle.c:753 #4 0x000000000046a616 in ngx_spawn_process (cycle=, proc=, data=, name=, respawn=) at src/os/unix/ngx_process.c:198 #5 0x000000000046b819 in ngx_start_worker_processes (cycle=, n=8, type=-4) at src/os/unix/ngx_process_cycle.c:358 #6 0x000000000046b638 in ngx_master_process_cycle (cycle=0x85c1e6050) at src/os/unix/ngx_process_cycle.c:243 #7 0x00000000004481f4 in main (argc=, argv=) at src/core/nginx.c:367 Current language: auto; currently minimal (gdb) fr 0 #0 0x00000000004a86c4 in ngx_http_v2_write_handler (wev=) at src/http/v2/ngx_http_v2.c:435 435 ngx_queue_remove(q); (gdb) l 430 } 431 432 while (!ngx_queue_empty(&h2c->posted)) { 433 q = ngx_queue_head(&h2c->posted); 434 435 ngx_queue_remove(q); 436 437 stream = ngx_queue_data(q, ngx_http_v2_stream_t, queue); 438 439 stream->handled = 0; (gdb) Второй : #0 ngx_http_v2_write_handler (wev=) at src/http/v2/ngx_http_v2.c:444 444 wev = stream->request->connection->write; [New Thread 801c16000 (LWP 100643/)] (gdb) bt #0 ngx_http_v2_write_handler (wev=) at src/http/v2/ngx_http_v2.c:444 #1 0x000000000046d776 in ngx_kqueue_process_events (cycle=, timer=, flags=0) at src/event/modules/ngx_kqueue_module.c:669 #2 0x0000000000464ac4 in ngx_process_events_and_timers (cycle=0x801c8b050) at src/event/ngx_event.c:242 #3 0x000000000046bf68 in ngx_worker_process_cycle (cycle=, data=) at src/os/unix/ngx_process_cycle.c:753 #4 0x000000000046a616 in ngx_spawn_process (cycle=, proc=, data=, name=, respawn=) at src/os/unix/ngx_process.c:198 #5 0x000000000046b819 in ngx_start_worker_processes (cycle=, n=8, type=-3) at src/os/unix/ngx_process_cycle.c:358 #6 0x000000000046afe5 in ngx_master_process_cycle (cycle=) at src/os/unix/ngx_process_cycle.c:130 #7 0x00000000004481f4 in main (argc=, argv=) at src/core/nginx.c:367 Current language: auto; currently minimal (gdb) fr 0 #0 ngx_http_v2_write_handler (wev=) at src/http/v2/ngx_http_v2.c:444 444 wev = stream->request->connection->write; (gdb) l 439 stream->handled = 0; 440 441 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, c->log, 0, 442 "run http2 stream %ui", stream->node->id); 443 444 wev = stream->request->connection->write; 445 446 wev->active = 0; 447 wev->ready = 1; 448 В логах ничего кроме: 2016/11/18 01:39:36 [alert] 628#100623: worker process 19425 exited on signal 11 (core dumped) Опции сборки (собиралось из исходников): nginx version: nginx/1.10.2 built by clang 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) built with LibreSSL 2.4.4 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_realip_module --with-http_stub_status_module --with-pcre --with-threads --add-dynamic-module=./headers-more-nginx-module-84241e4 --with-http_ssl_module --with-http_v2_module --add-module=./nginx-upload-progress-module-0.9.0u --with-openssl=./libressl-2.4.4 OS: FreeBSD 11.0-STABLE #1 r308689 Буду рад помочь в поиске и устранении проблемы (если она еще не устранена в 1.11.*), если нужны дополнительные данные - попробую предоставить. Спасибо! From vbart на nginx.com Sun Nov 20 15:12:22 2016 From: vbart на nginx.com (Valentin V. Bartenev) Date: Sun, 20 Nov 2016 18:12:22 +0300 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler In-Reply-To: References: Message-ID: <1837308.OK70lT2DeE@vbart-laptop> On Sunday 20 November 2016 15:40:11 Dmitriy M. wrote: [..] > --add-dynamic-module=./headers-more-nginx-module-84241e4 > --with-http_ssl_module --with-http_v2_module > --add-module=./nginx-upload-progress-module-0.9.0u > --with-openssl=./libressl-2.4.4 > > OS: FreeBSD 11.0-STABLE #1 r308689 > > > Буду рад помочь в поиске и устранении проблемы (если она еще не > устранена в 1.11.*), если нужны дополнительные данные - попробую > предоставить. > > Спасибо! > [..] Сперва стоит убедиться в том, что проблема воспроизводится без сторонних модулей. -- Валентин Бартенев From endo.mulo на gmail.com Sun Nov 20 15:58:45 2016 From: endo.mulo на gmail.com (Dmitriy M.) Date: Sun, 20 Nov 2016 17:58:45 +0200 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler In-Reply-To: <1837308.OK70lT2DeE@vbart-laptop> References: <1837308.OK70lT2DeE@vbart-laptop> Message-ID: 20 ноября 2016 г., 17:12 пользователь Valentin V. Bartenev написал: > On Sunday 20 November 2016 15:40:11 Dmitriy M. wrote: > [..] >> --add-dynamic-module=./headers-more-nginx-module-84241e4 >> --with-http_ssl_module --with-http_v2_module >> --add-module=./nginx-upload-progress-module-0.9.0u >> --with-openssl=./libressl-2.4.4 >> >> OS: FreeBSD 11.0-STABLE #1 r308689 >> >> >> Буду рад помочь в поиске и устранении проблемы (если она еще не >> устранена в 1.11.*), если нужны дополнительные данные - попробую >> предоставить. >> >> Спасибо! >> > [..] > > Сперва стоит убедиться в том, что проблема воспроизводится > без сторонних модулей. > > -- > Валентин Бартенев > _______________________________________________ К сожалению, это практически невозможно. Сервису необходимы перечисленные при сборке модули, без них возможности проверки под нагрузкой нет. Способа воспроизведения нет, они происходят неконтролируемо и очень редко (1-2 краша в сутки на ряде разных клонированных сетапов). Могу дополнить, что эти же модули (набор модулей, но да headers-more-nginx-module-84241e4 и libressl были обновлены) были вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода крашей небыло, конфигурация nginx.conf существенно не менялась. Попробую собрать с предыдущими версиями модулей (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без оптимизаций кода для дебаггинга. https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/ From swood на fotofor.biz Sun Nov 20 16:09:45 2016 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sun, 20 Nov 2016 19:09:45 +0300 Subject: ignore long locked inactive cache entry Message-ID: Здраствуйте. Имеем nginx 1.11.1 с конфигом для кэширования: proxy_cache_path /path/to/cache/folder levels=1:2 keys_zone=two:128m max_size=120g inactive=120m loader_sleep=5ms; proxy_temp_path /path/to/temp/folder 1 2; proxy_ignore_headers Expires Cache-Control; proxy_cache_min_uses 2; proxy_cache_valid 200 302 7d; proxy_cache_key $uri; proxy_force_ranges on; Примерно через 4 часа после перезапуска в логе начинают появляться сообщения типа: ignore long locked inactive cache entry e4717ba34b1d9f128e974fb692755202, count:1 После чего свободного места в разделе не остается совсем. Если перезапустить процесс, то nginx успешно удалит все лишнее и свободное место появится снова. Не подскажете, что с этим можно сделать? Каких-то дополнительных модулей для кэширования нет. -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart на nginx.com Sun Nov 20 16:17:12 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 20 Nov 2016 19:17:12 +0300 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler In-Reply-To: References: <1837308.OK70lT2DeE@vbart-laptop> Message-ID: <6791207.lFIfeuULy3@vbart-laptop> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote: [..] > > К сожалению, это практически невозможно. Сервису необходимы > перечисленные при сборке модули, без них возможности проверки под > нагрузкой нет. Способа воспроизведения нет, они происходят > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных > клонированных сетапов). > > Могу дополнить, что эти же модули (набор модулей, но да > headers-more-nginx-module-84241e4 и libressl были обновлены) были > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода > крашей небыло, конфигурация nginx.conf существенно не менялась. > > Попробую собрать с предыдущими версиями модулей > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без > оптимизаций кода для дебаггинга. > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/ То, что модули раньше работали - абсолютно не показатель. Многие сторонние модули славятся тем, что лезут во внутренние структуры nginx, используя их не по назначению. Как результат, такие модули могут поломать nginx при любых изменениях в его внутренних механизмах. Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке тела запроса в модуле http/2. Бектрейс, который вы привели - не содержит какой-либо полезной информации для дебага. Ошибка, послужившая причиной падения, произошла в другом месте, на другой итерации цикла обработки событий. А то, что видно на бэктрейсе - лишь следствие. Можно попытаться получить debug-лог перед падением: http://nginx.org/ru/docs/debugging_log.html#memory Смотрите раздел про запись его в буфер в памяти. -- Валентин Бартенев From vbart на nginx.com Sun Nov 20 16:22:46 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 20 Nov 2016 19:22:46 +0300 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler In-Reply-To: <6791207.lFIfeuULy3@vbart-laptop> References: <6791207.lFIfeuULy3@vbart-laptop> Message-ID: <2276684.pvFDZpfd01@vbart-laptop> On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote: > On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote: > [..] > > > > К сожалению, это практически невозможно. Сервису необходимы > > перечисленные при сборке модули, без них возможности проверки под > > нагрузкой нет. Способа воспроизведения нет, они происходят > > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных > > клонированных сетапов). > > > > Могу дополнить, что эти же модули (набор модулей, но да > > headers-more-nginx-module-84241e4 и libressl были обновлены) были > > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода > > крашей небыло, конфигурация nginx.conf существенно не менялась. > > > > Попробую собрать с предыдущими версиями модулей > > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без > > оптимизаций кода для дебаггинга. > > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/ > > То, что модули раньше работали - абсолютно не показатель. Многие сторонние > модули славятся тем, что лезут во внутренние структуры nginx, используя их > не по назначению. Как результат, такие модули могут поломать nginx при любых > изменениях в его внутренних механизмах. > > Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке > тела запроса в модуле http/2. > > Бектрейс, который вы привели - не содержит какой-либо полезной информации > для дебага. Ошибка, послужившая причиной падения, произошла в другом месте, > на другой итерации цикла обработки событий. А то, что видно на бэктрейсе - > лишь следствие. > > Можно попытаться получить debug-лог перед падением: > http://nginx.org/ru/docs/debugging_log.html#memory > > Смотрите раздел про запись его в буфер в памяти. > [..] И в дополнение к предыдущему письму, а вы уверены, что у вас nginx-upload-progress-module вообще с HTTP/2 корректно работает? Судя по тому же тикету на github, он и не должен: https://github.com/masterzen/nginx-upload-progress-module/issues/45 Интересно также, что вы делаете с помощью headers-more-nginx-module, что не получается сделать стандартными средствами nginx? -- Валентин Бартенев From swood на fotofor.biz Sun Nov 20 16:44:27 2016 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sun, 20 Nov 2016 19:44:27 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: References: Message-ID: Проверил, файл и правда занят процессом nginx. Встает вопрос, а что с этим делать тогда? Файл никто не запрашивает, его пытаются удалить, а его видели сам же nginx и удерживает. Файл не удаляется и в итоге раздел забивается в ноль. Можно ли придумать опцию о принудительном удалении элемента кэша, если у него он должен вытесниться, но почему-то его держит сам nginx? Ведь по сути, если этот элемент кому-то понадобится и он станет снова популярным, то он снова будет записан в место для кэширования и нет смысла его удерживать и блокировать удаление. Может ли тут играть злую шутку http2? А keepalive ? 20 ноября 2016 г., 19:09 пользователь Anton Kiryushkin написал: > Здраствуйте. > > Имеем nginx 1.11.1 с конфигом для кэширования: > > proxy_cache_path /path/to/cache/folder levels=1:2 keys_zone=two:128m > max_size=120g inactive=120m loader_sleep=5ms; > proxy_temp_path /path/to/temp/folder 1 2; > proxy_ignore_headers Expires Cache-Control; > proxy_cache_min_uses 2; > proxy_cache_valid 200 302 7d; > proxy_cache_key $uri; > proxy_force_ranges on; > > > Примерно через 4 часа после перезапуска в логе начинают появляться > сообщения типа: > > ignore long locked inactive cache entry e4717ba34b1d9f128e974fb692755202, > count:1 > > После чего свободного места в разделе не остается совсем. Если > перезапустить процесс, то nginx успешно удалит все лишнее и свободное место > появится снова. > > Не подскажете, что с этим можно сделать? > > Каких-то дополнительных модулей для кэширования нет. > > -- > Best regards, > Anton Kiryushkin > > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From basil на vpm.net.ua Sun Nov 20 17:52:10 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Sun, 20 Nov 2016 19:52:10 +0200 Subject: ignore long locked inactive cache entry In-Reply-To: References: Message-ID: у Вас за 4 часа заполняется 120 гигов ? 20 ноября 2016 г., 18:44 пользователь Anton Kiryushkin написал: > Проверил, файл и правда занят процессом nginx. Встает вопрос, а что с этим > делать тогда? Файл никто не запрашивает, его пытаются удалить, а его видели > сам же nginx и удерживает. Файл не удаляется и в итоге раздел забивается в > ноль. Можно ли придумать опцию о принудительном удалении элемента кэша, > если у него он должен вытесниться, но почему-то его держит сам nginx? Ведь > по сути, если этот элемент кому-то понадобится и он станет снова > популярным, то он снова будет записан в место для кэширования и нет смысла > его удерживать и блокировать удаление. Может ли тут играть злую шутку > http2? А keepalive ? > > 20 ноября 2016 г., 19:09 пользователь Anton Kiryushkin > написал: > >> Здраствуйте. >> >> Имеем nginx 1.11.1 с конфигом для кэширования: >> >> proxy_cache_path /path/to/cache/folder levels=1:2 keys_zone=two:128m >> max_size=120g inactive=120m loader_sleep=5ms; >> proxy_temp_path /path/to/temp/folder 1 2; >> proxy_ignore_headers Expires Cache-Control; >> proxy_cache_min_uses 2; >> proxy_cache_valid 200 302 7d; >> proxy_cache_key $uri; >> proxy_force_ranges on; >> >> >> Примерно через 4 часа после перезапуска в логе начинают появляться >> сообщения типа: >> >> ignore long locked inactive cache entry e4717ba34b1d9f128e974fb692755202, >> count:1 >> >> После чего свободного места в разделе не остается совсем. Если >> перезапустить процесс, то nginx успешно удалит все лишнее и свободное место >> появится снова. >> >> Не подскажете, что с этим можно сделать? >> >> Каких-то дополнительных модулей для кэширования нет. >> >> -- >> Best regards, >> Anton Kiryushkin >> >> > > > -- > Best regards, > Anton Kiryushkin > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Nov 21 00:57:22 2016 From: nginx-forum на forum.nginx.org (dblokhin) Date: Sun, 20 Nov 2016 19:57:22 -0500 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: <61915068e2db773b2268762a61c7d061.NginxMailingListRussian@forum.nginx.org> References: <2058933.aWAm0Vs5gD@vbart-laptop> <339e413510f2545c9712da4117cafecc.NginxMailingListRussian@forum.nginx.org> <61915068e2db773b2268762a61c7d061.NginxMailingListRussian@forum.nginx.org> Message-ID: <19018fa26b1217525f943d5dde73a940.NginxMailingListRussian@forum.nginx.org> > Возможно Cloudflare не отправляет запрос к Nginx и выдает > ответ из своего кеша, или отправляет запрос к вашему Nginx, > но в запросе есть какие то параметры которые не позволяют > Nginx создавать кеш. Добрый день! Спасибо за отклик, но Cloudflare по умолчанию не кэширует HTML-контент, для этого его надо отдельно настроить (если бы он был бы настроен, вопрос бы не появился здесь). Даже если представить, что он вопреки всему отдавал страничку для домена_1 из своего кэша, то для остальных 4 доменов поведение было бы таким же, но его не было. Напоминаю, что 1 ресурс доступен по 5 доменам: server_name domain1 domain2 domain3 domain4 domain5; и, скажем, для domain4 кэш не создается. Согласно, логу nginx запросы от Cloudflare приходят такие: > GET / HTTP/1.1 > GET /about HTTP/1.1 Т.е. он их прозрачно проксирует без изменения запроса. Опять же, даже если бы он добавлял в запрос что-то свое, что не позволяло nginx'у создавать кэш, то такое же поведение было бы для других 4 доменов, но этого не было. В любом случае, я прекращаю беспокоить местных специалистов, которые видимо не знают о культурах своих "западных коллег" типа Quora, StackOverflow и множества отдельных сообществ, дабы не отвлекать заниматься своим самым важным делом и дать им жить в своем безмолвном игнорируемом молчании. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271056,271077#msg-271077 From mdounin на mdounin.ru Mon Nov 21 02:02:00 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 21 Nov 2016 05:02:00 +0300 Subject: fastcgi_cache_lock doesnt work In-Reply-To: <06275492e4242fd7c113895af0f189cd.NginxMailingListRussian@forum.nginx.org> References: <06275492e4242fd7c113895af0f189cd.NginxMailingListRussian@forum.nginx.org> Message-ID: <20161121020159.GG8196@mdounin.ru> Hello! On Thu, Nov 17, 2016 at 10:49:58AM -0500, permyakovsv wrote: > I have further configuration: > fastcgi_cache fastcgi_cache_products; > fastcgi_cache_valid 200 302 304 404 25m; > fastcgi_cache_valid 301 5m; > fastcgi_cache_valid 500 502 20s; > > fastcgi_cache_lock on; > fastcgi_cache_lock_timeout 25s; > fastcgi_cache_use_stale updating error timeout > invalid_header http_500 http_503; > > And I see netx picture: > date http_code http_cache_status > backend_responce > ... > 17/Nov/2016:17:19:54 +0200 200 cs=HIT 0 > 17/Nov/2016:17:19:14 +0200 200 cs=EXPIRED 8.041 > 17/Nov/2016:17:18:07 +0200 200 cs=EXPIRED 3.218 > 17/Nov/2016:17:17:24 +0200 200 cs=EXPIRED 3.291 > 17/Nov/2016:17:17:21 +0200 200 cs=UPDATING 0 > 17/Nov/2016:17:16:14 +0200 200 cs=EXPIRED 3.538 > 17/Nov/2016:17:15:53 +0200 200 cs=EXPIRED 2.977 > 17/Nov/2016:17:14:32 +0200 200 cs=EXPIRED 4.119 > 17/Nov/2016:17:13:49 +0200 200 cs=EXPIRED 4.784 > 17/Nov/2016:17:13:04 +0200 200 cs=HIT 0 > ... > 17/Nov/2016:16:48:44 +0200 200 cs=HIT 0 > 17/Nov/2016:16:48:37 +0200 200 cs=EXPIRED 4.279 > 17/Nov/2016:16:47:57 +0200 200 cs=EXPIRED 3.936 > 17/Nov/2016:16:47:46 +0200 200 cs=EXPIRED 3.447 > 17/Nov/2016:16:46:53 +0200 200 cs=EXPIRED 3.287 > ... > > But I expect only one request to backend, and why first request didn't > update cache? > Maybe Anybody faced the same problem? First of all, the fastcgi_cache_lock directive is unrelated to updating existing cache entries, it only works when loading _new_ items into cache. See http://nginx.org/r/fastcgi_cache_lock for details. In case of updating "fastcgi_cache_use_stale updating" is expected to work, and "UPDATING" in your logs suggests that it does its job just fine: it prevents multiple parallel requests to upstream servers. It clearly prevented multiple requests here: > 17/Nov/2016:17:17:24 +0200 200 cs=EXPIRED 3.291 > 17/Nov/2016:17:17:21 +0200 200 cs=UPDATING 0 the request at 17:17:21 was served from cache (UPDATING status and zero upstream response time) as the request finished at 17:17:24 was already started at that time. Next question is: why requests doesn't update the cache. But "HIT" in logs clearly indicate that cache is updated, and correctly used. What probably looks confusing is that expiration times are clearly much shorter than configured in proxy_cache_valid directives. This is quite normal though: as long as there are Cache-Control or Expires directives, nginx will use them for cache expiration times instead of proxy_cache_valid. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Mon Nov 21 04:47:53 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 21 Nov 2016 09:47:53 +0500 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: <19018fa26b1217525f943d5dde73a940.NginxMailingListRussian@forum.nginx.org> References: <2058933.aWAm0Vs5gD@vbart-laptop> <339e413510f2545c9712da4117cafecc.NginxMailingListRussian@forum.nginx.org> <61915068e2db773b2268762a61c7d061.NginxMailingListRussian@forum.nginx.org> <19018fa26b1217525f943d5dde73a940.NginxMailingListRussian@forum.nginx.org> Message-ID: 21 ноября 2016 г., 5:57 пользователь dblokhin написал: > > Возможно Cloudflare не отправляет запрос к Nginx и выдает > > ответ из своего кеша, или отправляет запрос к вашему Nginx, > > но в запросе есть какие то параметры которые не позволяют > > Nginx создавать кеш. > > Добрый день! > > Спасибо за отклик, но Cloudflare по умолчанию не кэширует HTML-контент, для > этого его надо отдельно настроить (если бы он был бы настроен, вопрос бы не > появился здесь). Даже если представить, что он вопреки всему отдавал > страничку для домена_1 из своего кэша, то для остальных 4 доменов поведение > было бы таким же, но его не было. > возможно, вам будет лучше напрямую пообщаться с тем, кто настроил 4 правильно работающих домена, навряд ли в списке рассылки кто-то обладает такой информацией. > Напоминаю, что 1 ресурс доступен по 5 доменам: > server_name domain1 domain2 domain3 domain4 domain5; > > и, скажем, для domain4 кэш не создается. > > Согласно, логу nginx запросы от Cloudflare приходят такие: > > GET / HTTP/1.1 > > GET /about HTTP/1.1 > > Т.е. он их прозрачно проксирует без изменения запроса. Опять же, даже если > бы он добавлял в запрос что-то свое, что не позволяло nginx'у создавать > кэш, > то такое же поведение было бы для других 4 доменов, но этого не было. > > В любом случае, я прекращаю беспокоить местных специалистов, которые видимо > не знают о культурах своих "западных коллег" типа Quora, StackOverflow и > множества отдельных сообществ, дабы не отвлекать заниматься своим самым > важным делом и дать им жить в своем безмолвном игнорируемом молчании. > возможно, вам действительно стоит задать этот вопрос на StackOverflow или Quora. приносим извинения, за то, что поддержка на данном списке рассылки не оправдала ваших ожиданий > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,271056,271077#msg-271077 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Nov 21 07:15:15 2016 From: nginx-forum на forum.nginx.org (waster) Date: Mon, 21 Nov 2016 02:15:15 -0500 Subject: =?UTF-8?B?0J/QtdGA0LjQvtC00LjRh9C10YHQutC40LUg0LfQsNCy0LjRgdCw0L3QuNGPINCy?= =?UTF-8?B?INC+0YLQstC10YLQsNGFINC90LAg0LfQsNC/0YDQvtGB0Ys=?= Message-ID: <6f41726b24bc8f0a97fe8493d8f50dfc.NginxMailingListRussian@forum.nginx.org> Здравствуйте, Установлен Nginx 1.10.1, нагрузка в пике достигает 2Gbps (~6K handled_requests/sec). Sysctl поднастроен: ---------------------------------------------------------------------------------------------------------------- # Custom net.ipv4.tcp_fin_timeout=10 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_tw_reuse = 1 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65536 net.ipv4.tcp_rfc1337 = 1 net.ipv4.ip_local_port_range = 16384 65535 fs.file-max = 200000 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 vm.overcommit_memory = 1 ---------------------------------------------------------------------------------------------------------------- Пример конфигурации: https://forum.nginx.org/read.php?21,270342 Почему-то периодически (раз в несколько минут) наблюдаются зависания в ответах, причем даже на статусный запрос. C включенным keepalive для upstream "затыки" встречаются гораздо чаще, при снижении нагрузки (в ночные часы) они сохраняются. Ниже даны примеры обычного запроса, и запроса, на котором наблюдается "затык". Видно, что в этот момент резко подскакивает Writing. # curl http://localhost/status Active connections: 12917 server accepts handled requests 39318277 39318277 473217981 Reading: 1 Writing: 100 Waiting: 12806 ------------------------------------------------------------ # curl http://localhost/status (несколько секунд ждем ответ) Active connections: 16261 server accepts handled requests 39322503 39322503 473225372 Reading: 0 Writing: 6960 Waiting: 9282 ------------------------------------------------------------ Кроме того, в этот момент видно увеличение очереди TCP: #ss -lt State Recv-Q Send-Q Local Address:Port Peer Address:Port ... LISTEN 1579 65535 *:http *:* ... Подскажите, пожалуйста, в чем может быть причина? С уважением, Андрей. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271081,271081#msg-271081 From nginx на kinetiksoft.com Mon Nov 21 12:49:24 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Mon, 21 Nov 2016 15:49:24 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LHQsNCzPyDQntGC0LrQsNC30YvQstCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LXRiNC40YDQvtCy0LDRgtGMINC00LvRjyDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQtyDQvdC10YHQutC+0LvRjNC60LjRhSBzZXJ2ZXIgbmFtZQ==?= In-Reply-To: <19018fa26b1217525f943d5dde73a940.NginxMailingListRussian@forum.nginx.org> References: <2058933.aWAm0Vs5gD@vbart-laptop> <61915068e2db773b2268762a61c7d061.NginxMailingListRussian@forum.nginx.org> <19018fa26b1217525f943d5dde73a940.NginxMailingListRussian@forum.nginx.org> Message-ID: <4920602.q4PTqzeFN5@cybernote> Настройте на веб-сервере отдельный виртуалхост, который бы обслуживал только "некешируемый" домен. И посмотрите что будет. Уверен. что дело в кривых настройках CF для конкретного домена. В любом случае поснифайте траф, как Вам уже написали, сразу станет яснее. С обеих сторон веб-сервера - как от CF, так и от бэкнэнда. Хотя с учетом > И если обращаться > к серверу напрямую по имени domain.ltd, то кэш успешно создается. Если же > обычным путем (через Cloudflare), то при обращении именно на определенный > домен кэш не создается. С чем это может быть связано? дело, повторюсь, в хедерах от CF к вашему nginx. Не умеете сами - наймите специалиста. И переставайте хамить. Это не работает даже в платном саппорте, а уж в бесплатном списке рассылки и подавно - тут вам (внезапно!) вообще никто ничего не должен. From nginx-forum на forum.nginx.org Tue Nov 22 11:00:52 2016 From: nginx-forum на forum.nginx.org (nerjin) Date: Tue, 22 Nov 2016 06:00:52 -0500 Subject: 400 Bad Request Message-ID: Nginx ругается на такой запрос: "GET http://ankerch-crimea.ru?page=home HTTP/1.1" 400 Я так понимаю из-за того, что нет слеша после домена, но по спецификации такой вариант возможен, если в нем нет логина-пароля (правда я дальше википедии не проверял): scheme:[//[user:password@]host[:port]][/]path[?query][#fragment] A path, which contains data, usually organized in hierarchical form, that appears as a sequence of segments separated by slashes. Such a sequence may resemble or map exactly to a file system path, but does not always imply a relation to one. The path must begin with a single slash (/) if an authority part was present, and may also if one was not, but must not begin with a double slash. Браузеры такую ситуацию обрабатывают, сами добавляют слеш. А вот если из кода делать запрос, то напарываешься на 400 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271109,271109#msg-271109 From mdounin на mdounin.ru Tue Nov 22 13:55:46 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 22 Nov 2016 16:55:46 +0300 Subject: 400 Bad Request In-Reply-To: References: Message-ID: <20161122135546.GK8196@mdounin.ru> Hello! On Tue, Nov 22, 2016 at 06:00:52AM -0500, nerjin wrote: > Nginx ругается на такой запрос: > > "GET http://ankerch-crimea.ru?page=home HTTP/1.1" 400 > > Я так понимаю из-за того, что нет слеша после домена, но по спецификации > такой вариант возможен, если в нем нет логина-пароля (правда я дальше > википедии не проверял): > > scheme:[//[user:password@]host[:port]][/]path[?query][#fragment] > > A path, which contains data, usually organized in hierarchical form, that > appears as a sequence of segments separated by slashes. Such a sequence may > resemble or map exactly to a file system path, but does not always imply a > relation to one. The path must begin with a single slash (/) if an authority > part was present, and may also if one was not, but must not begin with a > double slash. > > Браузеры такую ситуацию обрабатывают, сами добавляют слеш. А вот если из > кода делать запрос, то напарываешься на 400 Актуальный до недавнего времени RFC 2616 даёт такой синтаксис, https://tools.ietf.org/html/rfc2616#section-3.2.2: http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] Т.е. без пути - нельзя, если есть query. В свежем RFC 7230 синтаксис позволяет пустой путь при наличии query, https://tools.ietf.org/html/rfc7230#section-2.7.1: http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] Patches, что называется, are welcome (правда, вряд ли это получится хорошо обработать без копирования). Непонятно, впрочем, зачем вы вообще пытаетесь использовать форму запроса с абсолютным URI в строке запроса. В HTTP это используют исключительно для запросов к forward proxy (в HTTP/1.0 только это и было разрешено), обычная же форма запроса подразумевает путь в строке запроса: GET /?page=home HTTP/1.1 Host: example.com И, с учётом того, что заголовок Host так или иначе в HTTP/1.1 обязателен - такой запрос получается компактнее. Отмечу в скобках, что для подобной формы - "/" обязателен (ну и в добавок RFC 7230 как бы намекает, что по другому к origin-серверу ходить нельзя), https://tools.ietf.org/html/rfc7230#section-5.3.1: When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target. If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. A Host header field is also sent, as defined in Section 5.4. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Nov 23 10:27:20 2016 From: nginx-forum на forum.nginx.org (nerjin) Date: Wed, 23 Nov 2016 05:27:20 -0500 Subject: 400 Bad Request In-Reply-To: <20161122135546.GK8196@mdounin.ru> References: <20161122135546.GK8196@mdounin.ru> Message-ID: <6dab6fdb95d8116458fda0f9654865dd.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Непонятно, впрочем, зачем вы вообще пытаетесь использовать форму > запроса с абсолютным URI в строке запроса. В HTTP это используют > исключительно для запросов к forward proxy (в HTTP/1.0 только > это и было разрешено), обычная же форма запроса подразумевает путь > в строке запроса: Обрисую сначала ситуацию. Я использую nginx как forward proxy, обращаюсь к сайту http://ankerch-crimea.ru, а он уже через пару редиректов кидает меня на абсолютный урл http://ankerch-crimea.ru?page=home. Как раз по RFC 2616 в location должен быть абсолютный урл. Как-то изменить работу внешнего сайта возможности нет. Вопрос в том, возможно ли как-то обойти эту ошибку? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,21197,271129#msg-271129 From mdounin на mdounin.ru Wed Nov 23 14:57:02 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 23 Nov 2016 17:57:02 +0300 Subject: 400 Bad Request In-Reply-To: <6dab6fdb95d8116458fda0f9654865dd.NginxMailingListRussian@forum.nginx.org> References: <20161122135546.GK8196@mdounin.ru> <6dab6fdb95d8116458fda0f9654865dd.NginxMailingListRussian@forum.nginx.org> Message-ID: <20161123145702.GP8196@mdounin.ru> Hello! On Wed, Nov 23, 2016 at 05:27:20AM -0500, nerjin wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Непонятно, впрочем, зачем вы вообще пытаетесь использовать форму > > запроса с абсолютным URI в строке запроса. В HTTP это используют > > исключительно для запросов к forward proxy (в HTTP/1.0 только > > это и было разрешено), обычная же форма запроса подразумевает путь > > в строке запроса: > > Обрисую сначала ситуацию. Я использую nginx как forward proxy, обращаюсь к > сайту http://ankerch-crimea.ru, а он уже через пару редиректов кидает меня > на абсолютный урл http://ankerch-crimea.ru?page=home. Как раз по RFC 2616 в > location должен быть абсолютный урл. > Как-то изменить работу внешнего сайта возможности нет. Вопрос в том, > возможно ли как-то обойти эту ошибку? Нормализовавать такие URI и добавлять "/" - самое простое решение. Ну или, как уже было сказано, patches are welcome. Отмечу в скобках, что nginx - не forward proxy, используя его как forward proxy вы добровольно подписываетесь на участие в конкурсе "найди грабли". -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Nov 23 16:25:46 2016 From: nginx-forum на forum.nginx.org (nerjin) Date: Wed, 23 Nov 2016 11:25:46 -0500 Subject: 400 Bad Request In-Reply-To: <20161123145702.GP8196@mdounin.ru> References: <20161123145702.GP8196@mdounin.ru> Message-ID: Спасибо. В итоге заборол с помощью директивы proxy_redirect. Насчет forward proxy: а какая разница forward или reverse. Весь вопрос в том, кого считать клиентом, а кого upstream'ом. У меня такая конфигурация пока что отлично работает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271109,271146#msg-271146 From nginx-forum на forum.nginx.org Thu Nov 24 09:06:50 2016 From: nginx-forum на forum.nginx.org (tester0) Date: Thu, 24 Nov 2016 04:06:50 -0500 Subject: =?UTF-8?B?ZmFzdGNnaSBpZ25vcmUgaGVhZGVycyAg0L3QtSDRgNCw0LHQvtGC0LDQtdGCPw==?= Message-ID: <5d368f855f74462370064323be4210b1.NginxMailingListRussian@forum.nginx.org> Здравствуйте, имею location, в котором осуществляется fastcgi кэширование, оно работает, но почему-то в response headers получаю заголовок Set-Cookie хотя это специально отключено: fastcgi_ignore_headers Cache-Control Expires Set-Cookie ; предположительно из-за этого происходит какая-то ерунда с сессиями. в чем может быть дело? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271150,271150#msg-271150 From stalker на altlinux.ru Thu Nov 24 09:12:32 2016 From: stalker на altlinux.ru (Anton Gorlov) Date: Thu, 24 Nov 2016 12:12:32 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgaWdub3JlIGhlYWRlcnMg0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= =?UTF-8?B?Pw==?= In-Reply-To: <5d368f855f74462370064323be4210b1.NginxMailingListRussian@forum.nginx.org> References: <5d368f855f74462370064323be4210b1.NginxMailingListRussian@forum.nginx.org> Message-ID: <1d6d1505-a7c2-8f74-1de6-6ea05fdab193@altlinux.ru> 24.11.2016 12:06, tester0 пишет: > имею location, в котором осуществляется fastcgi кэширование, оно работает, > но почему-то в response headers получаю заголовок Set-Cookie > хотя это специально отключено: > fastcgi_ignore_headers Cache-Control Expires Set-Cookie ; > > предположительно из-за этого происходит какая-то ерунда с сессиями. > > в чем может быть дело? В не чтении документации? Вероятно Вам нужно http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_hide_header From mdounin на mdounin.ru Thu Nov 24 12:51:48 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 24 Nov 2016 15:51:48 +0300 Subject: 400 Bad Request In-Reply-To: References: <20161123145702.GP8196@mdounin.ru> Message-ID: <20161124125147.GQ8196@mdounin.ru> Hello! On Wed, Nov 23, 2016 at 11:25:46AM -0500, nerjin wrote: > Спасибо. > > В итоге заборол с помощью директивы proxy_redirect. > > Насчет forward proxy: а какая разница forward или reverse. Весь вопрос в > том, кого считать клиентом, а кого upstream'ом. > У меня такая конфигурация пока что отлично работает. Ну для начала - разница в синтаксисе запросов и наборе методов. Например, метод CONNECT, необходимый для forward-проксирования https, nginx просто не поддерживает. А дальше начинаются нюансы с доверием к ответу бекенда, поведением по умоланию, специальными заголовками для общения клиента и proxy, и так далее. Скажем, за-DoS'ить nginx с настройками по умолчанию, имея контроль над тем, куда он проксирует, не то чтобы сложно. И в случае forward proxy это означает, что за-DoS'ить может любой. Настроить, чтобы работало как-то - можно. Но никто не обещал, что работать будет хорошо. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Thu Nov 24 13:34:25 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 24 Nov 2016 16:34:25 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgaWdub3JlIGhlYWRlcnMgINC90LUg0YDQsNCx0L7RgtCw0LU=?= =?UTF-8?B?0YI/?= In-Reply-To: <5d368f855f74462370064323be4210b1.NginxMailingListRussian@forum.nginx.org> References: <5d368f855f74462370064323be4210b1.NginxMailingListRussian@forum.nginx.org> Message-ID: <20161124133425.GS8196@mdounin.ru> Hello! On Thu, Nov 24, 2016 at 04:06:50AM -0500, tester0 wrote: > Здравствуйте, > > имею location, в котором осуществляется fastcgi кэширование, оно работает, > но почему-то в response headers получаю заголовок Set-Cookie > хотя это специально отключено: > fastcgi_ignore_headers Cache-Control Expires Set-Cookie ; > > предположительно из-за этого происходит какая-то ерунда с сессиями. > > в чем может быть дело? Директива fastcgi_ignore_headers инструктирует nginx игнорировать соответствующие заголовки. В частности, если написано fastcgi_ignore_headers Set-Cookie; то nginx будет игнорировать наличие этого заголовка и не будет отключать кеширование, если он присутствует в ответе. Это он, судя по всему, и делает. В случае Set-Cookie - обычно также нужно спрятать соответствующие заголовки из ответа, это делается с помощью директивы fastcgi_hide_headers: fastcgi_hide_headers Set-Cookie; Подробнее можно прочитать в документации тут: http://nginx.org/r/fastcgi_ignore_headers/ru http://nginx.org/r/fastcgi_hide_header/ru -- Maxim Dounin http://nginx.org/ From webnetbt на gmail.com Thu Nov 24 14:13:28 2016 From: webnetbt на gmail.com (webnetbt на gmail.com) Date: Thu, 24 Nov 2016 17:13:28 +0300 Subject: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu) Message-ID: Доброго времени суток. Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб. Прописал client_max_body_size 900m и в server и http и даже в location. Рестарт nginx пробую загрузить файл и ошибка: 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too large body: 174579043 bytes, client: 192.168.10.10, server: localhost, request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96", referrer: "http://192.168.11.96/wp-admin/media-new.php" Что не так делаю, подскажите пожалуйста. -- С Уважением, Виталий. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Thu Nov 24 14:25:24 2016 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 24 Nov 2016 17:25:24 +0300 (MSK) Subject: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu) In-Reply-To: References: Message-ID: On Thu, 24 Nov 2016, webnetbt на gmail.com wrote: > Доброго времени суток. > Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб. > Прописал client_max_body_size 900m и в server и http и даже в location. > Рестарт nginx пробую загрузить файл и ошибка: > 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too > large body: 174579043 bytes, client: 192.168.10.10, server: localhost, > request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96", > referrer: "http://192.168.11.96/wp-admin/media-new.php" > > Что не так делаю, подскажите пожалуйста. Добрый день! Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему max body size. Или же заливать видеофайлы по scp\ftp. > -- Best regards, Andrey Kopeyko From webnetbt на gmail.com Thu Nov 24 14:28:35 2016 From: webnetbt на gmail.com (webnetbt на gmail.com) Date: Thu, 24 Nov 2016 17:28:35 +0300 Subject: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu) In-Reply-To: References: Message-ID: В php тоже настроил параметры post_max_size, upload_max_filesize. Но никаких результатов не дало. 24 ноября 2016 г., 17:25 пользователь Andrey Kopeyko написал: > On Thu, 24 Nov 2016, webnetbt на gmail.com wrote: > > Доброго времени суток. >> Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб. >> Прописал client_max_body_size 900m и в server и http и даже в location. >> Рестарт nginx пробую загрузить файл и ошибка: >> 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too >> large body: 174579043 bytes, client: 192.168.10.10, server: localhost, >> request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96", >> referrer: "http://192.168.11.96/wp-admin/media-new.php" >> >> Что не так делаю, подскажите пожалуйста. >> > > Добрый день! > > Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему max > body size. > > Или же заливать видеофайлы по scp\ftp. > > >> > -- > Best regards, > Andrey Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С Уважением, Виталий. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Thu Nov 24 14:37:51 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 24 Nov 2016 16:37:51 +0200 Subject: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu) In-Reply-To: References: Message-ID: WP напрямую работает с nginx или проксирует на апач? 2016-11-24 16:28 GMT+02:00 : > В php тоже настроил параметры post_max_size, upload_max_filesize. Но > никаких результатов не дало. > > 24 ноября 2016 г., 17:25 пользователь Andrey Kopeyko > написал: > >> On Thu, 24 Nov 2016, webnetbt на gmail.com wrote: >> >> Доброго времени суток. >>> Уже устал, не могу настроить загрузку видео файлов размером больше 170 >>> мб. >>> Прописал client_max_body_size 900m и в server и http и даже в location. >>> Рестарт nginx пробую загрузить файл и ошибка: >>> 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too >>> large body: 174579043 bytes, client: 192.168.10.10, server: localhost, >>> request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96", >>> referrer: "http://192.168.11.96/wp-admin/media-new.php" >>> >>> Что не так делаю, подскажите пожалуйста. >>> >> >> Добрый день! >> >> Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему >> max body size. >> >> Или же заливать видеофайлы по scp\ftp. >> >> >>> >> -- >> Best regards, >> Andrey Kopeyko >> _______________________________________________ >> 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 > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Nov 24 15:08:10 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 24 Nov 2016 18:08:10 +0300 Subject: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu) In-Reply-To: References: Message-ID: <20161124150810.GU8196@mdounin.ru> Hello! On Thu, Nov 24, 2016 at 05:25:24PM +0300, Andrey Kopeyko wrote: > On Thu, 24 Nov 2016, webnetbt на gmail.com wrote: > > > Доброго времени суток. > > Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб. > > Прописал client_max_body_size 900m и в server и http и даже в location. > > Рестарт nginx пробую загрузить файл и ошибка: > > 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too > > large body: 174579043 bytes, client: 192.168.10.10, server: localhost, > > request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96", > > referrer: "http://192.168.11.96/wp-admin/media-new.php" > > > > Что не так делаю, подскажите пожалуйста. > > Добрый день! > > Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему max > body size. Бекенд, конечно, подкрутить надо. Но в данном случае, очевидно, дело не в бекенде, т.к. приведённая ошибка в логах nginx'а однозначно говорит о том, что срабатывает client_max_body_size в nginx'е. Надо смотреть, что именно написано в конфиге, скорее всего - редактируется не тот конфиг, или не тот server{} / location{} в нём. -- Maxim Dounin http://nginx.org/ From webnetbt на gmail.com Thu Nov 24 21:12:47 2016 From: webnetbt на gmail.com (webnetbt на gmail.com) Date: Thu, 24 Nov 2016 21:12:47 +0000 Subject: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu) In-Reply-To: <20161124150810.GU8196@mdounin.ru> References: <20161124150810.GU8196@mdounin.ru> Message-ID: Нашли причину. Был подцеплен proxy.conf в нем прописан client_max_body_size 100m. Все поправили, работает. чт, 24 нояб. 2016 г. в 18:08, Maxim Dounin : > Hello! > > On Thu, Nov 24, 2016 at 05:25:24PM +0300, Andrey Kopeyko wrote: > > > On Thu, 24 Nov 2016, webnetbt на gmail.com wrote: > > > > > Доброго времени суток. > > > Уже устал, не могу настроить загрузку видео файлов размером больше 170 > мб. > > > Прописал client_max_body_size 900m и в server и http и даже в > location. > > > Рестарт nginx пробую загрузить файл и ошибка: > > > 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too > > > large body: 174579043 bytes, client: 192.168.10.10, server: localhost, > > > request: "POST /wp-admin/media-new.php HTTP/1.1", host: > "192.168.11.96", > > > referrer: "http://192.168.11.96/wp-admin/media-new.php" > > > > > > Что не так делаю, подскажите пожалуйста. > > > > Добрый день! > > > > Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему > max > > body size. > > Бекенд, конечно, подкрутить надо. Но в данном случае, очевидно, > дело не в бекенде, т.к. приведённая ошибка в логах nginx'а > однозначно говорит о том, что срабатывает client_max_body_size в > nginx'е. > > Надо смотреть, что именно написано в конфиге, скорее всего - > редактируется не тот конфиг, или не тот server{} / location{} в > нём. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From endo.mulo на gmail.com Fri Nov 25 08:31:45 2016 From: endo.mulo на gmail.com (Dmitriy M.) Date: Fri, 25 Nov 2016 10:31:45 +0200 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler In-Reply-To: <2276684.pvFDZpfd01@vbart-laptop> References: <6791207.lFIfeuULy3@vbart-laptop> <2276684.pvFDZpfd01@vbart-laptop> Message-ID: 20 ноября 2016 г., 18:22 пользователь Валентин Бартенев написал: > On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote: >> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote: >> [..] >> > >> > К сожалению, это практически невозможно. Сервису необходимы >> > перечисленные при сборке модули, без них возможности проверки под >> > нагрузкой нет. Способа воспроизведения нет, они происходят >> > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных >> > клонированных сетапов). >> > >> > Могу дополнить, что эти же модули (набор модулей, но да >> > headers-more-nginx-module-84241e4 и libressl были обновлены) были >> > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода >> > крашей небыло, конфигурация nginx.conf существенно не менялась. >> > >> > Попробую собрать с предыдущими версиями модулей >> > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без >> > оптимизаций кода для дебаггинга. >> > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/ >> >> То, что модули раньше работали - абсолютно не показатель. Многие сторонние >> модули славятся тем, что лезут во внутренние структуры nginx, используя их >> не по назначению. Как результат, такие модули могут поломать nginx при любых >> изменениях в его внутренних механизмах. >> >> Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке >> тела запроса в модуле http/2. >> >> Бектрейс, который вы привели - не содержит какой-либо полезной информации >> для дебага. Ошибка, послужившая причиной падения, произошла в другом месте, >> на другой итерации цикла обработки событий. А то, что видно на бэктрейсе - >> лишь следствие. >> >> Можно попытаться получить debug-лог перед падением: >> http://nginx.org/ru/docs/debugging_log.html#memory >> >> Смотрите раздел про запись его в буфер в памяти. >> > [..] > > И в дополнение к предыдущему письму, а вы уверены, что у вас > nginx-upload-progress-module вообще с HTTP/2 корректно работает? > > Судя по тому же тикету на github, он и не должен: > https://github.com/masterzen/nginx-upload-progress-module/issues/45 > > Интересно также, что вы делаете с помощью headers-more-nginx-module, > что не получается сделать стандартными средствами nginx? > > -- > Валентин Бартенев Добрый день, Валентин прошу прощения за задержку в ответе - проверяли разные комбинации nginx. nginx-upload-progress-module и headers-more-nginx-module были у нас в конфигурации скорее исторически, необходимости в них, как оказалось, нет. Поэтому, создали конфигурацию без сторонних модулей , с одной простой функцией - приём SSL HTTP и проксирование: # nginx -V nginx version: nginx/1.10.2 built with LibreSSL 2.4.4 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_realip_module --with-http_stub_status_module --with-pcre --with-threads --with-http_ssl_module --with-http_v2_module --with-openssl=../libressl-2.4.4 --with-debug И nginx продолжает крашится (некоторые приватные данные были заменены на ХХХ): #0 ngx_http_v2_write_handler (wev=0x851458eb0) at src/http/v2/ngx_http_v2.c:444 444 wev = stream->request->connection->write; [New Thread 801c16000 (LWP 100649/)] (gdb) bt #0 ngx_http_v2_write_handler (wev=0x851458eb0) at src/http/v2/ngx_http_v2.c:444 #1 0x000000000048cb23 in ngx_kqueue_process_events (cycle=0x801de9050, timer=213, flags=1) at src/event/modules/ngx_kqueue_module.c:669 #2 0x000000000047b3fa in ngx_process_events_and_timers (cycle=0x801de9050) at src/event/ngx_event.c:242 #3 0x0000000000489b9a in ngx_worker_process_cycle (cycle=0x801de9050, data=0x1) at src/os/unix/ngx_process_cycle.c:753 #4 0x0000000000486cad in ngx_spawn_process (cycle=0x801de9050, proc=0x489a90 , data=0x1, name=0x6a6192 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198 #5 0x0000000000488890 in ngx_start_worker_processes (cycle=0x801de9050, n=8, type=-4) at src/os/unix/ngx_process_cycle.c:358 #6 0x0000000000488657 in ngx_master_process_cycle (cycle=0x801de9050) at src/os/unix/ngx_process_cycle.c:243 #7 0x0000000000447672 in main (argc=1, argv=0x7fffffffebb8) at src/core/nginx.c:367 Current language: auto; currently minimal (gdb) i locals rc = -2 q = (ngx_queue_t *) 0x85379ccb0 c = (ngx_connection_t *) 0x84a4c65b0 stream = (ngx_http_v2_stream_t *) 0x85379cc60 h2c = (ngx_http_v2_connection_t *) 0x85797c220 (gdb) p *q $1 = {prev = 0x0, next = 0x0} (gdb) p *c $2 = {data = 0x85797c220, read = 0x84f458eb0, write = 0x851458eb0, fd = 576, recv = 0x491af0 , send = 0x491db0 , recv_chain = 0x492240 , send_chain = 0x4923b0 , listening = 0x801de93d0, sent = 490296, log = 0x8541a9c60, pool = 0x8541a9c00, type = 1, sockaddr = 0x8541a9c50, socklen = 16, addr_text = {len = 13, data = 0x8541a9cb0 "46.133.156.37"}, proxy_protocol_addr = {len = 0, data = 0x0}, ssl = 0x8541a9d20, local_sockaddr = 0x801c99d28, local_socklen = 16, buffer = 0x0, queue = {prev = 0x0, next = 0x0}, number = 18898941, requests = 29, buffered = 1, log_error = 2, unexpected_eof = 1, timedout = 0, error = 0, destroyed = 0, idle = 0, reusable = 0, close = 0, shared = 0, sendfile = 0, sndlowat = 0, tcp_nodelay = 1, tcp_nopush = 0, need_last_buf = 0, sendfile_task = 0x0} (gdb) p stream $3 = (ngx_http_v2_stream_t *) 0x85379cc60 (gdb) p *stream $4 = {request = 0x85379c050, connection = 0x85797c220, node = 0x856bf0ef0, queued = 0, send_window = 6075904, recv_window = 65536, preread = 0x0, free_frames = 0x856c6af58, free_frame_headers = 0x0, free_bufs = 0x856c6aef8, queue = { prev = 0x0, next = 0x0}, cookies = 0x85379cd28, header_limit = 0, pool = 0x855eb4000, handled = 0, blocked = 0, exhausted = 0, in_closed = 1, out_closed = 1, rst_sent = 0, no_flow_control = 0, skip_data = 0} (gdb) p h2c $5 = (ngx_http_v2_connection_t *) 0x85797c220 (gdb) p *h2c $6 = {connection = 0x84a4c65b0, http_connection = 0x8541a9cc0, processing = 1, send_window = 15146099, recv_window = 2147483003, init_window = 6291456, frame_size = 16384, waiting = {prev = 0x85797c258, next = 0x85797c258}, state = { sid = 57, length = 0, padding = 0, flags = 37, incomplete = 0, keep_pool = 0, parse_name = 0, parse_value = 0, index = 0, header = {name = {len = 10, data = 0x85798a56e "user-agent"}, value = {len = 137, data = 0x85798a579 "Mozilla/5.0 (Linux; Android 6.0.1; Redmi 3S Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.76 Mobile Safari/537.36"}}, header_limit = 15004, field_state = 0 '\0', field_start = 0x8543f0c6f "/XXXXXX/XXX/XXXXXXXXXXXXXXXXXXXX/X/XXX%XXX%20XXXXXXXXXXXXXX", field_end = 0x8543f0cac "", field_rest = 0, pool = 0x0, stream = 0x0, buffer = 0x85797c2e0 "", buffer_used = 0, handler = 0x500660 }, hpack = {entries = 0x85748f600, added = 46, deleted = 0, reused = 0, allocated = 64, size = 4096, free = 394, storage = 0x853d07000 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXtext/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8accept-encodinggzip, deflate, sdchaccept-languageXX-XX,XX;q=0.8,XX-XX;q=0.6,en;q=0.4cookieXXXXXXX="..., pos = 0x853d078b6 "xscPF_QgWNtNyk0JXu2w3UcYDrgQv0fiMVXifJGNlWS0j9m37ixTHc4kFIPs8hPiLo4qEbwbg-wu88I=; XXXXXXXXX=9d4aebb99c97d1cfd0e1685943776d38225cd062; XXXX=XXXX; __utmb=69692428.21.10.1480053397; __utmc=69692428"}, pool = 0x8576fd000, free_frames = 0x0, free_fake_connections = 0x0, streams_index = 0x856452220, last_out = 0x85487f648, posted = {prev = 0x85797c370, next = 0x85797c370}, dependencies = {prev = 0x859333a38, next = 0x856452338}, closed = {prev = 0x858a64390, next = 0x856452358}, last_sid = 57, closed_nodes = 28, settings_ack = 1, blocked = 1} (gdb) fr #0 ngx_http_v2_write_handler (wev=0x851458eb0) at src/http/v2/ngx_http_v2.c:444 444 wev = stream->request->connection->write; (gdb) l 439 stream->handled = 0; 440 441 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, c->log, 0, 442 "run http2 stream %ui", stream->node->id); 443 444 wev = stream->request->connection->write; 445 446 wev->active = 0; 447 wev->ready = 1; 448 (gdb) p stream->request->connection $7 = (ngx_connection_t *) 0xa (gdb) p stream->request $8 = (ngx_http_request_t *) 0x85379c050 (gdb) p *stream->request $9 = {signature = 4226631568, connection = 0xa, ctx = 0x856a11f28, main_conf = 0x6, srv_conf = 0x856a11f33, loc_conf = 0x856a11f3a, read_event_handler = 0x4861c3f653476b3b, write_event_handler = 0xd, cache = 0x856a11f44, upstream = 0x5, upstream_states = 0x856a11f52, pool = 0x856a11f58, header_in = 0x85379cc00, headers_in = {headers = {last = 0x85379c0c0, part = {elts = 0x8536a2020, nelts = 8, next = 0x0}, size = 48, nalloc = 20, pool = 0x85379c000}, host = 0x8536a2020, connection = 0x0, if_modified_since = 0x0, if_unmodified_since = 0x0, if_match = 0x0, if_none_match = 0x0, user_agent = 0x8536a2140, referer = 0x8536a20e0, content_length = 0x0, content_type = 0x0, range = 0x0, if_range = 0x0, transfer_encoding = 0x0, expect = 0x0, upgrade = 0x0, accept_encoding = 0x8536a2080, via = 0x0, authorization = 0x0, keep_alive = 0x0, x_forwarded_for = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x85379c680}, x_real_ip = 0x0, user = {len = 0, data = 0x85379c1b8 ""}, passwd = {len = 0, data = 0x0}, cookies = {elts = 0x85379c6b0, nelts = 35760227744, size = 1, nalloc = 35807675712, pool = 0x8564e6540}, server = { len = 0, data = 0x50000000c
}, content_length_n = 164, keep_alive_n = 2380, connection_type = 1, chunked = 1, msie = 0, msie6 = 0, opera = 1, gecko = 1, chrome = 1, safari = 0, konqueror = 0}, headers_out = {headers = {last = 0xf7370b6c, part = {elts = 0x0, nelts = 0, next = 0x94c}, size = 35865916482, nalloc = 0, pool = 0x4d3}, status = 0, status_line = {len = 0, data = 0x4ed2d0 "UH\211ЕH\203Л@H\211}П\211uЛ\211UХH\213}ПH\211}Ю\213UЛ\017╞UХ\211р\211вH\211}пH\213}пH\201ГЪ\001"}, server = 0x4ed470, date = 0x85379c1a0, content_length = 0x1, content_encoding = 0x1, location = 0x0, refresh = 0x853d2c050, last_modified = 0x61e75563aa847688, content_range = 0x696a1394be61c396, accept_ranges = 0xb81ca0b80004753f, www_authenticate = 0x5fdf68311536ee06, expires = 0x3d260d62d0751d9a, etag = 0xb41a96a0711f744c, override_charset = 0x2d980a62c749a8fd, content_type_len = 5361711866659580748, content_type = {len = 16111286140954451668, data = 0xba9f34a5094abf3d
}, charset = {len = 8578051269243699330, data = 0x2a83006fb498ca02
}, content_type_lowcase = 0xccdbf2c7e48d3747
, content_type_hash = 11475120440503177658, cache_control = { elts = 0x965161cd9a2f8500, nelts = 9138599854249686236, size = 968336868888348906, nalloc = 9872101289212144860, pool = 0x874dea215639c920}, content_length_n = -9095832714587370333, content_offset = -8646842013157968240, date_time = -39384271865661966, last_modified_time = -8430598664003936891}, request_body = 0x87a8c54a6a49ea21, lingering_time = 48371482963596688, start_sec = 1480053841, start_msec = 396, method = 2, http_version = 2000, request_line = {len = 0, data = 0x85379ce90 "GET /XXXXXX/XXX/XXXXXXXXXXXXXXXXXXXX/X/XXX%XXX%20XXXXXX%20XX%20XXXXXXXXXX HTTP/2.0"}, uri = {len = 63, data = 0x85379cce0 "/XXXXXX/XXX/XXXXXXXXXXXXXXXXXXXX/X/XXX XXX XXXXXX XX XXXXXXXXXX"}, args = {len = 0, data = 0x0}, exten = {len = 3, data = 0x85379cd1c "doc"}, unparsed_uri = {len = 71, data = 0x0}, method_name = { len = 35813137368, data = 0x85379c6a0 "╠еyS\b"}, http_protocol = {len = 5147808, data = 0x853d2cc60 "PюрS\b"}, out = 0xa, main = 0x85379c052, parent = 0x856a11ff9, postponed = 0x856a11ff9, post_subrequest = 0x0, posted_requests = 0x0, phase_handler = 35813138416, content_handler = 0x856a11ff9, access_code = 9714584, variables = 0x0, ncaptures = 0, captures = 0x1, captures_data = 0x85379c36f "", limit_rate = 35760227183, limit_rate_after = 0, header_size = 0, request_length = 35760226984, err_status = 35760227183, http_connection = 0x0, stream = 0x0, log_handler = 0, cleanup = 0x1, count = 30112, subrequests = 78, blocked = 0, aio = 0, http_state = 0, complex_uri = 0, quoted_uri = 0, plus_in_uri = 0, space_in_uri = 0, invalid_header = 0, add_uri_to_alias = 0, valid_location = 0, valid_unparsed_uri = 0, uri_changed = 0, uri_changes = 0, request_body_in_single_buf = 0, request_body_in_file_only = 0, request_body_in_persistent_file = 0, request_body_in_clean_file = 0, request_body_file_group_access = 0, request_body_file_log_level = 0, request_body_no_buffering = 0, subrequest_in_memory = 0, waited = 0, cached = 0, gzip_tested = 0, gzip_ok = 0, gzip_vary = 0, proxy = 0, bypass_cache = 0, no_cache = 0, limit_conn_set = 0, limit_req_set = 1, pipeline = 1, chunked = 0, header_only = 0, keepalive = 0, lingering_close = 1, discard_body = 1, reading_body = 0, internal = 0, error_page = 1, filter_finalize = 1, post_action = 0, request_complete = 1, request_output = 0, header_sent = 0, expect_tested = 1, root_tested = 0, done = 1, logged = 1, buffered = 3, main_filter_need_in_memory = 1, filter_need_in_memory = 0, filter_need_temporary = 1, allow_ranges = 0, subrequest_ranges = 0, single_range = 0, disable_not_modified = 0, stat_reading = 1, stat_writing = 0, state = 35813137240, header_hash = 0, lowcase_index = 0, lowcase_header = 0x85379c4d8 "", header_name_start = 0x947020 "\022", header_name_end = 0x0, header_start = 0x0, header_end = 0x22
, uri_start = 0x0, uri_end = 0x0, uri_ext = 0x0, args_start = 0x0, request_start = 0x4
, request_end = 0x0, method_end = 0x0, schema_start = 0x200
, schema_end = 0x853d2c000 "", host_start = 0x0, host_end = 0x20
, port_start = 0x10000
, port_end = 0x93dd40 "*", http_minor = 21744, http_major = 79} (gdb) Core файл и исполнительный файл есть, так же записан debug.log (из корки, через кольцевой буфер в памяти), если какие-то данных из них понадобятся - предоставим. Спасибо! From nginx-forum на forum.nginx.org Fri Nov 25 08:55:50 2016 From: nginx-forum на forum.nginx.org (IvanMiller) Date: Fri, 25 Nov 2016 03:55:50 -0500 Subject: =?UTF-8?B?0J7Rh9C10YDQtdC00L3QvtC5INCy0L7Qv9GA0L7RgSBuZ2lueCtwaHA=?= Message-ID: Всем добрый день. Вот в очередной раз принялся "конфигурировать". Обратился к офф. документации, там четко сказанно The problem section usually looks like this: location ~* \.php$ { fastcgi_pass backend; # [...] } Хорошо, плохо так плохо, а хорошо вот так location ~* (file_a|file_b|file_c)\.php$ { fastcgi_pass backend; # [...] } Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не попадают, Nginx их начинает тупо выдавать без обработки. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271168,271168#msg-271168 From endo.mulo на gmail.com Fri Nov 25 08:56:45 2016 From: endo.mulo на gmail.com (Dmitriy M.) Date: Fri, 25 Nov 2016 10:56:45 +0200 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler In-Reply-To: References: <6791207.lFIfeuULy3@vbart-laptop> <2276684.pvFDZpfd01@vbart-laptop> Message-ID: 25 ноября 2016 г., 10:31 пользователь Dmitriy M. написал: > 20 ноября 2016 г., 18:22 пользователь Валентин Бартенев > написал: >> On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote: >>> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote: >>> [..] >>> > >>> > К сожалению, это практически невозможно. Сервису необходимы >>> > перечисленные при сборке модули, без них возможности проверки под >>> > нагрузкой нет. Способа воспроизведения нет, они происходят >>> > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных >>> > клонированных сетапов). >>> > >>> > Могу дополнить, что эти же модули (набор модулей, но да >>> > headers-more-nginx-module-84241e4 и libressl были обновлены) были >>> > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода >>> > крашей небыло, конфигурация nginx.conf существенно не менялась. >>> > >>> > Попробую собрать с предыдущими версиями модулей >>> > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без >>> > оптимизаций кода для дебаггинга. >>> > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/ >>> >>> То, что модули раньше работали - абсолютно не показатель. Многие сторонние >>> модули славятся тем, что лезут во внутренние структуры nginx, используя их >>> не по назначению. Как результат, такие модули могут поломать nginx при любых >>> изменениях в его внутренних механизмах. >>> >>> Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке >>> тела запроса в модуле http/2. >>> >>> Бектрейс, который вы привели - не содержит какой-либо полезной информации >>> для дебага. Ошибка, послужившая причиной падения, произошла в другом месте, >>> на другой итерации цикла обработки событий. А то, что видно на бэктрейсе - >>> лишь следствие. >>> >>> Можно попытаться получить debug-лог перед падением: >>> http://nginx.org/ru/docs/debugging_log.html#memory >>> >>> Смотрите раздел про запись его в буфер в памяти. >>> >> [..] >> >> И в дополнение к предыдущему письму, а вы уверены, что у вас >> nginx-upload-progress-module вообще с HTTP/2 корректно работает? >> >> Судя по тому же тикету на github, он и не должен: >> https://github.com/masterzen/nginx-upload-progress-module/issues/45 >> >> Интересно также, что вы делаете с помощью headers-more-nginx-module, >> что не получается сделать стандартными средствами nginx? >> >> -- >> Валентин Бартенев > > Добрый день, Валентин > и вдогонку прошлому письму, core номер два, тоже на сетапе без сторонних модулей nginx -V nginx version: nginx/1.10.2 built with LibreSSL 2.4.4 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_realip_module --with-http_stub_status_module --with-pcre --with-threads --with-http_ssl_module --with-http_v2_module --with-openssl=./libressl-2.4.4 --with-debug #0 0x00000000004fd0da in ngx_http_v2_write_handler (wev=0x85144f380) at src/http/v2/ngx_http_v2.c:435 435 ngx_queue_remove(q); [New Thread 801c16000 (LWP 100771/)] (gdb) i locals rc = -2 q = (ngx_queue_t *) 0x85d2bdcb0 c = (ngx_connection_t *) 0x84a4b0b80 stream = (ngx_http_v2_stream_t *) 0x85144f380 h2c = (ngx_http_v2_connection_t *) 0x853bf7a20 Current language: auto; currently minimal (gdb) p q $1 = (ngx_queue_t *) 0x85d2bdcb0 (gdb) p *q $2 = {prev = 0x3938386138313962, next = 0x85e7d7cb0} (gdb) p c $3 = (ngx_connection_t *) 0x84a4b0b80 (gdb) p *c $4 = {data = 0x853bf7a20, read = 0x84f44f380, write = 0x85144f380, fd = 6509, recv = 0x491af0 , send = 0x491db0 , recv_chain = 0x492240 , send_chain = 0x4923b0 , listening = 0x801de93d0, sent = 2319718, log = 0x8562a2460, pool = 0x8562a2400, type = 1, sockaddr = 0x8562a2450, socklen = 16, addr_text = {len = 12, data = 0x8562a24b0 "92.60.186.11\b"}, proxy_protocol_addr = {len = 0, data = 0x0}, ssl = 0x8562a2520, local_sockaddr = 0x801c99d28, local_socklen = 16, buffer = 0x0, queue = {prev = 0x0, next = 0x0}, number = 25442656, requests = 202, buffered = 1, log_error = 2, unexpected_eof = 1, timedout = 0, error = 0, destroyed = 0, idle = 0, reusable = 0, close = 0, shared = 0, sendfile = 0, sndlowat = 0, tcp_nodelay = 1, tcp_nopush = 0, need_last_buf = 0, sendfile_task = 0x0} (gdb) fr #0 0x00000000004fd0da in ngx_http_v2_write_handler (wev=0x85144f380) at src/http/v2/ngx_http_v2.c:435 435 ngx_queue_remove(q); (gdb) l 430 } 431 432 while (!ngx_queue_empty(&h2c->posted)) { 433 q = ngx_queue_head(&h2c->posted); 434 435 ngx_queue_remove(q); 436 437 stream = ngx_queue_data(q, ngx_http_v2_stream_t, queue); 438 439 stream->handled = 0; (gdb) p h2c $5 = (ngx_http_v2_connection_t *) 0x853bf7a20 (gdb) p *h2c $6 = {connection = 0x84a4b0b80, http_connection = 0x8562a24c0, processing = 3, send_window = 10055604, recv_window = 2147445557, init_window = 131072, frame_size = 16384, waiting = {prev = 0x853bf7a58, next = 0x853bf7a58}, state = { sid = 415, length = 4, padding = 0, flags = 0, incomplete = 0, keep_pool = 0, parse_name = 0, parse_value = 0, index = 0, header = {name = {len = 25, data = 0x85df80ccb "upgrade-insecure-requests"}, value = {len = 1, data = 0x85dd4e7fb "1"}}, header_limit = 14373, field_state = 0 '\0', field_start = 0x85dd4e7fb "1", field_end = 0x85dd4e7fc "", field_rest = 0, pool = 0x0, stream = 0x0, buffer = 0x853bf7ae0 "", buffer_used = 0, handler = 0x500660 }, hpack = {entries = 0x85eb43e00, added = 360, deleted = 311, reused = 307, allocated = 64, size = 4096, free = 10, storage = 0x85abfc000 "etracknew=1442820681065738.1480063024.205cookieloginhesh=68224ef0f0f562b069105a5a84d3bf43bb4f4beacookietracknew=1442820681065738.1480063033.205cookie__utmb=69692428.27.9.1480062955667refererhttps://ma"..., pos = 0x85abfc30f "(organic)|utmcmd=organic|utmctr=ukrcookie__utmv=183793058.|1=Users=Registered=1^2=Gender=f=1^3=Age=41=1^4=ID=40d191c1723959071990c7556fae5c92=1cookieuid=1CpM/FfSfoQYenDjBEOlAg==cookietrackss=147496897"...}, pool = 0x860d2b000, free_frames = 0x860d2b490, free_fake_connections = 0x0, streams_index = 0x853d22820, last_out = 0x857066188, posted = {prev = 0x85e7d7cb0, next = 0x85d2bdcb0}, dependencies = {prev = 0x8575e6bb0, next = 0x853d229a0}, closed = {prev = 0x855bffb80, next = 0x858b1f900}, last_sid = 415, closed_nodes = 31, settings_ack = 1, blocked = 1} (gdb) p h2c->posted $7 = {prev = 0x85e7d7cb0, next = 0x85d2bdcb0} (gdb) p h2c->posted.next $8 = (ngx_queue_t *) 0x85d2bdcb0 (gdb) p *h2c->posted.next $9 = {prev = 0x3938386138313962, next = 0x85e7d7cb0} core файл и исполнительный тоже есть, debug log был включен, если нужны дополнительные данные - попробуем извлечь. From nginx на mva.name Fri Nov 25 09:20:30 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 25 Nov 2016 12:20:30 +0300 Subject: =?UTF-8?B?UmU6INCe0YfQtdGA0LXQtNC90L7QuSDQstC+0L/RgNC+0YEgbmdpbngrcGhw?= In-Reply-To: References: Message-ID: <1543918.cF8ZFldVUj@note> > > Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не > попадают, Nginx их начинает тупо выдавать без обработки. У меня всё прекрасно работает с location ~ \.php$ { fastcgi_pass $upstream_name; fastcgi_index index.php; include fastcgi.conf; } (просьба обратить внимание на отсутствие * после ~) From nginx-forum на forum.nginx.org Fri Nov 25 09:49:17 2016 From: nginx-forum на forum.nginx.org (IvanMiller) Date: Fri, 25 Nov 2016 04:49:17 -0500 Subject: =?UTF-8?B?UmU6INCe0YfQtdGA0LXQtNC90L7QuSDQstC+0L/RgNC+0YEgbmdpbngrcGhw?= In-Reply-To: <1543918.cF8ZFldVUj@note> References: <1543918.cF8ZFldVUj@note> Message-ID: Да никто и не говорит, что оно работать не будет, просто не очень понятно, о чем в документации идет речь и как дальше настроить что бы nginx ны выдавал php файлы. Вот, она, документация https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271168,271171#msg-271171 From andrey на kopeyko.ru Fri Nov 25 10:19:29 2016 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Fri, 25 Nov 2016 13:19:29 +0300 (MSK) Subject: =?UTF-8?B?UmU6INCe0YfQtdGA0LXQtNC90L7QuSDQstC+0L/RgNC+0YEgbmdpbngrcGhw?= In-Reply-To: References: Message-ID: Добрый день, Ivan! On Fri, 25 Nov 2016, IvanMiller wrote: > Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не > попадают, Nginx их начинает тупо выдавать без обработки. Тут есть 3 варианта - расширить маску, чтобы и они попадали - сделать дефолтный location, в котором отвечать 404 - удалить лишнее из DocumentRoot \ с сервера У каждого - есть и плюсы и минусы. -- Best regards, Andrey Kopeyko From chipitsine на gmail.com Fri Nov 25 11:55:45 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 25 Nov 2016 16:55:45 +0500 Subject: =?UTF-8?B?UmU6INCe0YfQtdGA0LXQtNC90L7QuSDQstC+0L/RgNC+0YEgbmdpbngrcGhw?= In-Reply-To: References: Message-ID: 25 ноября 2016 г., 13:55 пользователь IvanMiller < nginx-forum на forum.nginx.org> написал: > Всем добрый день. > Вот в очередной раз принялся "конфигурировать". Обратился к офф. > документации, там четко сказанно > > The problem section usually looks like this: > > location ~* \.php$ { > fastcgi_pass backend; > # [...] > } > > Хорошо, плохо так плохо, а хорошо вот так > > location ~* (file_a|file_b|file_c)\.php$ { > fastcgi_pass backend; > # [...] > } > > Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не > попадают, Nginx их начинает тупо выдавать без обработки. > через try_files можно сделать условие "если есть файл - отдать его, если нет, маршрутизируем в @php > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,271168,271168#msg-271168 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Fri Nov 25 15:05:30 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 25 Nov 2016 18:05:30 +0300 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler In-Reply-To: References: Message-ID: <3048780.qxrlIZU1zu@vbart-workstation> On Friday 25 November 2016 10:56:45 Dmitriy M. wrote: > 25 ноября 2016 г., 10:31 пользователь Dmitriy M. написал: > > 20 ноября 2016 г., 18:22 пользователь Валентин Бартенев > > написал: > >> On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote: > >>> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote: > >>> [..] > >>> > > >>> > К сожалению, это практически невозможно. Сервису необходимы > >>> > перечисленные при сборке модули, без них возможности проверки под > >>> > нагрузкой нет. Способа воспроизведения нет, они происходят > >>> > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных > >>> > клонированных сетапов). > >>> > > >>> > Могу дополнить, что эти же модули (набор модулей, но да > >>> > headers-more-nginx-module-84241e4 и libressl были обновлены) были > >>> > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода > >>> > крашей небыло, конфигурация nginx.conf существенно не менялась. > >>> > > >>> > Попробую собрать с предыдущими версиями модулей > >>> > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без > >>> > оптимизаций кода для дебаггинга. > >>> > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/ > >>> > >>> То, что модули раньше работали - абсолютно не показатель. Многие сторонние > >>> модули славятся тем, что лезут во внутренние структуры nginx, используя их > >>> не по назначению. Как результат, такие модули могут поломать nginx при любых > >>> изменениях в его внутренних механизмах. > >>> > >>> Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке > >>> тела запроса в модуле http/2. > >>> > >>> Бектрейс, который вы привели - не содержит какой-либо полезной информации > >>> для дебага. Ошибка, послужившая причиной падения, произошла в другом месте, > >>> на другой итерации цикла обработки событий. А то, что видно на бэктрейсе - > >>> лишь следствие. > >>> > >>> Можно попытаться получить debug-лог перед падением: > >>> http://nginx.org/ru/docs/debugging_log.html#memory > >>> > >>> Смотрите раздел про запись его в буфер в памяти. > >>> > >> [..] > >> > >> И в дополнение к предыдущему письму, а вы уверены, что у вас > >> nginx-upload-progress-module вообще с HTTP/2 корректно работает? > >> > >> Судя по тому же тикету на github, он и не должен: > >> https://github.com/masterzen/nginx-upload-progress-module/issues/45 > >> > >> Интересно также, что вы делаете с помощью headers-more-nginx-module, > >> что не получается сделать стандартными средствами nginx? > >> > >> -- > >> Валентин Бартенев > > > > Добрый день, Валентин > > > > и вдогонку прошлому письму, core номер два, тоже на сетапе без сторонних модулей > nginx -V > nginx version: nginx/1.10.2 > built with LibreSSL 2.4.4 > TLS SNI support enabled > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt' > --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx/error.log --user=www --group=www > --modules-path=/usr/local/libexec/nginx > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx/access.log --with-http_realip_module > --with-http_stub_status_module --with-pcre --with-threads > --with-http_ssl_module --with-http_v2_module > --with-openssl=./libressl-2.4.4 --with-debug > > > #0 0x00000000004fd0da in ngx_http_v2_write_handler (wev=0x85144f380) > at src/http/v2/ngx_http_v2.c:435 > 435 ngx_queue_remove(q); > [New Thread 801c16000 (LWP 100771/)] > (gdb) i locals > rc = -2 > q = (ngx_queue_t *) 0x85d2bdcb0 > c = (ngx_connection_t *) 0x84a4b0b80 > stream = (ngx_http_v2_stream_t *) 0x85144f380 > h2c = (ngx_http_v2_connection_t *) 0x853bf7a20 > Current language: auto; currently minimal > (gdb) p q > $1 = (ngx_queue_t *) 0x85d2bdcb0 > (gdb) p *q > $2 = {prev = 0x3938386138313962, next = 0x85e7d7cb0} > (gdb) p c > $3 = (ngx_connection_t *) 0x84a4b0b80 > (gdb) p *c > $4 = {data = 0x853bf7a20, read = 0x84f44f380, write = 0x85144f380, fd > = 6509, recv = 0x491af0 , send = 0x491db0 > , recv_chain = 0x492240 , > send_chain = 0x4923b0 , > listening = 0x801de93d0, sent = 2319718, log = 0x8562a2460, pool = > 0x8562a2400, type = 1, sockaddr = 0x8562a2450, socklen = 16, addr_text > = {len = 12, data = 0x8562a24b0 "92.60.186.11\b"}, proxy_protocol_addr > = {len = 0, data = 0x0}, > ssl = 0x8562a2520, local_sockaddr = 0x801c99d28, local_socklen = 16, > buffer = 0x0, queue = {prev = 0x0, next = 0x0}, number = 25442656, > requests = 202, buffered = 1, log_error = 2, unexpected_eof = 1, > timedout = 0, error = 0, > destroyed = 0, idle = 0, reusable = 0, close = 0, shared = 0, > sendfile = 0, sndlowat = 0, tcp_nodelay = 1, tcp_nopush = 0, > need_last_buf = 0, sendfile_task = 0x0} > (gdb) fr > #0 0x00000000004fd0da in ngx_http_v2_write_handler (wev=0x85144f380) > at src/http/v2/ngx_http_v2.c:435 > 435 ngx_queue_remove(q); > (gdb) l > 430 } > 431 > 432 while (!ngx_queue_empty(&h2c->posted)) { > 433 q = ngx_queue_head(&h2c->posted); > 434 > 435 ngx_queue_remove(q); > 436 > 437 stream = ngx_queue_data(q, ngx_http_v2_stream_t, queue); > 438 > 439 stream->handled = 0; > (gdb) p h2c > $5 = (ngx_http_v2_connection_t *) 0x853bf7a20 > (gdb) p *h2c > $6 = {connection = 0x84a4b0b80, http_connection = 0x8562a24c0, > processing = 3, send_window = 10055604, recv_window = 2147445557, > init_window = 131072, frame_size = 16384, waiting = {prev = > 0x853bf7a58, next = 0x853bf7a58}, state = { > sid = 415, length = 4, padding = 0, flags = 0, incomplete = 0, > keep_pool = 0, parse_name = 0, parse_value = 0, index = 0, header = > {name = {len = 25, data = 0x85df80ccb "upgrade-insecure-requests"}, > value = {len = 1, > data = 0x85dd4e7fb "1"}}, header_limit = 14373, field_state = > 0 '\0', field_start = 0x85dd4e7fb "1", field_end = 0x85dd4e7fc "", > field_rest = 0, pool = 0x0, stream = 0x0, buffer = 0x853bf7ae0 "", > buffer_used = 0, > handler = 0x500660 }, hpack = {entries = > 0x85eb43e00, added = 360, deleted = 311, reused = 307, allocated = 64, > size = 4096, free = 10, > storage = 0x85abfc000 > "etracknew=1442820681065738.1480063024.205cookieloginhesh=68224ef0f0f562b069105a5a84d3bf43bb4f4beacookietracknew=1442820681065738.1480063033.205cookie__utmb=69692428.27.9.1480062955667refererhttps://ma"..., > pos = 0x85abfc30f > "(organic)|utmcmd=organic|utmctr=ukrcookie__utmv=183793058.|1=Users=Registered=1^2=Gender=f=1^3=Age=41=1^4=ID=40d191c1723959071990c7556fae5c92=1cookieuid=1CpM/FfSfoQYenDjBEOlAg==cookietrackss=147496897"...}, > pool = 0x860d2b000, free_frames = 0x860d2b490, free_fake_connections > = 0x0, streams_index = 0x853d22820, last_out = 0x857066188, posted = > {prev = 0x85e7d7cb0, next = 0x85d2bdcb0}, dependencies = {prev = > 0x8575e6bb0, > next = 0x853d229a0}, closed = {prev = 0x855bffb80, next = > 0x858b1f900}, last_sid = 415, closed_nodes = 31, settings_ack = 1, > blocked = 1} > (gdb) p h2c->posted > $7 = {prev = 0x85e7d7cb0, next = 0x85d2bdcb0} > (gdb) p h2c->posted.next > $8 = (ngx_queue_t *) 0x85d2bdcb0 > (gdb) p *h2c->posted.next > $9 = {prev = 0x3938386138313962, next = 0x85e7d7cb0} > > > core файл и исполнительный тоже есть, debug log был включен, если > нужны дополнительные данные - попробуем извлечь. Дебаг-лог и хотелось бы увидеть. Поскольку ошибка происходит на самом деле не там, где оно падает, то нужен лог событий, а бэктрейс просто не содержит необходимой информации. -- Валентин Бартенев From vbart на nginx.com Fri Nov 25 15:09:49 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 25 Nov 2016 18:09:49 +0300 Subject: nginx/1.10.2 crashes in ngx_http_v2_write_handler In-Reply-To: <3048780.qxrlIZU1zu@vbart-workstation> References: <3048780.qxrlIZU1zu@vbart-workstation> Message-ID: <1518264.KzH0jPjTjK@vbart-workstation> On Friday 25 November 2016 18:05:30 Валентин Бартенев wrote: > On Friday 25 November 2016 10:56:45 Dmitriy M. wrote: > > 25 ноября 2016 г., 10:31 пользователь Dmitriy M. написал: > > > 20 ноября 2016 г., 18:22 пользователь Валентин Бартенев > > > написал: > > >> On Sunday 20 November 2016 19:17:12 Валентин Бартенев wrote: > > >>> On Sunday 20 November 2016 17:58:45 Dmitriy M. wrote: > > >>> [..] > > >>> > > > >>> > К сожалению, это практически невозможно. Сервису необходимы > > >>> > перечисленные при сборке модули, без них возможности проверки под > > >>> > нагрузкой нет. Способа воспроизведения нет, они происходят > > >>> > неконтролируемо и очень редко (1-2 краша в сутки на ряде разных > > >>> > клонированных сетапов). > > >>> > > > >>> > Могу дополнить, что эти же модули (набор модулей, но да > > >>> > headers-more-nginx-module-84241e4 и libressl были обновлены) были > > >>> > вкомпилены в nginx-1.9.12 , с которым на протяжении более полугода > > >>> > крашей небыло, конфигурация nginx.conf существенно не менялась. > > >>> > > > >>> > Попробую собрать с предыдущими версиями модулей > > >>> > (openresty-headers-more-nginx-module-0c6e05d и libressl-2.3.6) и без > > >>> > оптимизаций кода для дебаггинга. > > >>> > https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/ > > >>> > > >>> То, что модули раньше работали - абсолютно не показатель. Многие сторонние > > >>> модули славятся тем, что лезут во внутренние структуры nginx, используя их > > >>> не по назначению. Как результат, такие модули могут поломать nginx при любых > > >>> изменениях в его внутренних механизмах. > > >>> > > >>> Между версией 1.10.1 и 1.10.2 произошли существенные изменения в обработке > > >>> тела запроса в модуле http/2. > > >>> > > >>> Бектрейс, который вы привели - не содержит какой-либо полезной информации > > >>> для дебага. Ошибка, послужившая причиной падения, произошла в другом месте, > > >>> на другой итерации цикла обработки событий. А то, что видно на бэктрейсе - > > >>> лишь следствие. > > >>> > > >>> Можно попытаться получить debug-лог перед падением: > > >>> http://nginx.org/ru/docs/debugging_log.html#memory > > >>> > > >>> Смотрите раздел про запись его в буфер в памяти. > > >>> > > >> [..] > > >> > > >> И в дополнение к предыдущему письму, а вы уверены, что у вас > > >> nginx-upload-progress-module вообще с HTTP/2 корректно работает? > > >> > > >> Судя по тому же тикету на github, он и не должен: > > >> https://github.com/masterzen/nginx-upload-progress-module/issues/45 > > >> > > >> Интересно также, что вы делаете с помощью headers-more-nginx-module, > > >> что не получается сделать стандартными средствами nginx? > > >> > > >> -- > > >> Валентин Бартенев > > > > > > Добрый день, Валентин > > > > > > > и вдогонку прошлому письму, core номер два, тоже на сетапе без сторонних модулей > > nginx -V > > nginx version: nginx/1.10.2 > > built with LibreSSL 2.4.4 > > TLS SNI support enabled > > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > > /usr/local/include' --with-ld-opt='-L /usr/local/lib -lrt' > > --conf-path=/usr/local/etc/nginx/nginx.conf > > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > > --error-log-path=/var/log/nginx/error.log --user=www --group=www > > --modules-path=/usr/local/libexec/nginx > > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > > --http-log-path=/var/log/nginx/access.log --with-http_realip_module > > --with-http_stub_status_module --with-pcre --with-threads > > --with-http_ssl_module --with-http_v2_module > > --with-openssl=./libressl-2.4.4 --with-debug > > > > > > #0 0x00000000004fd0da in ngx_http_v2_write_handler (wev=0x85144f380) > > at src/http/v2/ngx_http_v2.c:435 > > 435 ngx_queue_remove(q); > > [New Thread 801c16000 (LWP 100771/)] > > (gdb) i locals > > rc = -2 > > q = (ngx_queue_t *) 0x85d2bdcb0 > > c = (ngx_connection_t *) 0x84a4b0b80 > > stream = (ngx_http_v2_stream_t *) 0x85144f380 > > h2c = (ngx_http_v2_connection_t *) 0x853bf7a20 > > Current language: auto; currently minimal > > (gdb) p q > > $1 = (ngx_queue_t *) 0x85d2bdcb0 > > (gdb) p *q > > $2 = {prev = 0x3938386138313962, next = 0x85e7d7cb0} > > (gdb) p c > > $3 = (ngx_connection_t *) 0x84a4b0b80 > > (gdb) p *c > > $4 = {data = 0x853bf7a20, read = 0x84f44f380, write = 0x85144f380, fd > > = 6509, recv = 0x491af0 , send = 0x491db0 > > , recv_chain = 0x492240 , > > send_chain = 0x4923b0 , > > listening = 0x801de93d0, sent = 2319718, log = 0x8562a2460, pool = > > 0x8562a2400, type = 1, sockaddr = 0x8562a2450, socklen = 16, addr_text > > = {len = 12, data = 0x8562a24b0 "92.60.186.11\b"}, proxy_protocol_addr > > = {len = 0, data = 0x0}, > > ssl = 0x8562a2520, local_sockaddr = 0x801c99d28, local_socklen = 16, > > buffer = 0x0, queue = {prev = 0x0, next = 0x0}, number = 25442656, > > requests = 202, buffered = 1, log_error = 2, unexpected_eof = 1, > > timedout = 0, error = 0, > > destroyed = 0, idle = 0, reusable = 0, close = 0, shared = 0, > > sendfile = 0, sndlowat = 0, tcp_nodelay = 1, tcp_nopush = 0, > > need_last_buf = 0, sendfile_task = 0x0} > > (gdb) fr > > #0 0x00000000004fd0da in ngx_http_v2_write_handler (wev=0x85144f380) > > at src/http/v2/ngx_http_v2.c:435 > > 435 ngx_queue_remove(q); > > (gdb) l > > 430 } > > 431 > > 432 while (!ngx_queue_empty(&h2c->posted)) { > > 433 q = ngx_queue_head(&h2c->posted); > > 434 > > 435 ngx_queue_remove(q); > > 436 > > 437 stream = ngx_queue_data(q, ngx_http_v2_stream_t, queue); > > 438 > > 439 stream->handled = 0; > > (gdb) p h2c > > $5 = (ngx_http_v2_connection_t *) 0x853bf7a20 > > (gdb) p *h2c > > $6 = {connection = 0x84a4b0b80, http_connection = 0x8562a24c0, > > processing = 3, send_window = 10055604, recv_window = 2147445557, > > init_window = 131072, frame_size = 16384, waiting = {prev = > > 0x853bf7a58, next = 0x853bf7a58}, state = { > > sid = 415, length = 4, padding = 0, flags = 0, incomplete = 0, > > keep_pool = 0, parse_name = 0, parse_value = 0, index = 0, header = > > {name = {len = 25, data = 0x85df80ccb "upgrade-insecure-requests"}, > > value = {len = 1, > > data = 0x85dd4e7fb "1"}}, header_limit = 14373, field_state = > > 0 '\0', field_start = 0x85dd4e7fb "1", field_end = 0x85dd4e7fc "", > > field_rest = 0, pool = 0x0, stream = 0x0, buffer = 0x853bf7ae0 "", > > buffer_used = 0, > > handler = 0x500660 }, hpack = {entries = > > 0x85eb43e00, added = 360, deleted = 311, reused = 307, allocated = 64, > > size = 4096, free = 10, > > storage = 0x85abfc000 > > "etracknew=1442820681065738.1480063024.205cookieloginhesh=68224ef0f0f562b069105a5a84d3bf43bb4f4beacookietracknew=1442820681065738.1480063033.205cookie__utmb=69692428.27.9.1480062955667refererhttps://ma"..., > > pos = 0x85abfc30f > > "(organic)|utmcmd=organic|utmctr=ukrcookie__utmv=183793058.|1=Users=Registered=1^2=Gender=f=1^3=Age=41=1^4=ID=40d191c1723959071990c7556fae5c92=1cookieuid=1CpM/FfSfoQYenDjBEOlAg==cookietrackss=147496897"...}, > > pool = 0x860d2b000, free_frames = 0x860d2b490, free_fake_connections > > = 0x0, streams_index = 0x853d22820, last_out = 0x857066188, posted = > > {prev = 0x85e7d7cb0, next = 0x85d2bdcb0}, dependencies = {prev = > > 0x8575e6bb0, > > next = 0x853d229a0}, closed = {prev = 0x855bffb80, next = > > 0x858b1f900}, last_sid = 415, closed_nodes = 31, settings_ack = 1, > > blocked = 1} > > (gdb) p h2c->posted > > $7 = {prev = 0x85e7d7cb0, next = 0x85d2bdcb0} > > (gdb) p h2c->posted.next > > $8 = (ngx_queue_t *) 0x85d2bdcb0 > > (gdb) p *h2c->posted.next > > $9 = {prev = 0x3938386138313962, next = 0x85e7d7cb0} > > > > > > core файл и исполнительный тоже есть, debug log был включен, если > > нужны дополнительные данные - попробуем извлечь. > > > Дебаг-лог и хотелось бы увидеть. Поскольку ошибка происходит на самом деле > не там, где оно падает, то нужен лог событий, а бэктрейс просто не содержит > необходимой информации. > [..] И используемую конфигурацию было бы неплохо посмотреть. -- Валентин Бартенев From sytar.alex на gmail.com Fri Nov 25 20:11:10 2016 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Fri, 25 Nov 2016 23:11:10 +0300 Subject: =?UTF-8?B?UmU6INCe0YfQtdGA0LXQtNC90L7QuSDQstC+0L/RgNC+0YEgbmdpbngrcGhw?= In-Reply-To: References: Message-ID: 25 ноября 2016 г., 14:55 пользователь Илья Шипицин написал: > через try_files можно сделать условие "если есть файл - отдать его, если > нет, маршрутизируем в @php И при запросе php-файла nginx радостно отдаст его пользователю. Не надо давать "плохие" советы, человек про другое спрашивал ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Fri Nov 25 20:25:24 2016 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 25 Nov 2016 22:25:24 +0200 Subject: =?UTF-8?B?UmU6INCe0YfQtdGA0LXQtNC90L7QuSDQstC+0L/RgNC+0YEgbmdpbngrcGhw?= In-Reply-To: References: Message-ID: On 25.11.2016 10:55, IvanMiller wrote: > Вот в очередной раз принялся "конфигурировать". Обратился к офф. > документации, там четко сказанно > > The problem section usually looks like this: > > location ~* \.php$ { > fastcgi_pass backend; > # [...] > } > > Хорошо, плохо так плохо, а хорошо вот так > > location ~* (file_a|file_b|file_c)\.php$ { > fastcgi_pass backend; > # [...] > } > > Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не > попадают, Nginx их начинает тупо выдавать без обработки. location заданные регулярными выражениями обрабатываются в порядке их появления в конфиге: http://nginx.org/ru/docs/http/ngx_http_core_module.html#location Можно делать так: location ~* (file_a|file_b|file_c)\.php$ { fastcgi_pass backend; # [...] } location ~* \.php$ { return 403; } -- Best regards, Gena From nginx-forum на forum.nginx.org Mon Nov 28 08:36:08 2016 From: nginx-forum на forum.nginx.org (halvabady) Date: Mon, 28 Nov 2016 03:36:08 -0500 Subject: =?UTF-8?B?UmU6INCe0YfQtdGA0LXQtNC90L7QuSDQstC+0L/RgNC+0YEgbmdpbngrcGhw?= In-Reply-To: References: Message-ID: <76e97a2235aa10a00c77976a38e95eb1.NginxMailingListRussian@forum.nginx.org> это лучший сервис [url=http://xn----7sbahjd3btneuw1joc.xn--p1ai//]адвокатов[/url] что приходилось видеть в просторах интернета и лююди там отличные и вообще сервис отличный!! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271168,271199#msg-271199 From m_nikita на bk.ru Wed Nov 30 00:37:50 2016 From: m_nikita на bk.ru (=?UTF-8?B?0J3QuNC60LjRgtCw?=) Date: Wed, 30 Nov 2016 03:37:50 +0300 Subject: =?UTF-8?B?Tmdpbngg0LTRg9Cx0LvQuNGA0YPQtdGCINC30LDQv9GA0L7RgdGLINC90LAg0LE=?= =?UTF-8?B?0LXQutC10L3QtA==?= Message-ID: <1480466270.818939054@f328.i.mail.ru> Доброго времени суток. Суть проблемы: пришел запрос, ушел на бекенд. Если бекенд не ответил за 2 секунды , nginx перестает ждать и отправляет еще один аналогичный запрос на бекенд, который отвергает приложение ввиду того что все еще занято прошлым запросом(на таблицах висят локи и пр). Вопрос: Почему nginx может не ждать выполнения а дублировать запрос спустя 2  секунды. Вот немного деталей. nginx version: nginx/1.11.6 built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1)  built with OpenSSL 1.0.1f 6 Jan 2014 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --with-cc-opt='-I /usr/include' --with-ld-opt='-L /usr/lib' --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/nginx-error.log --user=www-data --group=www-data --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/nginx-access.log --with-http_perl_module --with-http_stub_status_module --with-pcre --with-http_ssl_module --add-module=/usr/src/ngx_devel_kit-0.2.19 --add-module=/usr/src/lua-nginx-module --add-module=/usr/src/echo-nginx-module --with-debug --with-http_realip_module --add-module=/usr/src/nginx_upstream_check_module client_max_body_size       300m; client_body_buffer_size    128k; proxy_read_timeout 180s; proxy_send_timeout 180s; proxy_connect_timeout   10s; proxy_http_version 1.1; proxy_set_header Connection keep-alive; proxy_next_upstream error; proxy_next_upstream_timeout 30s; proxy_ignore_client_abort   on пробовал, не помогло. Вот вывод strike детки которая обрабатывала запрос:  http://pastebin.com/raw/HFP9tNNm   Интересно что делал nginx между 23:32:10 и 23:32:12 Вот вывод debug лога:  http://pastebin.com/raw/SQhXKVQ9   Куда копать дальше ?  Спасибо. -- Никита Маслянников ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Wed Nov 30 01:22:22 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 30 Nov 2016 04:22:22 +0300 Subject: =?UTF-8?B?UmU6IE5naW54INC00YPQsdC70LjRgNGD0LXRgiDQt9Cw0L/RgNC+0YHRiyDQvdCw?= =?UTF-8?B?INCx0LXQutC10L3QtA==?= In-Reply-To: <1480466270.818939054@f328.i.mail.ru> References: <1480466270.818939054@f328.i.mail.ru> Message-ID: <1679072.SDZ91bq2mD@vbart-laptop> On Wednesday 30 November 2016 03:37:50 Никита wrote: > Доброго времени суток. > > Суть проблемы: пришел запрос, ушел на бекенд. Если бекенд не ответил за 2 секунды , nginx перестает ждать и отправляет еще один аналогичный запрос на бекенд, который отвергает приложение ввиду того что все еще занято прошлым запросом(на таблицах висят локи и пр). > > Вопрос: Почему nginx может не ждать выполнения а дублировать запрос спустя 2 секунды. > > Вот немного деталей. > > nginx version: nginx/1.11.6 > built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) > built with OpenSSL 1.0.1f 6 Jan 2014 > TLS SNI support enabled > configure arguments: --prefix=/usr/share/nginx --with-cc-opt='-I /usr/include' --with-ld-opt='-L /usr/lib' --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/nginx-error.log --user=www-data --group=www-data --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/nginx-access.log --with-http_perl_module --with-http_stub_status_module --with-pcre --with-http_ssl_module --add-module=/usr/src/ngx_devel_kit-0.2.19 --add-module=/usr/src/lua-nginx-module --add-module=/usr/src/echo-nginx-module --with-debug --with-http_realip_module --add-module=/usr/src/nginx_upstream_check_module > > client_max_body_size 300m; > client_body_buffer_size 128k; > proxy_read_timeout 180s; > proxy_send_timeout 180s; > proxy_connect_timeout 10s; > proxy_http_version 1.1; > proxy_set_header Connection keep-alive; > proxy_next_upstream error; > proxy_next_upstream_timeout 30s; > > > proxy_ignore_client_abort on пробовал, не помогло. > > Вот вывод strike детки которая обрабатывала запрос: http://pastebin.com/raw/HFP9tNNm > Интересно что делал nginx между 23:32:10 и 23:32:12 > Ждал ответа от бэкенда. > Вот вывод debug лога: http://pastebin.com/raw/SQhXKVQ9 > > Куда копать дальше ? > > Спасибо. > > Судя по логу клиент закрыл соединение через две секунды, а затем послал ещё один запрос в другом соединении. -- Валентин Бартенев From russjura на gmail.com Wed Nov 30 01:28:15 2016 From: russjura на gmail.com (=?UTF-8?B?0K7RgNC40Lk=?=) Date: Wed, 30 Nov 2016 03:28:15 +0200 Subject: =?UTF-8?B?UmU6IE5naW54INC00YPQsdC70LjRgNGD0LXRgiDQt9Cw0L/RgNC+0YHRiyDQvdCw?= =?UTF-8?B?INCx0LXQutC10L3QtA==?= In-Reply-To: <1679072.SDZ91bq2mD@vbart-laptop> References: <1480466270.818939054@f328.i.mail.ru> <1679072.SDZ91bq2mD@vbart-laptop> Message-ID: а можно часть логов ? желательно и доступа и ошибок ? в промежутке 23:30:00 и 23:33:30 30 ноября 2016 г., 3:22 пользователь Валентин Бартенев написал: > On Wednesday 30 November 2016 03:37:50 Никита wrote: > > Доброго времени суток. > > > > Суть проблемы: пришел запрос, ушел на бекенд. Если бекенд не ответил за > 2 секунды , nginx перестает ждать и отправляет еще один аналогичный запрос > на бекенд, который отвергает приложение ввиду того что все еще занято > прошлым запросом(на таблицах висят локи и пр). > > > > Вопрос: Почему nginx может не ждать выполнения а дублировать запрос > спустя 2 секунды. > > > > Вот немного деталей. > > > > nginx version: nginx/1.11.6 > > built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) > > built with OpenSSL 1.0.1f 6 Jan 2014 > > TLS SNI support enabled > > configure arguments: --prefix=/usr/share/nginx --with-cc-opt='-I > /usr/include' --with-ld-opt='-L /usr/lib' --conf-path=/etc/nginx/nginx.conf > --sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx/nginx-error.log --user=www-data > --group=www-data --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/nginx-access.log > --with-http_perl_module --with-http_stub_status_module --with-pcre > --with-http_ssl_module --add-module=/usr/src/ngx_devel_kit-0.2.19 > --add-module=/usr/src/lua-nginx-module --add-module=/usr/src/echo-nginx-module > --with-debug --with-http_realip_module --add-module=/usr/src/nginx_ > upstream_check_module > > > > client_max_body_size 300m; > > client_body_buffer_size 128k; > > proxy_read_timeout 180s; > > proxy_send_timeout 180s; > > proxy_connect_timeout 10s; > > proxy_http_version 1.1; > > proxy_set_header Connection keep-alive; > > proxy_next_upstream error; > > proxy_next_upstream_timeout 30s; > > > > > > proxy_ignore_client_abort on пробовал, не помогло. > > > > Вот вывод strike детки которая обрабатывала запрос: > http://pastebin.com/raw/HFP9tNNm > > Интересно что делал nginx между 23:32:10 и 23:32:12 > > > > Ждал ответа от бэкенда. > > > > Вот вывод debug лога: http://pastebin.com/raw/SQhXKVQ9 > > > > Куда копать дальше ? > > > > Спасибо. > > > > > > Судя по логу клиент закрыл соединение через две секунды, а затем послал > ещё один запрос в другом соединении. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From russjura на gmail.com Wed Nov 30 01:29:40 2016 From: russjura на gmail.com (=?UTF-8?B?0K7RgNC40Lk=?=) Date: Wed, 30 Nov 2016 03:29:40 +0200 Subject: =?UTF-8?B?UmU6IE5naW54INC00YPQsdC70LjRgNGD0LXRgiDQt9Cw0L/RgNC+0YHRiyDQvdCw?= =?UTF-8?B?INCx0LXQutC10L3QtA==?= In-Reply-To: References: <1480466270.818939054@f328.i.mail.ru> <1679072.SDZ91bq2mD@vbart-laptop> Message-ID: Все, вижу, прошу прощения з предыдущее сообщение, еще не проснулся. 30 ноября 2016 г., 3:28 пользователь Юрий написал: > а можно часть логов ? желательно и доступа и ошибок ? в промежутке 23:30:00 > и 23:33:30 > > 30 ноября 2016 г., 3:22 пользователь Валентин Бартенев > написал: > > On Wednesday 30 November 2016 03:37:50 Никита wrote: >> > Доброго времени суток. >> > >> > Суть проблемы: пришел запрос, ушел на бекенд. Если бекенд не ответил за >> 2 секунды , nginx перестает ждать и отправляет еще один аналогичный запрос >> на бекенд, который отвергает приложение ввиду того что все еще занято >> прошлым запросом(на таблицах висят локи и пр). >> > >> > Вопрос: Почему nginx может не ждать выполнения а дублировать запрос >> спустя 2 секунды. >> > >> > Вот немного деталей. >> > >> > nginx version: nginx/1.11.6 >> > built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) >> > built with OpenSSL 1.0.1f 6 Jan 2014 >> > TLS SNI support enabled >> > configure arguments: --prefix=/usr/share/nginx --with-cc-opt='-I >> /usr/include' --with-ld-opt='-L /usr/lib' --conf-path=/etc/nginx/nginx.conf >> --sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid >> --error-log-path=/var/log/nginx/nginx-error.log --user=www-data >> --group=www-data --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp >> --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp >> --http-proxy-temp-path=/var/tmp/nginx/proxy_temp >> --http-scgi-temp-path=/var/tmp/nginx/scgi_temp >> --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp >> --http-log-path=/var/log/nginx/nginx-access.log --with-http_perl_module >> --with-http_stub_status_module --with-pcre --with-http_ssl_module >> --add-module=/usr/src/ngx_devel_kit-0.2.19 --add-module=/usr/src/lua-nginx-module >> --add-module=/usr/src/echo-nginx-module --with-debug >> --with-http_realip_module --add-module=/usr/src/nginx_up >> stream_check_module >> > >> > client_max_body_size 300m; >> > client_body_buffer_size 128k; >> > proxy_read_timeout 180s; >> > proxy_send_timeout 180s; >> > proxy_connect_timeout 10s; >> > proxy_http_version 1.1; >> > proxy_set_header Connection keep-alive; >> > proxy_next_upstream error; >> > proxy_next_upstream_timeout 30s; >> > >> > >> > proxy_ignore_client_abort on пробовал, не помогло. >> > >> > Вот вывод strike детки которая обрабатывала запрос: >> http://pastebin.com/raw/HFP9tNNm >> > Интересно что делал nginx между 23:32:10 и 23:32:12 >> > >> >> Ждал ответа от бэкенда. >> >> >> > Вот вывод debug лога: http://pastebin.com/raw/SQhXKVQ9 >> > >> > Куда копать дальше ? >> > >> > Спасибо. >> > >> > >> >> Судя по логу клиент закрыл соединение через две секунды, а затем послал >> ещё один запрос в другом соединении. >> >> -- >> Валентин Бартенев >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Nov 30 07:58:28 2016 From: nginx-forum на forum.nginx.org (waster) Date: Wed, 30 Nov 2016 02:58:28 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC30LDQstC40YHQsNC90Lg=?= =?UTF-8?B?0Y8g0LIg0L7RgtCy0LXRgtCw0YUg0L3QsCDQt9Cw0L/RgNC+0YHRiw==?= In-Reply-To: <6f41726b24bc8f0a97fe8493d8f50dfc.NginxMailingListRussian@forum.nginx.org> References: <6f41726b24bc8f0a97fe8493d8f50dfc.NginxMailingListRussian@forum.nginx.org> Message-ID: <5d073c6efe848b5323ec48427e245118.NginxMailingListRussian@forum.nginx.org> Никто, все-таки с подобным поведением не сталкивался? Никак не могу найти причину. Файловая подсистема вряд ли здесь причиной, серверах стоят SSD, iostat нормальный. Сами серверы довольно могучие - 12 CPUs, 48GB RAM. Во всех логах системы и nginx чисто, никаких предупреждений, но все равно иногда есть затыки в ответах. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271081,271236#msg-271236 From basil на vpm.net.ua Wed Nov 30 09:56:54 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Wed, 30 Nov 2016 11:56:54 +0200 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC30LDQstC40YHQsNC90Lg=?= =?UTF-8?B?0Y8g0LIg0L7RgtCy0LXRgtCw0YUg0L3QsCDQt9Cw0L/RgNC+0YHRiw==?= In-Reply-To: <5d073c6efe848b5323ec48427e245118.NginxMailingListRussian@forum.nginx.org> References: <6f41726b24bc8f0a97fe8493d8f50dfc.NginxMailingListRussian@forum.nginx.org> <5d073c6efe848b5323ec48427e245118.NginxMailingListRussian@forum.nginx.org> Message-ID: у меня когда затыки, то виновато приложение, причем затыки являются слествием каких-то предыдущих запросов, и в логах 503-ю отдают банально безобидные запросы, которые просто выполняются за милисекунды, отлавливать очень сложно такое, та и ресурсы на такое тратить не хочется, ибо есть куда - но это моя ситуация Затыки такие, что нгинкс даже перестает отдавать страницу статистики заббиксу - тупо забиваются сессии, боремся уменьшением ттл-а сессии. На бекэндах апач, очень сильно помогло уменьшение количества выполняемых запросов одним процессом - тупо прибиваю его после 32-ух запросов 30 ноября 2016 г., 9:58 пользователь waster написал: > Никто, все-таки с подобным поведением не сталкивался? Никак не могу найти > причину. Файловая подсистема вряд ли здесь причиной, серверах стоят SSD, > iostat нормальный. Сами серверы довольно могучие - 12 CPUs, 48GB RAM. Во > всех логах системы и nginx чисто, никаких предупреждений, но все равно > иногда есть затыки в ответах. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,271081,271236#msg-271236 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Nov 30 11:19:42 2016 From: nginx-forum на forum.nginx.org (waster) Date: Wed, 30 Nov 2016 06:19:42 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC30LDQstC40YHQsNC90Lg=?= =?UTF-8?B?0Y8g0LIg0L7RgtCy0LXRgtCw0YUg0L3QsCDQt9Cw0L/RgNC+0YHRiw==?= In-Reply-To: References: Message-ID: Ага, только дело в том, что там приложения-то по сути нет, просто связка прокси с кэшем и ориджина на раздачу статики. Может как-то параметры keep-alive завязаны? Vasiliy P. Melnik Wrote: ------------------------------------------------------- > у меня когда затыки, то виновато приложение, причем затыки являются > слествием каких-то предыдущих запросов, и в логах 503-ю отдают > банально > безобидные запросы, которые просто выполняются за милисекунды, > отлавливать > очень сложно такое, та и ресурсы на такое тратить не хочется, ибо есть > куда > - но это моя ситуация > > Затыки такие, что нгинкс даже перестает отдавать страницу статистики > заббиксу - тупо забиваются сессии, боремся уменьшением ттл-а сессии. > На > бекэндах апач, очень сильно помогло уменьшение количества выполняемых > запросов одним процессом - тупо прибиваю его после 32-ух запросов > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271081,271240#msg-271240 From m_nikita на bk.ru Wed Nov 30 12:44:17 2016 From: m_nikita на bk.ru (=?UTF-8?B?0J3QuNC60LjRgtCw?=) Date: Wed, 30 Nov 2016 15:44:17 +0300 Subject: =?UTF-8?B?UmVbMl06IE5naW54INC00YPQsdC70LjRgNGD0LXRgiDQt9Cw0L/RgNC+0YHRiyA=?= =?UTF-8?B?0L3QsCDQsdC10LrQtdC90LQ=?= In-Reply-To: <1679072.SDZ91bq2mD@vbart-laptop> References: <1480466270.818939054@f328.i.mail.ru> <1679072.SDZ91bq2mD@vbart-laptop> Message-ID: <1480509857.111291504@f343.i.mail.ru> Если клиент повторил запрос - почему тогда в трейсах и логах не видно входящего конекта от внешнего инициатора запроса, есть только внезапный реквест на апстрим ? >Среда, 30 ноября 2016, 4:22 +03:00 от Валентин Бартенев : > >On Wednesday 30 November 2016 03:37:50 Никита wrote: >> Доброго времени суток. >> >> Суть проблемы: пришел запрос, ушел на бекенд. Если бекенд не ответил за 2 секунды , nginx перестает ждать и отправляет еще один аналогичный запрос на бекенд, который отвергает приложение ввиду того что все еще занято прошлым запросом(на таблицах висят локи и пр). >> >> Вопрос: Почему nginx может не ждать выполнения а дублировать запрос спустя 2 секунды. >> >> Вот немного деталей. >> >> nginx version: nginx/1.11.6 >> built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) >> built with OpenSSL 1.0.1f 6 Jan 2014 >> TLS SNI support enabled >> configure arguments: --prefix=/usr/share/nginx --with-cc-opt='-I /usr/include' --with-ld-opt='-L /usr/lib' --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/nginx-error.log --user=www-data --group=www-data --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/nginx-access.log --with-http_perl_module --with-http_stub_status_module --with-pcre --with-http_ssl_module --add-module=/usr/src/ngx_devel_kit-0.2.19 --add-module=/usr/src/lua-nginx-module --add-module=/usr/src/echo-nginx-module --with-debug --with-http_realip_module --add-module=/usr/src/nginx_upstream_check_module >> >> client_max_body_size 300m; >> client_body_buffer_size 128k; >> proxy_read_timeout 180s; >> proxy_send_timeout 180s; >> proxy_connect_timeout 10s; >> proxy_http_version 1.1; >> proxy_set_header Connection keep-alive; >> proxy_next_upstream error; >> proxy_next_upstream_timeout 30s; >> >> >> proxy_ignore_client_abort on пробовал, не помогло. >> >> Вот вывод strike детки которая обрабатывала запрос: http://pastebin.com/raw/HFP9tNNm >> Интересно что делал nginx между 23:32:10 и 23:32:12 >> > >Ждал ответа от бэкенда. > > >> Вот вывод debug лога: http://pastebin.com/raw/SQhXKVQ9 >> >> Куда копать дальше ? >> >> Спасибо. >> >> > >Судя по логу клиент закрыл соединение через две секунды, а затем послал ещё один запрос в другом соединении. > >-- >Валентин Бартенев >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Никита Маслянников ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Wed Nov 30 14:10:50 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 30 Nov 2016 17:10:50 +0300 Subject: =?UTF-8?B?UmU6IE5naW54INC00YPQsdC70LjRgNGD0LXRgiDQt9Cw0L/RgNC+0YHRiyDQvdCw?= =?UTF-8?B?INCx0LXQutC10L3QtA==?= In-Reply-To: <1480509857.111291504@f343.i.mail.ru> References: <1480466270.818939054@f328.i.mail.ru> <1679072.SDZ91bq2mD@vbart-laptop> <1480509857.111291504@f343.i.mail.ru> Message-ID: <12138712.h0oSn5T5ic@vbart-workstation> On Wednesday 30 November 2016 15:44:17 Никита wrote: > Если клиент повторил запрос - почему тогда в трейсах и логах не видно входящего конекта от внешнего инициатора запроса, есть только внезапный реквест на апстрим ? > [..] Дебаг-лог, который вы привели - неполный и снять не на основном уровне. Так что похоже у вас больше одного лога и смотреть нужно все. -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed Nov 30 22:21:39 2016 From: nginx-forum на forum.nginx.org (atway) Date: Wed, 30 Nov 2016 17:21:39 -0500 Subject: nginx performance problem on linux In-Reply-To: <1cb8f2e7a6b1f24f0abbfbedd060df6b.NginxMailingListRussian@forum.nginx.org> References: <20161117213117.enenfeh62clsfd23@sie.protva.ru> <1cb8f2e7a6b1f24f0abbfbedd060df6b.NginxMailingListRussian@forum.nginx.org> Message-ID: <04bea708df68639359e745fd07b1e9f8.NginxMailingListRussian@forum.nginx.org> Это баг ядра. Пришлось откатиться до версии vzkernel 2.6.32-042stab116.2 https://bugs.openvz.org/browse/OVZ-6836 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271025,271254#msg-271254