From nginx-forum на forum.nginx.org Fri May 4 13:15:10 2018 From: nginx-forum на forum.nginx.org (Konstantin) Date: Fri, 04 May 2018 09:15:10 -0400 Subject: =?UTF-8?B?0YTQvtGA0LLQsNGA0LTQuNC90LMgVURQINC/0L7RgtC+0LrQvg==?= Message-ID: Добрый день ! Возможно ли с помощью nginx решить следующую задачу: Есть входящие UDP потоки, обычные на адрес, multicast, broadcast. Необходимо при получении каждого пакета переслать его на несколько заданных портов и адресов. То есть суть в том что разветвить(несколько копий создать) UDP поток. С Уважением Константин. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279677,279677#msg-279677 From arut на nginx.com Fri May 4 13:57:01 2018 From: arut на nginx.com (Roman Arutyunyan) Date: Fri, 4 May 2018 16:57:01 +0300 Subject: =?UTF-8?B?UmU6INGE0L7RgNCy0LDRgNC00LjQvdCzIFVEUCDQv9C+0YLQvtC60L4=?= In-Reply-To: References: Message-ID: <20180504135701.GB2383@Romans-MacBook-Air.local> Добрый день, Константин. On Fri, May 04, 2018 at 09:15:10AM -0400, Konstantin wrote: > Добрый день ! > > Возможно ли с помощью nginx решить следующую задачу: > Есть входящие UDP потоки, обычные на адрес, multicast, broadcast. > Необходимо при получении каждого пакета переслать его на несколько заданных > портов и адресов. > То есть суть в том что разветвить(несколько копий создать) UDP поток. Нет, такое сейчас невозможно. -- Roman Arutyunyan From nginx на mva.name Mon May 7 13:49:57 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 07 May 2018 16:49:57 +0300 Subject: =?UTF-8?B?0L/QsNC60LXRgtGLINC/0L7QtCBVYnVudHUgMTguMDQgTFRTIChiaW9uaWMp?= Message-ID: <2520991.787RBI4FOX@tp> Здравствуйте, товарищи дивелоперы! Подскажите, пожалуйста, есть ли планы по добавлению дистрибутива "bionic" в NginX'овый репозиторий пакетов для Ubuntu (уже как минимум неделю, а то и две, как релизнулось)? А то, что-то, вот, затык на устаноке NginX :'( From thresh на nginx.com Mon May 7 13:55:33 2018 From: thresh на nginx.com (Konstantin Pavlov) Date: Mon, 7 May 2018 16:55:33 +0300 Subject: =?UTF-8?B?UmU6INC/0LDQutC10YLRiyDQv9C+0LQgVWJ1bnR1IDE4LjA0IExUUyAoYmlvbmlj?= =?UTF-8?B?KQ==?= In-Reply-To: <2520991.787RBI4FOX@tp> References: <2520991.787RBI4FOX@tp> Message-ID: <30526c4b-0a3a-953f-4a7e-43b265ebe86d@nginx.com> Здравствуйте, 07.05.2018 16:49, Vadim A. Misbakh-Soloviov wrote: > Здравствуйте, товарищи дивелоперы! > Подскажите, пожалуйста, есть ли планы по добавлению дистрибутива "bionic" в > NginX'овый репозиторий пакетов для Ubuntu (уже как минимум неделю, а то и две, > как релизнулось)? Да, сделаем на этой неделе. -- Konstantin Pavlov https://www.nginx.com/ From thresh на nginx.com Tue May 8 14:27:49 2018 From: thresh на nginx.com (Konstantin Pavlov) Date: Tue, 8 May 2018 17:27:49 +0300 Subject: =?UTF-8?B?UmU6INC/0LDQutC10YLRiyDQv9C+0LQgVWJ1bnR1IDE4LjA0IExUUyAoYmlvbmlj?= =?UTF-8?B?KQ==?= In-Reply-To: <2520991.787RBI4FOX@tp> References: <2520991.787RBI4FOX@tp> Message-ID: <0cb53a45-2702-2dad-5158-733e3e72639d@nginx.com> Здравствуйте, 07.05.2018 16:49, Vadim A. Misbakh-Soloviov wrote: > Здравствуйте, товарищи дивелоперы! > Подскажите, пожалуйста, есть ли планы по добавлению дистрибутива "bionic" в > NginX'овый репозиторий пакетов для Ubuntu (уже как минимум неделю, а то и две, > как релизнулось)? > > А то, что-то, вот, затык на устаноке NginX :'( Теперь пакеты доступны - и для mainline и для stable веток разработки. -- Konstantin Pavlov https://www.nginx.com/ From corochoone на gmail.com Fri May 11 05:46:56 2018 From: corochoone на gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCS0LjRgdC70L7QsdC+0LrQvtCy?=) Date: Fri, 11 May 2018 08:46:56 +0300 Subject: =?UTF-8?B?0KHQvNC10L3QuNC70L7RgdGMINGD0LzQvtC70YfQsNC90LjQtSDQvdCwICpfaW50?= =?UTF-8?B?ZXJjZXB0X2Vycm9ycz8=?= Message-ID: Доброго времени суток, всем. Странную штуку я обнаружил. Хотелось бы понять, не ошибся ли? У меня в одном месте стоит nginx-1.10.2 (разработка) в другом 1.12.2 (тестирование). Ось одна и та же: CentOS 7. И тут разработчики обнаружили что неправильно работает их API - на разработке всё ок, на тестировании - лажа. Посмотрели в чём дело. Там где 1.10.2 при отдачи 500-ки, выводится содержимое, которое возвращает скрипт, выдавший 500-ку, а там где 1.12.2 при отдаче 500-ки, отдаётся содержимое файла, который задан директивой error_page. Дальнейшее расследование показало, что если на 1.12.2 сделать fastcgi_intercept_errors off; то всё работает. Однако, в документации: http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_intercept_errors написано что ПО УМОЛЧАНИЮ установлено off. Получается документация врёт и умолчание сменилось на 1.12.2? Больше нигде директивы fastcgi_intercept_errors в конфигах нет. P.S. Похоже это же самое справедливо и для proxy_intercept_errors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Fri May 11 18:18:26 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 11 May 2018 21:18:26 +0300 Subject: =?UTF-8?B?UmU6INCh0LzQtdC90LjQu9C+0YHRjCDRg9C80L7Qu9GH0LDQvdC40LUg0L3QsCAq?= =?UTF-8?B?X2ludGVyY2VwdF9lcnJvcnM/?= In-Reply-To: References: Message-ID: <20180511181826.GY32137@mdounin.ru> Hello! On Fri, May 11, 2018 at 08:46:56AM +0300, Виктор Вислобоков wrote: > Странную штуку я обнаружил. Хотелось бы понять, не ошибся ли? > У меня в одном месте стоит nginx-1.10.2 (разработка) в другом 1.12.2 > (тестирование). Ось одна и та же: CentOS 7. > И тут разработчики обнаружили что неправильно работает их API - на > разработке всё ок, на тестировании - лажа. Посмотрели в чём дело. > Там где 1.10.2 при отдачи 500-ки, выводится содержимое, которое возвращает > скрипт, выдавший 500-ку, а там где 1.12.2 при отдаче 500-ки, отдаётся > содержимое файла, который задан директивой error_page. > Дальнейшее расследование показало, что если на 1.12.2 сделать > > fastcgi_intercept_errors off; > > то всё работает. Однако, в документации: > http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_intercept_errors > написано что ПО УМОЛЧАНИЮ установлено off. Получается документация врёт и > умолчание сменилось на 1.12.2? > Больше нигде директивы fastcgi_intercept_errors в конфигах нет. > > P.S. Похоже это же самое справедливо и для proxy_intercept_errors. Нет, значения по умолчанию fastcgi_intercept_errors и proxy_intercept_errors не менялись с момента появления соответствующих директив. Если подобное поведение действительно наблюдается и лечится явным указанием "fastcgi_intercept_errors off" - было бы интересно увидеть вывод "nginx -V" и "nginx -T". -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon May 14 07:14:28 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 14 May 2018 12:14:28 +0500 Subject: =?UTF-8?B?UmU6INC/0L7QtNC00LXRgNC20LrQsCBJUF9CSU5EX0FERFJFU1NfTk9fUE9SVCA=?= =?UTF-8?B?0L3QsCBDZW50T1MtNy40?= In-Reply-To: <1705981.ux17j1kC72@vbart-laptop> References: <1705981.ux17j1kC72@vbart-laptop> Message-ID: на днях зарелизился centos-7.5, в нем, к сожалению, все по прежнему завел тикет https://trac.nginx.org/nginx/ticket/1553 посмотрите ? 29 апреля 2018 г., 3:40 пользователь Валентин Бартенев написал: > On Saturday, 28 April 2018 15:03:49 MSK Илья Шипицин wrote: > > привет! > > > > поддержка IP_BIND_ADDRESS_NO_PORT официально началась в ядре 4.2, но ... > ее > > портировали в 3.10 на CentOS-7.4 > > > > однако, портировали не очень качественно. константа определена не в том > > файле, в котором должна (и в котором ищет nginx) > > > > [root на xxx ~]# grep -r IP_BIND_ADDRESS_NO_PORT /usr/include/ > > /usr/include/linux/in.h:#define IP_BIND_ADDRESS_NO_PORT 24 > > [root на xxx ~]# > > > > > > т.е. если пакет собирать, как он собирается обычно, то поддержка > > IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы). > > > > скажите, вы официальные пакеты собираете каким образом ? кажется, имеет > > смысл поправить эту процедуру и дать эту крутую фичу пользователям > > CentOS-7.4 > > > > Дело же не в ядре (не только в нем). На линуксах интерфейс обеспечивает > glibc > и именно туда смотрит nginx. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon May 14 09:35:27 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 14 May 2018 14:35:27 +0500 Subject: =?UTF-8?B?0L/QsNC00LXQvdC40Y8g0LLQvtGA0LrQtdGA0LAg0L/QvtGB0LvQtSDQstC60Ls=?= =?UTF-8?B?0Y7Rh9C10L3QuNGPIG1heF9jb25ucw==?= Message-ID: привет! используем nginx-1.13.9 на freebsd. поменяли конфигурацию было upstream xxx { server server1:80; server server2:80; server server3:80; keepalive 10; } стало upstream xxx { server server1:80 max_conns=5000; server server2:80 max_conns=5000; server server3:80 max_conns=5000; keepalive 10; zone xxx 10m; } стали ловить вот такие падения (gdb) bt #0 ngx_event_connect_peer (pc=0x827944638) at src/event/ngx_event_connect.c:41 #1 0x00000000004720d3 in ngx_http_upstream_connect (r=0x807e13050, u=0x827944628) at src/http/ngx_http_upstream.c:1508 #2 0x000000000046f1b7 in ngx_http_upstream_init_request (r=) at ngx_event_timer.h:46 #3 0x0000000000467ab8 in ngx_http_read_client_request_body (r=0x807e13050, post_handler=0x46e4e0 ) at ngx_event_timer.h:55 #4 0x00000000004a5e43 in ngx_http_proxy_handler (r=0x807e13050) at src/http/modules/ngx_http_proxy_module.c:930 #5 0x0000000000456d1a in ngx_http_core_content_phase (r=0x807e13050, ph=0x81a3bc0f8) at src/http/ngx_http_core_module.c:1162 #6 0x00000000004560f5 in ngx_http_handler (r=0x807e13050) at src/http/ngx_http_core_module.c:851 #7 0x000000000045fe2c in ngx_http_process_request (r=0x807e13050) at src/http/ngx_http_request.c:1948 #8 0x0000000000461b73 in ngx_http_process_request_line (rev=0x8042ccc68) at src/http/ngx_http_request.c:1048 #9 0x0000000000449c48 in ngx_kqueue_process_events (cycle=0x81c449050, timer=, flags=) at src/event/modules/ngx_kqueue_module.c:669 #10 0x000000000043ef69 in ngx_process_events_and_timers (cycle=0x81c449050) at src/event/ngx_event.c:242 #11 0x0000000000447f79 in ngx_worker_process_cycle (cycle=0x81c449050, data=) at src/os/unix/ngx_process_cycle.c:750 #12 0x0000000000446328 in ngx_spawn_process (cycle=, proc=, data=, name=, respawn=32) at src/os/unix/ngx_process.c:199 #13 0x00000000004472a9 in ngx_master_process_cycle (cycle=0x81c449050) at src/os/unix/ngx_process_cycle.c:622 #14 0x000000000041cda8 in main (argc=, argv=) at src/core/nginx.c:382 Current language: auto; currently minimal (gdb) у нас весьма развесистый конфиг, и есть сторонние модули (но по трейсу вроде они не задействованы). в списке изменений между 1.13.9 и 1.13.12 не вижу правок в этих местах. поразбираемся ? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ru на nginx.com Mon May 14 10:04:41 2018 From: ru на nginx.com (Ruslan Ermilov) Date: Mon, 14 May 2018 13:04:41 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QtNC00LXRgNC20LrQsCBJUF9CSU5EX0FERFJFU1NfTk9fUE9SVCA=?= =?UTF-8?B?0L3QsCBDZW50T1MtNy40?= In-Reply-To: References: <1705981.ux17j1kC72@vbart-laptop> Message-ID: <20180514100441.GB1635@lo0.su> On Mon, May 14, 2018 at 12:14:28PM +0500, Илья Шипицин wrote: > на днях зарелизился centos-7.5, в нем, к сожалению, все по прежнему > > завел тикет > > https://trac.nginx.org/nginx/ticket/1553 > > посмотрите ? > > 29 апреля 2018 г., 3:40 пользователь Валентин Бартенев > написал: > > > On Saturday, 28 April 2018 15:03:49 MSK Илья Шипицин wrote: > > > привет! > > > > > > поддержка IP_BIND_ADDRESS_NO_PORT официально началась в ядре 4.2, но ... > > > ее портировали в 3.10 на CentOS-7.4 > > > > > > однако, портировали не очень качественно. константа определена не в том > > > файле, в котором должна (и в котором ищет nginx) > > > > > > [root на xxx ~]# grep -r IP_BIND_ADDRESS_NO_PORT /usr/include/ > > > /usr/include/linux/in.h:#define IP_BIND_ADDRESS_NO_PORT 24 > > > [root на xxx ~]# > > > > > > > > > т.е. если пакет собирать, как он собирается обычно, то поддержка > > > IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы). > > > > > > скажите, вы официальные пакеты собираете каким образом ? кажется, имеет > > > смысл поправить эту процедуру и дать эту крутую фичу пользователям > > > CentOS-7.4 > > > > > > > Дело же не в ядре (не только в нем). На линуксах интерфейс обеспечивает > > glibc и именно туда смотрит nginx. - это заголовочный файл ядра. - это заголовочный файл glibc. Приложения используют . В норме макрос IP_BIND_ADDRESS_NO_PORT есть в обоих файлах, что означает, что поддержка есть и в ядре, и в glibc. Утверждение о том, что "константа определена не в том файле", ошибочное. Как Вам уже пытался ранее объяснять Валентин, проблема заключается в том, что в установленной версии glibc нет поддержки этого макроса. Для себя Вы можете проблему решить так: configure --with-cc-opt=-DIP_BIND_ADDRESS_NO_PORT=24 From chipitsine на gmail.com Mon May 14 10:30:51 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 14 May 2018 15:30:51 +0500 Subject: =?UTF-8?B?UmU6INC/0L7QtNC00LXRgNC20LrQsCBJUF9CSU5EX0FERFJFU1NfTk9fUE9SVCA=?= =?UTF-8?B?0L3QsCBDZW50T1MtNy40?= In-Reply-To: <20180514100441.GB1635@lo0.su> References: <1705981.ux17j1kC72@vbart-laptop> <20180514100441.GB1635@lo0.su> Message-ID: 14 мая 2018 г., 15:04 пользователь Ruslan Ermilov написал: > On Mon, May 14, 2018 at 12:14:28PM +0500, Илья Шипицин wrote: > > на днях зарелизился centos-7.5, в нем, к сожалению, все по прежнему > > > > завел тикет > > > > https://trac.nginx.org/nginx/ticket/1553 > > > > посмотрите ? > > > > 29 апреля 2018 г., 3:40 пользователь Валентин Бартенев > > написал: > > > > > On Saturday, 28 April 2018 15:03:49 MSK Илья Шипицин wrote: > > > > привет! > > > > > > > > поддержка IP_BIND_ADDRESS_NO_PORT официально началась в ядре 4.2, но > ... > > > > ее портировали в 3.10 на CentOS-7.4 > > > > > > > > однако, портировали не очень качественно. константа определена не в > том > > > > файле, в котором должна (и в котором ищет nginx) > > > > > > > > [root на xxx ~]# grep -r IP_BIND_ADDRESS_NO_PORT /usr/include/ > > > > /usr/include/linux/in.h:#define IP_BIND_ADDRESS_NO_PORT 24 > > > > [root на xxx ~]# > > > > > > > > > > > > т.е. если пакет собирать, как он собирается обычно, то поддержка > > > > IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы). > > > > > > > > скажите, вы официальные пакеты собираете каким образом ? кажется, > имеет > > > > смысл поправить эту процедуру и дать эту крутую фичу пользователям > > > > CentOS-7.4 > > > > > > > > > > Дело же не в ядре (не только в нем). На линуксах интерфейс > обеспечивает > > > glibc и именно туда смотрит nginx. > > - это заголовочный файл ядра. - это > заголовочный файл glibc. Приложения используют . > В норме макрос IP_BIND_ADDRESS_NO_PORT есть в обоих файлах, что > означает, что поддержка есть и в ядре, и в glibc. Утверждение о > том, что "константа определена не в том файле", ошибочное. > > Как Вам уже пытался ранее объяснять Валентин, проблема заключается > в том, что в установленной версии glibc нет поддержки этого макроса. > > Для себя Вы можете проблему решить так: > > configure --with-cc-opt=-DIP_BIND_ADDRESS_NO_PORT=24 > для себя я, конечно, решу. первоначально мы попали в неочевидную ловушку 1) читаем про IP_BIND_ADDRESS_NO_PORT 2) читаем, что начиная с centos-7.4 должно работать 3) ставим официальный пакет 4) не работает (но чтобы это понять, пришлось залезть в отладочный лог и попрыгать с strace) в официальном пакете поправите ? > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon May 14 13:59:46 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 14 May 2018 16:59:46 +0300 Subject: =?UTF-8?B?UmU6INC/0LDQtNC10L3QuNGPINCy0L7RgNC60LXRgNCwINC/0L7RgdC70LUg0LI=?= =?UTF-8?B?0LrQu9GO0YfQtdC90LjRjyBtYXhfY29ubnM=?= In-Reply-To: References: Message-ID: <20180514135946.GB32137@mdounin.ru> Hello! On Mon, May 14, 2018 at 02:35:27PM +0500, Илья Шипицин wrote: > привет! > > используем nginx-1.13.9 на freebsd. > > поменяли конфигурацию > > было > > upstream xxx { > server server1:80; > server server2:80; > server server3:80; > keepalive 10; > } > > стало > > upstream xxx { > server server1:80 max_conns=5000; > server server2:80 max_conns=5000; > server server3:80 max_conns=5000; > keepalive 10; > zone xxx 10m; > } > > стали ловить вот такие падения > > (gdb) bt > #0 ngx_event_connect_peer (pc=0x827944638) at > src/event/ngx_event_connect.c:41 > #1 0x00000000004720d3 in ngx_http_upstream_connect (r=0x807e13050, > u=0x827944628) at src/http/ngx_http_upstream.c:1508 > #2 0x000000000046f1b7 in ngx_http_upstream_init_request (r= optimized out>) at ngx_event_timer.h:46 [...] > у нас весьма развесистый конфиг, и есть сторонние модули (но по трейсу > вроде они не задействованы). в списке изменений между 1.13.9 и 1.13.12 не > вижу правок в этих местах. > > > поразбираемся ? Судя по падению, выбор пира вернул NGX_OK, но вернул при этом мусор вместо адреса бэкенда. Наиболее вероятная причина - какой-нибудь сторонний балансировщик, который не умеет работать с блоками upstream{}, хранящимися в разделяемой памяти. Так что я бы рекомендовал начать разбираться с выпиливания сторонних модулей. -- Maxim Dounin http://mdounin.ru/ From panichev на segmento.ru Mon May 14 14:16:34 2018 From: panichev на segmento.ru (Panichev Oleg) Date: Mon, 14 May 2018 17:16:34 +0300 Subject: =?UTF-8?B?0KTQuNC70YzRgtGA0LDRhtC40Y8gZXJyb3JfbG9nINC00LvRjyDQu9C+0LrQtdC5?= =?UTF-8?B?0YjQvdCwLg==?= Message-ID: <92a4446d-5618-c21d-251b-45819a627fc2@segmento.ru> Добрый день, У нас есть задача часть трафика отправлять на тестовый стенд. Решили этот вопрос таким образом  split_clients "${shard_key}" $test_or_204 {     5%  test;     *   mirror_204;   }   upstream test {     server test:1234;   }   location /original {   ...   mirror /mirror    ...   }   location /mirror {  if ( $test_or_204 = "mirror_204" ) {         return 204;       }       fastcgi_pass $test_or_204;   }  Это решение работает прекрасно за исключением того момента, что когда выключается upstream,на который мы шлем часть тестового трафа, error_log оригинального локейшена /orig сразу заполняется ошибками вида  2018/04/26 09:37:15 [error] 24047#0: *395993 connect() failed (111: Connection refused) while connecting to upstream, client: x.x.x.x, server: xxxx.ru, request: "GET / HTTP/1.1", subrequest: "/mirror", upstream: "fastcgi://127.0.0.1:1234", host: "xxxx"  Можно как-то избавиться от этих сообщений? С уважением, Олег From mdounin на mdounin.ru Mon May 14 14:35:00 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 14 May 2018 17:35:00 +0300 Subject: =?UTF-8?B?UmU6INCk0LjQu9GM0YLRgNCw0YbQuNGPIGVycm9yX2xvZyDQtNC70Y8g0LvQvtC6?= =?UTF-8?B?0LXQudGI0L3QsC4=?= In-Reply-To: <92a4446d-5618-c21d-251b-45819a627fc2@segmento.ru> References: <92a4446d-5618-c21d-251b-45819a627fc2@segmento.ru> Message-ID: <20180514143459.GC32137@mdounin.ru> Hello! On Mon, May 14, 2018 at 05:16:34PM +0300, Panichev Oleg wrote: [...] >  Это решение работает прекрасно за исключением того момента, что когда > выключается upstream,на который мы шлем часть тестового трафа, error_log > оригинального локейшена /orig сразу заполняется ошибками вида > >  2018/04/26 09:37:15 [error] 24047#0: *395993 connect() failed (111: > Connection refused) while connecting to upstream, client: x.x.x.x, > server: xxxx.ru, request: "GET / HTTP/1.1", subrequest: "/mirror", > upstream: "fastcgi://127.0.0.1:1234", host: "xxxx" > >  Можно как-то избавиться от этих сообщений? Логгирование ошибок подзапросов происходит в рамках основного запроса. Соответственно от этих сообщений можно избавиться только выключив соответствующее логгирование для основного запроса. Ну или сделав так, чтобы ошибок не было. -- Maxim Dounin http://mdounin.ru/ From thresh на nginx.com Tue May 15 11:18:46 2018 From: thresh на nginx.com (Konstantin Pavlov) Date: Tue, 15 May 2018 14:18:46 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QtNC00LXRgNC20LrQsCBJUF9CSU5EX0FERFJFU1NfTk9fUE9SVCA=?= =?UTF-8?B?0L3QsCBDZW50T1MtNy40?= In-Reply-To: References: <1705981.ux17j1kC72@vbart-laptop> <20180514100441.GB1635@lo0.su> Message-ID: <98fa4377-daa2-48da-2ca2-122a94f98ff0@nginx.com> Здравствуйте, Илья, 14.05.2018 13:30, Илья Шипицин wrot> 14 мая 2018 г., 15:04 пользователь Ruslan Ermilov > написал: > > On Mon, May 14, 2018 at 12:14:28PM +0500, Илья Шипицин wrote: > > на днях зарелизился centos-7.5, в нем, к сожалению, все по прежнему > > > > завел тикет > > > > https://trac.nginx.org/nginx/ticket/1553 > > > > > посмотрите ? > > > > 29 апреля 2018 г., 3:40 пользователь Валентин Бартенев > > > написал: > > > > > On Saturday, 28 April 2018 15:03:49 MSK Илья Шипицин wrote: > > > > привет! > > > > > > > > поддержка IP_BIND_ADDRESS_NO_PORT официально началась в ядре 4.2, но ... > > > > ее портировали в 3.10 на CentOS-7.4 > > > > > > > > однако, портировали не очень качественно. константа определена не в том > > > > файле, в котором должна (и в котором ищет nginx) > > > > > > > > [root на xxx ~]# grep -r IP_BIND_ADDRESS_NO_PORT /usr/include/ > > > > /usr/include/linux/in.h:#define IP_BIND_ADDRESS_NO_PORT    24 > > > > [root на xxx ~]# > > > > > > > > > > > > т.е. если пакет собирать, как он собирается обычно, то поддержка > > > > IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы). > > > > > > > > скажите, вы официальные пакеты собираете каким образом ? кажется, имеет > > > > смысл поправить эту процедуру и дать эту крутую фичу пользователям > > > > CentOS-7.4 > > > > > > > > > > Дело же не в ядре (не только в нем).  На линуксах интерфейс обеспечивает > > > glibc и именно туда смотрит nginx. > > - это заголовочный файл ядра.  - это > заголовочный файл glibc.  Приложения используют . > В норме макрос IP_BIND_ADDRESS_NO_PORT есть в обоих файлах, что > означает, что поддержка есть и в ядре, и в glibc.  Утверждение о > том, что "константа определена не в том файле", ошибочное. > > Как Вам уже пытался ранее объяснять Валентин, проблема заключается > в том, что в установленной версии glibc нет поддержки этого макроса. > > Для себя Вы можете проблему решить так: > >         configure --with-cc-opt=-DIP_BIND_ADDRESS_NO_PORT=24 > > > > для себя я, конечно, решу. > > первоначально мы попали в неочевидную ловушку > 1) читаем про IP_BIND_ADDRESS_NO_PORT > 2) читаем, что начиная с centos-7.4 должно работать > 3) ставим официальный пакет > 4) не работает (но чтобы это понять, пришлось залезть в отладочный лог и > попрыгать с strace) > > в официальном пакете поправите ? Нам усиленно кажется, что исправлять это надо в RHEL/CentOS. Повесьте им багу о несоответствии интерфейсов ядра и glibc, это наилучший выход из этой ситуации. -- Konstantin Pavlov https://www.nginx.com/ From chipitsine на gmail.com Thu May 17 09:18:38 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 17 May 2018 14:18:38 +0500 Subject: =?UTF-8?B?UmU6INC/0L7QtNC00LXRgNC20LrQsCBJUF9CSU5EX0FERFJFU1NfTk9fUE9SVCA=?= =?UTF-8?B?0L3QsCBDZW50T1MtNy40?= In-Reply-To: <98fa4377-daa2-48da-2ca2-122a94f98ff0@nginx.com> References: <1705981.ux17j1kC72@vbart-laptop> <20180514100441.GB1635@lo0.su> <98fa4377-daa2-48da-2ca2-122a94f98ff0@nginx.com> Message-ID: https://bugs.centos.org/view.php?id=14828 до RHEL-овских дистрибутивов доступа нет, у CentOS сейчас 4000+ неназначенных багов. шансы на то, что RedHat бросится это чинить, думаю, дай бог, чтобы к 7.6 поправили пересоберете пакет с поддержкой опции ? 15 мая 2018 г., 16:18 пользователь Konstantin Pavlov написал: > Здравствуйте, Илья, > > 14.05.2018 13:30, Илья Шипицин wrot> 14 мая 2018 г., 15:04 пользователь > Ruslan Ermilov > > написал: > > > > On Mon, May 14, 2018 at 12:14:28PM +0500, Илья Шипицин wrote: > > > на днях зарелизился centos-7.5, в нем, к сожалению, все по прежнему > > > > > > завел тикет > > > > > > https://trac.nginx.org/nginx/ticket/1553 > > > > > > > > посмотрите ? > > > > > > 29 апреля 2018 г., 3:40 пользователь Валентин Бартенев < > vbart на nginx.com > > > > написал: > > > > > > > On Saturday, 28 April 2018 15:03:49 MSK Илья Шипицин wrote: > > > > > привет! > > > > > > > > > > поддержка IP_BIND_ADDRESS_NO_PORT официально началась в ядре > 4.2, но ... > > > > > ее портировали в 3.10 на CentOS-7.4 > > > > > > > > > > однако, портировали не очень качественно. константа определена > не в том > > > > > файле, в котором должна (и в котором ищет nginx) > > > > > > > > > > [root на xxx ~]# grep -r IP_BIND_ADDRESS_NO_PORT /usr/include/ > > > > > /usr/include/linux/in.h:#define IP_BIND_ADDRESS_NO_PORT 24 > > > > > [root на xxx ~]# > > > > > > > > > > > > > > > т.е. если пакет собирать, как он собирается обычно, то > поддержка > > > > > IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы). > > > > > > > > > > скажите, вы официальные пакеты собираете каким образом ? > кажется, имеет > > > > > смысл поправить эту процедуру и дать эту крутую фичу > пользователям > > > > > CentOS-7.4 > > > > > > > > > > > > > Дело же не в ядре (не только в нем). На линуксах интерфейс > обеспечивает > > > > glibc и именно туда смотрит nginx. > > > > - это заголовочный файл ядра. - это > > заголовочный файл glibc. Приложения используют . > > В норме макрос IP_BIND_ADDRESS_NO_PORT есть в обоих файлах, что > > означает, что поддержка есть и в ядре, и в glibc. Утверждение о > > том, что "константа определена не в том файле", ошибочное. > > > > Как Вам уже пытался ранее объяснять Валентин, проблема заключается > > в том, что в установленной версии glibc нет поддержки этого макроса. > > > > Для себя Вы можете проблему решить так: > > > > configure --with-cc-opt=-DIP_BIND_ADDRESS_NO_PORT=24 > > > > > > > > для себя я, конечно, решу. > > > > первоначально мы попали в неочевидную ловушку > > 1) читаем про IP_BIND_ADDRESS_NO_PORT > > 2) читаем, что начиная с centos-7.4 должно работать > > 3) ставим официальный пакет > > 4) не работает (но чтобы это понять, пришлось залезть в отладочный лог и > > попрыгать с strace) > > > > в официальном пакете поправите ? > > Нам усиленно кажется, что исправлять это надо в RHEL/CentOS. Повесьте > им багу о несоответствии интерфейсов ядра и glibc, это наилучший выход > из этой ситуации. > > -- > Konstantin Pavlov > https://www.nginx.com/ > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon May 21 13:12:11 2018 From: nginx-forum на forum.nginx.org (warma2d) Date: Mon, 21 May 2018 09:12:11 -0400 Subject: =?UTF-8?B?0J7RiNC40LHQutCwINC/0YDQuCDQvtGC0L/RgNCw0LLQutC1INC/0LjRgdGM0Lw=?= =?UTF-8?B?0LAg0LjQtyBQSFA=?= Message-ID: Добрый день! Проблема в том, что при попытке отправить письмо из единственного PHP скрипта index.php (который расположен /home/rima/www/public) не отправляется письмо даже стандартной функцией mail(), var_dump возвращает false. При этом установлен Sendmail, Nginx, php как fpm. Для сайта создан отдельный пул с chroot. (Принимать письма не требуется, главное отправлять.) Поскольку сайт работает через chroot, то его sendmail лежит здесь /home/rima/www/usr/sbin/ Даже через него напрямую из консоли ./sendmail можно спокойно отправить тестовое письмо, но из самого php скрипта не не удается. Всему каталогу с сайтом, директориями и файлам заданы полные права (777). mail.log выдаёт: [21-May-2018 07:31:33 America/New_York] mail() on [/public/index.php:7]: To: warma2d на ya.ru -- Headers: На тему mail кроме этого лога нигде никакие логи не увидеть. Подскажите пожалуйста что-нибудь по данному вопросу ? Заранее спасибо ! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279882,279882#msg-279882 From medvedev.yp на gmail.com Mon May 21 13:13:12 2018 From: medvedev.yp на gmail.com (Iurii Medvedev) Date: Mon, 21 May 2018 17:13:12 +0400 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0L7RgtC/0YDQsNCy0LrQtSDQv9C40YE=?= =?UTF-8?B?0YzQvNCwINC40LcgUEhQ?= In-Reply-To: References: Message-ID: Это никак не связано с nginx On Mon, May 21, 2018 at 5:12 PM warma2d wrote: > Добрый день! > > Проблема в том, что при попытке отправить письмо из единственного PHP > скрипта index.php (который расположен /home/rima/www/public) не > отправляется > письмо даже стандартной функцией mail(), var_dump возвращает false. > > При этом установлен Sendmail, Nginx, php как fpm. Для сайта создан > отдельный > пул с chroot. > (Принимать письма не требуется, главное отправлять.) > > Поскольку сайт работает через chroot, то его sendmail лежит здесь > /home/rima/www/usr/sbin/ > Даже через него напрямую из консоли ./sendmail можно спокойно отправить > тестовое письмо, но из самого php скрипта не не удается. Всему каталогу с > сайтом, директориями и файлам заданы полные права (777). > > mail.log выдаёт: > [21-May-2018 07:31:33 America/New_York] mail() on [/public/index.php:7]: > To: > warma2d на ya.ru -- Headers: > > На тему mail кроме этого лога нигде никакие логи не увидеть. > > Подскажите пожалуйста что-нибудь по данному вопросу ? > > Заранее спасибо ! > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,279882,279882#msg-279882 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- With best wishes Iurii Medvedev ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon May 21 13:21:06 2018 From: nginx-forum на forum.nginx.org (warma2d) Date: Mon, 21 May 2018 09:21:06 -0400 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0L7RgtC/0YDQsNCy0LrQtSDQv9C40YE=?= =?UTF-8?B?0YzQvNCwINC40LcgUEhQ?= In-Reply-To: References: Message-ID: <6fe961f1a59777514642381efbd0c22a.NginxMailingListRussian@forum.nginx.org> Если с Nginx никак не связано, то в чем предположительно может быть проблема, в какую сторону копать ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279882,279884#msg-279884 From kvt на kvtsoftware.com Mon May 21 13:43:37 2018 From: kvt на kvtsoftware.com (kvt на kvtsoftware.com) Date: Mon, 21 May 2018 16:43:37 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0L7RgtC/0YDQsNCy0LrQtSDQv9C40YE=?= =?UTF-8?B?0YzQvNCwINC40LcgUEhQ?= In-Reply-To: <6fe961f1a59777514642381efbd0c22a.NginxMailingListRussian@forum.nginx.org> References: <6fe961f1a59777514642381efbd0c22a.NginxMailingListRussian@forum.nginx.org> Message-ID: <1976581526910217@web43j.yandex.ru> А в php.ini сайта прописан путь и необходимые параметры к его sendmail? 21.05.2018, 16:21, "warma2d" : > Если с Nginx никак не связано, то в чем предположительно может быть > проблема, в какую сторону копать ? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279882,279884#msg-279884 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From a.kadjy на gmail.com Mon May 21 14:33:54 2018 From: a.kadjy на gmail.com (akadjy) Date: Mon, 21 May 2018 17:33:54 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0L7RgtC/0YDQsNCy0LrQtSDQv9C40YE=?= =?UTF-8?B?0YzQvNCwINC40LcgUEhQ?= In-Reply-To: <1976581526910217@web43j.yandex.ru> References: <6fe961f1a59777514642381efbd0c22a.NginxMailingListRussian@forum.nginx.org> <1976581526910217@web43j.yandex.ru> Message-ID: > А в php.ini сайта прописан путь и необходимые параметры к его sendmail? это актуально только для windows 21 мая 2018 г., 16:43 пользователь написал: > А в php.ini сайта прописан путь и необходимые параметры к его sendmail? > > 21.05.2018, 16:21, "warma2d" : >> Если с Nginx никак не связано, то в чем предположительно может быть >> проблема, в какую сторону копать ? >> >> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279882,279884#msg-279884 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vovansystems на gmail.com Mon May 21 17:23:57 2018 From: vovansystems на gmail.com (VovansystemS) Date: Mon, 21 May 2018 20:23:57 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0L7RgtC/0YDQsNCy0LrQtSDQv9C40YE=?= =?UTF-8?B?0YzQvNCwINC40LcgUEhQ?= In-Reply-To: References: Message-ID: добрый вечер, > Поскольку сайт работает через chroot, то его sendmail лежит здесь > /home/rima/www/usr/sbin/ > Даже через него напрямую из консоли ./sendmail можно спокойно отправить > тестовое письмо, но из самого php скрипта не не удается. Всему каталогу с > сайтом, директориями и файлам заданы полные права (777). а как Вы проверяете? chroot /home/rima/www/ а потом sendmail ? мне кажется у Вас sendmail статически не слинкован и ему чего-то не хватает, посмотрите через ldd sendmail также для всякой крипты (отправка через TLS) внутри чрута должны быть /dev/random /dev/urandom и прочие устройства, но такие ошибки можно отловить интерактивно в консоли From nginx на kinetiksoft.com Tue May 22 16:45:35 2018 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Tue, 22 May 2018 19:45:35 +0300 Subject: =?UTF-8?B?0J3QtdC+0LHRitGP0YHQvdC40LzRi9C5IDUwMyDQv9GA0LggbGltaXRfY29ubg==?= Message-ID: <60fa893f-c7cf-f6c7-f57d-3e8aeaf651f6@kinetiksoft.com> Здравствуйте! Периодически nginx начинает отдавать 503 там где не должен. А именно. Есть следующая конфигурация limit_conn: geo $binaddrnotownproxy {         default $binary_remote_addr;         51.ipv4/32 "";         2001:ipv6::/56 "";         10.ipv4/32 ""; } limit_conn_zone $binaddrnotownproxy zone=dynamic:2000m; 2000m взял уже от безысходности, так как думал, что переполняется область памяти. Такая схема используется, чтоб исключить некоторые адреса из лимитирования. И есть обычный, проксирующий через proxy_pass локейшен, в котором задано limit_conn dynamic 10; Регулярно, хоть и достаточно редко в ответ на запросы в этот локейшен проскакивает 503 тогда, когда оно совсем возникать не должно. Например, вот следующий лог. В этот локейшен ходит заббикс (фактически curl). Он тоже иногда получает 503. Я вырезал из лога все запросы с его IP. > 2a01:IPv6|-|22/May/2018:06:35:15 +0300|GET / > HTTP/1.1|200|117926|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.109 > 2a01:IPv6|-|22/May/2018:06:36:15 +0300|GET / > HTTP/1.1|200|117926|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.088 > 2a01:IPv6|-|22/May/2018:06:37:16 +0300|GET / > HTTP/1.1|200|117921|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.096 > 2a01:IPv6|-|22/May/2018:06:38:16 +0300|GET / > HTTP/1.1|200|117922|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.105 > 2a01:IPv6|-|22/May/2018:06:39:16 +0300|GET / > HTTP/1.1|200|117922|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.136 > 2a01:IPv6|-|22/May/2018:06:40:16 +0300|GET / > HTTP/1.1|200|117917|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.100 > 2a01:IPv6|-|22/May/2018:06:41:17 +0300|GET / > HTTP/1.1|200|117917|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.096 > 2a01:IPv6|-|22/May/2018:06:42:17 +0300|GET / > HTTP/1.1|200|117921|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.119 > 2a01:IPv6|-|22/May/2018:06:43:17 +0300|GET / > HTTP/1.1|200|117913|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.118 > 2a01:IPv6|-|22/May/2018:06:44:17 +0300|GET / > HTTP/1.1|200|117904|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.093 > 2a01:IPv6|-|22/May/2018:06:45:17 +0300|GET / > HTTP/1.1|200|117908|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.131 > 2a01:IPv6|-|22/May/2018:06:46:18 +0300|GET / > HTTP/1.1|200|117902|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.148 > 2a01:IPv6|-|22/May/2018:06:47:18 +0300|GET / > HTTP/1.1|200|117902|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.096 > 2a01:IPv6|-|22/May/2018:06:48:19 +0300|GET / > HTTP/1.1|200|117901|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.093 > 2a01:IPv6|-|22/May/2018:06:49:19 +0300|GET / > HTTP/1.1|200|117916|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.104 > 2a01:IPv6|-|22/May/2018:07:15:25 +0300|GET / > HTTP/1.1|200|117907|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > 6.1; Trident/6.0)|0.095 > 2a01:IPv6|-|22/May/2018:07:16:25 +0300|GET / > HTTP/1.1|503|608|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; > Trident/6.0)|0.000 Обращаю внимание, что идет серия быстрых запросов раз в минуту, на которые возвращается 200, а потом очереднй внезапно получает 503. Проясните, пожалуйста, кто-нибудь ситуацию. Debian Stretch, nginx из официальных репозиториев. # nginx -V nginx version: nginx/1.14.0 built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) built with OpenSSL 1.1.0f  25 May 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.14.0/debian/debuild-base/nginx-1.14.0=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' С уважением, Иван. From mdounin на mdounin.ru Tue May 22 18:22:49 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 22 May 2018 21:22:49 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQvtCx0YrRj9GB0L3QuNC80YvQuSA1MDMg0L/RgNC4IGxpbWl0X2Nv?= =?UTF-8?B?bm4=?= In-Reply-To: <60fa893f-c7cf-f6c7-f57d-3e8aeaf651f6@kinetiksoft.com> References: <60fa893f-c7cf-f6c7-f57d-3e8aeaf651f6@kinetiksoft.com> Message-ID: <20180522182249.GL32137@mdounin.ru> Hello! On Tue, May 22, 2018 at 07:45:35PM +0300, Иван wrote: > Периодически nginx начинает отдавать 503 там где не должен. А именно. > Есть следующая конфигурация limit_conn: > > geo $binaddrnotownproxy { >         default $binary_remote_addr; >         51.ipv4/32 ""; >         2001:ipv6::/56 ""; >         10.ipv4/32 ""; > } > > > limit_conn_zone $binaddrnotownproxy zone=dynamic:2000m; > > > 2000m взял уже от безысходности, так как думал, что переполняется > область памяти. > > > Такая схема используется, чтоб исключить некоторые адреса из лимитирования. > > > И есть обычный, проксирующий через proxy_pass локейшен, в котором задано > > limit_conn dynamic 10; > > Регулярно, хоть и достаточно редко в ответ на запросы в этот локейшен > проскакивает 503 тогда, когда оно совсем возникать не должно. Например, > вот следующий лог. В этот локейшен ходит заббикс (фактически curl). Он > тоже иногда получает 503. Я вырезал из лога все запросы с его IP. [...] > > 2a01:IPv6|-|22/May/2018:07:15:25 +0300|GET / > > HTTP/1.1|200|117907|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT > > 6.1; Trident/6.0)|0.095 > > 2a01:IPv6|-|22/May/2018:07:16:25 +0300|GET / > > HTTP/1.1|503|608|-|Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; > > Trident/6.0)|0.000 > > Обращаю внимание, что идет серия быстрых запросов раз в минуту, на > которые возвращается 200, а потом очереднй внезапно получает 503. > Проясните, пожалуйста, кто-нибудь ситуацию. Debian Stretch, nginx из > официальных репозиториев. Для начала стоит убедится, что именно nginx вернул 503. Потому как, скажем, Apache возвращает 503, если не может добраться до бэкенда, меж тем регулярно меняющийся размер ответа позволяет предположить, что ресурс, к которому ходит заббикс, не статический. Да и размер 608 не соответствует размеру стандартной 503-ей ошибки nginx'а. Узнать можно, например, заглянув в error log - если ошибку вернул nginx, там будет ругань про "limiting connections by zone...", по умолчанию на уровне error. Впрочем, даже если ответ от nginx'а - приведённый лог не даёт оснований считать, что limit_conn не должен был сработать. Запросы логгируются в access log в момент их завершения, так что смотреть надо в первую очередь на те запросы, которые логгируются после запроса, получившего в ответ 503, а не до него. -- Maxim Dounin http://mdounin.ru/ From constantine на mellodesign.ru Tue May 29 11:56:53 2018 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Tue, 29 May 2018 14:56:53 +0300 Subject: =?UTF-8?B?0J7RgtC+0LHRgNCw0LbQtdC90LjQtSBlcnJvcl9wYWdlINGBINC/0L7QvNC+0Yk=?= =?UTF-8?B?0YzRjiDRgdCw0LnRgtCw?= Message-ID: Здравствуйте! Нужна помощь по настройки error_page, нагуглить решение не получилось. Есть несколько локейшенов вида location ~ ^/sites/[^/]+/files/.*\.php$ { deny all; return 404; } location ~ \..*/.*\.php$ { return 404; } и дериктива error_page 404 /index.php это аналог из .htaccess друпала 7 ErrorDocument 404 /index.php Суть в том, что при попытки открыть файл по эти локейшенам отдается 404 от nginx, а хочется чтобы показало от друпала, мол страницы нету. Подскажите как такое реализовать? Я что-то не соображу никак. Спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 29 12:03:52 2018 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Tue, 29 May 2018 08:03:52 -0400 Subject: =?UTF-8?B?UmU6INCe0YLQvtCx0YDQsNC20LXQvdC40LUgZXJyb3IgcGFnZSDRgSDQv9C+0Lw=?= =?UTF-8?B?0L7RidGM0Y4g0YHQsNC50YLQsA==?= In-Reply-To: References: Message-ID: <5101197a4aa460da7deebb691f823756.NginxMailingListRussian@forum.nginx.org> location ~ ^/sites/[^/]+/files/.*\.php$ { deny all; error_page 404 /index.php; return 404; } location ~ \..*/.*\.php$ { error_page 404 /index.php ; return 404; } как-то так Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279975,279976#msg-279976 From constantine на mellodesign.ru Tue May 29 13:16:10 2018 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Tue, 29 May 2018 16:16:10 +0300 Subject: =?UTF-8?B?UmU6INCe0YLQvtCx0YDQsNC20LXQvdC40LUgZXJyb3IgcGFnZSDRgSDQv9C+0Lw=?= =?UTF-8?B?0L7RidGM0Y4g0YHQsNC50YLQsA==?= In-Reply-To: <5101197a4aa460da7deebb691f823756.NginxMailingListRussian@forum.nginx.org> References: <5101197a4aa460da7deebb691f823756.NginxMailingListRussian@forum.nginx.org> Message-ID: 2018-05-29 15:03 GMT+03:00 Dmytro Lavryk : > location ~ ^/sites/[^/]+/files/.*\.php$ { > deny all; > error_page 404 /index.php; > return 404; > } > > location ~ \..*/.*\.php$ { > error_page 404 /index.php ; > return 404; > } > > как-то так > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,279975,279976#msg-279976 > > _______________________________________________ > 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 May 30 23:52:10 2018 From: nginx-forum на forum.nginx.org (larsn) Date: Wed, 30 May 2018 19:52:10 -0400 Subject: Upstream zone Message-ID: День добрый. Столкнулся с высоким потреблением CPU при добавлении в конфиге апстримов директивы zone. Как было до upstream backend { server server1:8080 weight=860; server server2:8080 weight=860; server server3:8080 weight=860; ..... } Как стало после upstream backend { zone upstream_backend 1m; server server1:8080 weight=860; server server2:8080 weight=860; server server3:8080 weight=860; ..... } При значительной нагрузке потребление CPU взлетает неимоверно. Стоит отметить, что upstream серверов в данной группе достаточно много. Около 2000 штук. Может ли это быть связано с rw локами шаренной памяти? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279995,279995#msg-279995 From maxim на nginx.com Thu May 31 07:50:33 2018 From: maxim на nginx.com (Maxim Konovalov) Date: Thu, 31 May 2018 10:50:33 +0300 Subject: Fwd: nginx is hiring: tech writer position for the -unit project In-Reply-To: <07eee8a8-0bca-27de-c7a1-1a58ca88b1c3@nginx.com> References: <07eee8a8-0bca-27de-c7a1-1a58ca88b1c3@nginx.com> Message-ID: Привет. Возможно, здесь тоже кого-то заинтересует: мы ищем технического писателя на проект NGINX Unit. Подробности по ссылке ниже. -------- Forwarded Message -------- Subject: nginx is hiring: tech writer position for the -unit project Date: Thu, 31 May 2018 10:48:35 +0300 From: Maxim Konovalov Organization: Nginx, Inc. To: unit на nginx.org Hello, this is just a heads up: we are looking for a technical writer to work on NGINX Unit project documentation, see details here: https://www.nginx.com/careers/current-openings/?job_id=1187667 More on -unit project: http://unit.nginx.org. This is full time work in Moscow office, no remote option available at this time. Thanks, Maxim -- Maxim Konovalov -- Maxim Konovalov From ru на nginx.com Thu May 31 14:06:36 2018 From: ru на nginx.com (Ruslan Ermilov) Date: Thu, 31 May 2018 17:06:36 +0300 Subject: Upstream zone In-Reply-To: References: Message-ID: <20180531140636.GB86722@lo0.su> On Wed, May 30, 2018 at 07:52:10PM -0400, larsn wrote: > День добрый. > Столкнулся с высоким потреблением CPU при добавлении в конфиге апстримов > директивы zone. > Как было до > > upstream backend { > server server1:8080 weight=860; > server server2:8080 weight=860; > server server3:8080 weight=860; > ..... > } > > Как стало после > > upstream backend { > zone upstream_backend 1m; > server server1:8080 weight=860; > server server2:8080 weight=860; > server server3:8080 weight=860; > ..... > } > > При значительной нагрузке потребление CPU взлетает неимоверно. > Стоит отметить, что upstream серверов в данной группе достаточно много. > Около 2000 штук. > Может ли это быть связано с rw локами шаренной памяти? Интересует вывод "uname -a", "cat /proc/cpuinfo", "nginx -V". Сколько рабочих процессов в nginx? Какой балансировщик в upstream backend? Просьба протестировать Вашу конфигурацию с одним из балансировщиков ip_hash или hash (неконсистентный), патч ниже должен помочь: # HG changeset patch # User Ruslan Ermilov # Date 1527775383 -10800 # Thu May 31 17:03:03 2018 +0300 # Node ID 927cb2e79ea0ab79dae171325f3203601bbd0962 # Parent 760df963f0e03ff300cf1bc1a81d4745730457b0 Upstream: improved peer selection concurrency for hash and ip_hash. diff --git a/src/http/modules/ngx_http_upstream_hash_module.c b/src/http/modules/ngx_http_upstream_hash_module.c --- a/src/http/modules/ngx_http_upstream_hash_module.c +++ b/src/http/modules/ngx_http_upstream_hash_module.c @@ -176,7 +176,7 @@ ngx_http_upstream_get_hash_peer(ngx_peer ngx_log_debug1(NGX_LOG_DEBUG_HTTP, pc->log, 0, "get hash peer, try: %ui", pc->tries); - ngx_http_upstream_rr_peers_wlock(hp->rrp.peers); + ngx_http_upstream_rr_peers_rlock(hp->rrp.peers); if (hp->tries > 20 || hp->rrp.peers->single) { ngx_http_upstream_rr_peers_unlock(hp->rrp.peers); @@ -228,6 +228,8 @@ ngx_http_upstream_get_hash_peer(ngx_peer goto next; } + ngx_http_upstream_rr_peer_lock(hp->rrp.peers, peer); + ngx_log_debug2(NGX_LOG_DEBUG_HTTP, pc->log, 0, "get hash peer, value:%uD, peer:%ui", hp->hash, p); @@ -250,6 +252,8 @@ ngx_http_upstream_get_hash_peer(ngx_peer next: + ngx_http_upstream_rr_peer_unlock(hp->rrp.peers, peer); + if (++hp->tries > 20) { ngx_http_upstream_rr_peers_unlock(hp->rrp.peers); return hp->get_rr_peer(pc, &hp->rrp); @@ -268,6 +272,7 @@ ngx_http_upstream_get_hash_peer(ngx_peer peer->checked = now; } + ngx_http_upstream_rr_peer_unlock(hp->rrp.peers, peer); ngx_http_upstream_rr_peers_unlock(hp->rrp.peers); hp->rrp.tried[n] |= m; diff --git a/src/http/modules/ngx_http_upstream_ip_hash_module.c b/src/http/modules/ngx_http_upstream_ip_hash_module.c --- a/src/http/modules/ngx_http_upstream_ip_hash_module.c +++ b/src/http/modules/ngx_http_upstream_ip_hash_module.c @@ -161,7 +161,7 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p /* TODO: cached */ - ngx_http_upstream_rr_peers_wlock(iphp->rrp.peers); + ngx_http_upstream_rr_peers_rlock(iphp->rrp.peers); if (iphp->tries > 20 || iphp->rrp.peers->single) { ngx_http_upstream_rr_peers_unlock(iphp->rrp.peers); @@ -201,6 +201,8 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p ngx_log_debug2(NGX_LOG_DEBUG_HTTP, pc->log, 0, "get ip hash peer, hash: %ui %04XL", p, (uint64_t) m); + ngx_http_upstream_rr_peer_lock(iphp->rrp.peers, peer); + if (peer->down) { goto next; } @@ -220,6 +222,8 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p next: + ngx_http_upstream_rr_peer_unlock(iphp->rrp.peers, peer); + if (++iphp->tries > 20) { ngx_http_upstream_rr_peers_unlock(iphp->rrp.peers); return iphp->get_rr_peer(pc, &iphp->rrp); @@ -238,6 +242,7 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p peer->checked = now; } + ngx_http_upstream_rr_peer_unlock(iphp->rrp.peers, peer); ngx_http_upstream_rr_peers_unlock(iphp->rrp.peers); iphp->rrp.tried[n] |= m;