From nginx-forum на forum.nginx.org Mon Jul 1 14:01:36 2019 From: nginx-forum на forum.nginx.org (Pianinorama) Date: Mon, 01 Jul 2019 10:01:36 -0400 Subject: =?UTF-8?B?0J/RgNC+0YjRgyDRgNCw0LfRgNC10YjQuNGC0Ywg0YHQuNGC0YPQsNGG0LjRjiA=?= =?UTF-8?B?0L/QviDRgdC40L3RgtCw0LrRgdC40YHRgy4=?= Message-ID: <16388e52fa0cf7fabd9de69b9458e67e.NginxMailingListRussian@forum.nginx.org> Добрый день. Есть вот такой фрагмент конфига: location ~* ^(.*)(/static/.*)(jpg|jpeg|png)$ { set $webp $1$2webp; set $rootFile "${document_root}${webp}"; if ($http_accept ~* "webp"){set $test A;} if (-f $rootFile) {set $test "${test}B";} if ($test = AB) { add_header Vary Accept; rewrite (.*) $webp break; } } Хотелось уйти от большого количества IF. Сделал вот так (опускаем location): set $webp $1$2webp; set $rootFile "${document_root}${webp}"; map "$http_accept ~*" $test { "webp" A;} try_files $rootFile {set $test "${test}B";} if ($test = AB) { add_header Vary Accept; rewrite (.*) $webp break; } Есть сильное сомнение что сработает конструкция в try_files. Да и в рамках map тоже сильно сомневаюсь. Сможете кто-то подсказать, как сделать проще и изящнее? Заранее спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284703,284703#msg-284703 From nginx на mva.name Tue Jul 2 07:21:53 2019 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 02 Jul 2019 10:21:53 +0300 Subject: =?UTF-8?B?W1VuaXRdINCc0LjQs9GA0LDRhtC40Y8g0YEgZmFzdGNnaSDQuCDQtdGRINC/0L4=?= =?UTF-8?B?0LTQstC+0LTQvdGL0LUg0LrQsNC80L3QuA==?= Message-ID: <5415045.4z6ftBVuLT@note> Здравствуйте! Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз столкнулся с проблемой того, что у fastcgi есть такая полезная штука как split_path_info, где можно задать какая часть URI является значением SCRIPT_NAME (да и вообще существует возможность динамического формирования этого значения при запросе), а какая - идёт в PATH_INFO. Сама по себе переменная PATH_INFO (как доступное значение для приложения внутри массива $_SERVER) - ещё пол беды. Есть, конечно, приложения, которые рассчитывают на него, но это вторично по отношению к тому, что ну уж **очень** не хватает возможности динамически задавать значение "script" (aka SCRIPT_NAME в fcgi) для приложения в Юните. Т.е. чтобы весь URI как есть передался в сообщённый в заголовках (ну а как ещё? Не вижу иного способа передать информацию Юниту от NgX) скрипт. Без такой возможности приходится городить по 100500 блоков application для каждого потенциально возможного "script" (хардкодить все значения, в общем). Что, если честно, делает меня грустной пандой. Соответствено, сопровождение большинства приложений, которые из коробки работают с ЧПУ (а таких нынче большинство) превращается в пытку :'( А уж если они ещё и о SEO решают заботиться по примеру вордпресса и внаглую редиректить запросы типа "/scriptname.php?$uri" на "/?$uri" (явно полагаясь на то, что SCRIPT_NAME им передаётся и так), всё выходит на новый уровень... В общем, подскажите, пожалуйста: 1) есть ли возможность как-то передавать значения конфигурационных директив приложения в заголовках запроса? 2) каковы шансы того, что если п.1 не является осуществимым сейчас, вы это сделаете по реквесту из списка рассылки? :) 2а) и каковы шансы того, что это произойдёт в ближайших релизах? :) From nginx на kinetiksoft.com Tue Jul 2 09:42:08 2019 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Tue, 2 Jul 2019 12:42:08 +0300 Subject: =?UTF-8?B?UmU6IFtVbml0XSDQnNC40LPRgNCw0YbQuNGPINGBIGZhc3RjZ2kg0Lgg0LXRkSA=?= =?UTF-8?B?0L/QvtC00LLQvtC00L3Ri9C1INC60LDQvNC90Lg=?= In-Reply-To: <5415045.4z6ftBVuLT@note> References: <5415045.4z6ftBVuLT@note> Message-ID: Здравствуйте! Кстати, хотел бы присоединиться к вопросу, с давно тут озвученной "хотелкой" - иметь возможность передавать (как вариант транслируя из http_VARNAME) переменные типа $_SERVER['REMOTE_ADDR'] , $_SERVER[' HTTPS'] напрямую в пыху под юнитом, а не загонять сонм готовых приложений в обертки делающие $_SERVER['HTTPS']=$_SERVER['HTTP_X_SPECIALLY_FOR_UNIT_HTTPS']. Прям вот всё еще останавливает от повсеместной интеграции этого замечательного продукта в нашу инфраструктуру. С уважением, Иван. 02.07.2019 10:21, Vadim A. Misbakh-Soloviov пишет: > Здравствуйте! > > Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз > столкнулся с проблемой того, что у fastcgi есть такая полезная штука как > split_path_info, где можно задать какая часть URI является значением > SCRIPT_NAME (да и вообще существует возможность динамического формирования > этого значения при запросе), а какая - идёт в PATH_INFO. > > Сама по себе переменная PATH_INFO (как доступное значение для приложения > внутри массива $_SERVER) - ещё пол беды. Есть, конечно, приложения, которые > рассчитывают на него, но это вторично по отношению к тому, что ну уж **очень** > не хватает возможности динамически задавать значение "script" (aka SCRIPT_NAME > в fcgi) для приложения в Юните. > > Т.е. чтобы весь URI как есть передался в сообщённый в заголовках (ну а как > ещё? Не вижу иного способа передать информацию Юниту от NgX) скрипт. > > Без такой возможности приходится городить по 100500 блоков application для > каждого потенциально возможного "script" (хардкодить все значения, в общем). > Что, если честно, делает меня грустной пандой. > > Соответствено, сопровождение большинства приложений, которые из коробки > работают с ЧПУ (а таких нынче большинство) превращается в пытку :'( > А уж если они ещё и о SEO решают заботиться по примеру вордпресса и внаглую > редиректить запросы типа "/scriptname.php?$uri" на "/?$uri" (явно полагаясь на > то, что SCRIPT_NAME им передаётся и так), всё выходит на новый уровень... > > В общем, подскажите, пожалуйста: > 1) есть ли возможность как-то передавать значения конфигурационных директив > приложения в заголовках запроса? > 2) каковы шансы того, что если п.1 не является осуществимым сейчас, вы это > сделаете по реквесту из списка рассылки? :) > 2а) и каковы шансы того, что это произойдёт в ближайших релизах? :) > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From onokonem на gmail.com Tue Jul 2 17:39:53 2019 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 2 Jul 2019 10:39:53 -0700 Subject: =?UTF-8?B?dW5pdCtnbyAtINGA0LDRgdGB0LrQsNC30LDRgtGMINC90LAg0LrQvtC90YTQtQ==?= Message-ID: коллеги, скажите если я, как представитель ПК конференции https://golangconf.ru/2019, хочу позвать авторов Unit рассказать про применение их продукта для go - мне кому написать? спасибо From vbart на nginx.com Tue Jul 2 17:49:30 2019 From: vbart на nginx.com (Valentin V. Bartenev) Date: Tue, 02 Jul 2019 20:49:30 +0300 Subject: =?UTF-8?B?UmU6IFtVbml0XSDQnNC40LPRgNCw0YbQuNGPINGBIGZhc3RjZ2kg0Lgg0LXRkSA=?= =?UTF-8?B?0L/QvtC00LLQvtC00L3Ri9C1INC60LDQvNC90Lg=?= In-Reply-To: <5415045.4z6ftBVuLT@note> References: <5415045.4z6ftBVuLT@note> Message-ID: <4666370.shvzXya9Df@vbart-workstation> On Tuesday 02 July 2019 10:21:53 Vadim A. Misbakh-Soloviov wrote: > Здравствуйте! > > Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз > столкнулся с проблемой того, что у fastcgi есть такая полезная штука как > split_path_info, где можно задать какая часть URI является значением > SCRIPT_NAME (да и вообще существует возможность динамического формирования > этого значения при запросе), а какая - идёт в PATH_INFO. Есть мысль реализовать PATH_INFO в PHP-модуле по типу AcceptPathInfo в Apache и fastcgi_split_path_info ^(.+\.php)(.*)$; в nginx. https://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo Вопрос, есть ли случаи, когда нужно что-то отличное от ^(.+\.php)(.*)$? > > Сама по себе переменная PATH_INFO (как доступное значение для приложения > внутри массива $_SERVER) - ещё пол беды. Есть, конечно, приложения, которые > рассчитывают на него, но это вторично по отношению к тому, что ну уж **очень** > не хватает возможности динамически задавать значение "script" (aka SCRIPT_NAME > в fcgi) для приложения в Юните. Сейчас, если не указывать "script", то он формируется из URI, а если URI заканчивается на /, то к нему добавляется значение "index". > > Т.е. чтобы весь URI как есть передался в сообщённый в заголовках (ну а как > ещё? Не вижу иного способа передать информацию Юниту от NgX) скрипт. > > Без такой возможности приходится городить по 100500 блоков application для > каждого потенциально возможного "script" (хардкодить все значения, в общем). > Что, если честно, делает меня грустной пандой. > > Соответствено, сопровождение большинства приложений, которые из коробки > работают с ЧПУ (а таких нынче большинство) превращается в пытку :'( > А уж если они ещё и о SEO решают заботиться по примеру вордпресса и внаглую > редиректить запросы типа "/scriptname.php?$uri" на "/?$uri" (явно полагаясь на > то, что SCRIPT_NAME им передаётся и так), всё выходит на новый уровень... > > В общем, подскажите, пожалуйста: > 1) есть ли возможность как-то передавать значения конфигурационных директив > приложения в заголовках запроса? > 2) каковы шансы того, что если п.1 не является осуществимым сейчас, вы это > сделаете по реквесту из списка рассылки? :) > 2а) и каковы шансы того, что это произойдёт в ближайших релизах? :) [..] На самом деле самый правильный способ разруливать все эти хитросплетения способов адресации php скриптов - это написать единый index.php для всего приложения, на который направлять все запросы и там уже разбирать на составляющие и подключать необходимые скрипты. Почему сами php-разработчики приложений так не делают - для меня большая загадка. Однако приходится иметь дело с тем, что есть. Проблема необходимости гибко настраивать все переменные запроса - вполне понятна. Сейчас появился роутинг и на его базе уже планируется сделать возможность переопределения этих переменных. From vbart на nginx.com Tue Jul 2 17:59:02 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 02 Jul 2019 20:59:02 +0300 Subject: =?UTF-8?B?UmU6IFtVbml0XSDQnNC40LPRgNCw0YbQuNGPINGBIGZhc3RjZ2kg0Lgg0LXRkSA=?= =?UTF-8?B?0L/QvtC00LLQvtC00L3Ri9C1INC60LDQvNC90Lg=?= In-Reply-To: <4666370.shvzXya9Df@vbart-workstation> References: <5415045.4z6ftBVuLT@note> <4666370.shvzXya9Df@vbart-workstation> Message-ID: <2939676.HxquEBFlvk@vbart-workstation> On Tuesday 02 July 2019 20:49:30 Valentin V. Bartenev wrote: > On Tuesday 02 July 2019 10:21:53 Vadim A. Misbakh-Soloviov wrote: > > Здравствуйте! > > > > Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз > > столкнулся с проблемой того, что у fastcgi есть такая полезная штука как > > split_path_info, где можно задать какая часть URI является значением > > SCRIPT_NAME (да и вообще существует возможность динамического формирования > > этого значения при запросе), а какая - идёт в PATH_INFO. > > Есть мысль реализовать PATH_INFO в PHP-модуле по типу AcceptPathInfo > в Apache и fastcgi_split_path_info ^(.+\.php)(.*)$; в nginx. > > https://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo > > Вопрос, есть ли случаи, когда нужно что-то отличное от ^(.+\.php)(.*)$? > > > > > > Сама по себе переменная PATH_INFO (как доступное значение для приложения > > внутри массива $_SERVER) - ещё пол беды. Есть, конечно, приложения, которые > > рассчитывают на него, но это вторично по отношению к тому, что ну уж **очень** > > не хватает возможности динамически задавать значение "script" (aka SCRIPT_NAME > > в fcgi) для приложения в Юните. > > Сейчас, если не указывать "script", то он формируется из URI, а если URI > заканчивается на /, то к нему добавляется значение "index". > > > > > > Т.е. чтобы весь URI как есть передался в сообщённый в заголовках (ну а как > > ещё? Не вижу иного способа передать информацию Юниту от NgX) скрипт. > > > > Без такой возможности приходится городить по 100500 блоков application для > > каждого потенциально возможного "script" (хардкодить все значения, в общем). > > Что, если честно, делает меня грустной пандой. > > > > Соответствено, сопровождение большинства приложений, которые из коробки > > работают с ЧПУ (а таких нынче большинство) превращается в пытку :'( > > А уж если они ещё и о SEO решают заботиться по примеру вордпресса и внаглую > > редиректить запросы типа "/scriptname.php?$uri" на "/?$uri" (явно полагаясь на > > то, что SCRIPT_NAME им передаётся и так), всё выходит на новый уровень... > > > > В общем, подскажите, пожалуйста: > > 1) есть ли возможность как-то передавать значения конфигурационных директив > > приложения в заголовках запроса? > > 2) каковы шансы того, что если п.1 не является осуществимым сейчас, вы это > > сделаете по реквесту из списка рассылки? :) > > 2а) и каковы шансы того, что это произойдёт в ближайших релизах? :) > [..] > > На самом деле самый правильный способ разруливать все эти хитросплетения > способов адресации php скриптов - это написать единый index.php для всего > приложения, на который направлять все запросы и там уже разбирать на > составляющие и подключать необходимые скрипты. > > Почему сами php-разработчики приложений так не делают - для меня большая > загадка. Однако приходится иметь дело с тем, что есть. > > Проблема необходимости гибко настраивать все переменные запроса - вполне > понятна. Сейчас появился роутинг и на его базе уже планируется сделать > возможность переопределения этих переменных. > Задел кнопку и письмо ушло раньше времени. PATH_INFO в простом виде, типа fastcgi_split_path_info ^(.+\.php)(.*)$ думаю сделаем уже в ближайшем релизе к концу месяца. Более хитрую конфигурацию для переопределения произвольных переменных из маршрутов стоит ожидать не раньше осени. Концепция заключается не в том, чтобы передавать всё из nginx в заголовках, раскладывая запрос в нём всякими сложными правилами, а получать запрос как есть в исходном виде (от nginx или напрямую от клиента) и дальше уже вычленять из него всё необходимое. Плюс что-то типа realip-модуля для случаев нахождения Unit-а за реверсивным прокси. -- Валентин Бартенев From vbart на nginx.com Tue Jul 2 18:36:45 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 02 Jul 2019 21:36:45 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQrZ28gLSDRgNCw0YHRgdC60LDQt9Cw0YLRjCDQvdCwINC60L7QvdGE?= =?UTF-8?B?0LU=?= In-Reply-To: References: Message-ID: <7736547.KZRCRYGKdz@vbart-workstation> On Tuesday 02 July 2019 10:39:53 Daniel Podolsky wrote: > коллеги, скажите > > если я, как представитель ПК конференции https://golangconf.ru/2019, > хочу позвать авторов Unit рассказать про применение их продукта для go > - мне кому написать? [..] Мы в конференциях Бунина время от времени участвуем и среди нас даже постоянный представитель ПК HL++ есть. Писать можно мне на почту по поводу любых конференций. Что касается Golang Conf 2019, то, увы, но скорее всего не получится. -- Валентин Бартенев From onokonem на gmail.com Tue Jul 2 20:33:08 2019 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 2 Jul 2019 13:33:08 -0700 Subject: =?UTF-8?B?UmU6IHVuaXQrZ28gLSDRgNCw0YHRgdC60LDQt9Cw0YLRjCDQvdCwINC60L7QvdGE?= =?UTF-8?B?0LU=?= In-Reply-To: <7736547.KZRCRYGKdz@vbart-workstation> References: <7736547.KZRCRYGKdz@vbart-workstation> Message-ID: Спасибо за информацию. И жаль, что не получится... On Tue, 2 Jul 2019 at 11:36, Валентин Бартенев wrote: > On Tuesday 02 July 2019 10:39:53 Daniel Podolsky wrote: > > коллеги, скажите > > > > если я, как представитель ПК конференции https://golangconf.ru/2019, > > хочу позвать авторов Unit рассказать про применение их продукта для go > > - мне кому написать? > [..] > > Мы в конференциях Бунина время от времени участвуем и среди нас даже > постоянный представитель ПК HL++ есть. > > Писать можно мне на почту по поводу любых конференций. > > Что касается Golang Conf 2019, то, увы, но скорее всего не получится. > > -- > Валентин Бартенев > _______________________________________________ > 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 nginx-forum на forum.nginx.org Tue Jul 2 22:01:43 2019 From: nginx-forum на forum.nginx.org (scorpovi4) Date: Tue, 02 Jul 2019 18:01:43 -0400 Subject: =?UTF-8?B?V2VicCDQvdC1INC/0YDQuNGF0L7QtNC40YIg0L3QsCDQutC70LjQtdC90YI=?= Message-ID: <9e3b2003f29069ece781928aec2ec030.NginxMailingListRussian@forum.nginx.org> Пытаюсь заставить webp приходить на клиент. Сайт на WP. В http секции в nginx.conf map $http_accept $webp_extension { default ""; "~*webp" ".webp"; } В секции server location ~ ^/wp-content/uploads/ { location ~* ^/wp-content/uploads/(.+/)?(.+)\.(png|jpe?g)$ { expires 30d; add_header Vary "Accept-Encoding"; add_header Cache-Control "public, no-transform"; try_files $uri$webp_extension $uri =404; } } Есть ещё одна секция server для ssl, может в неё надо добавлять, вообще не понятно как попросить nginx таки слать webp. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284726,284726#msg-284726 From mdounin на mdounin.ru Wed Jul 3 00:18:37 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 3 Jul 2019 03:18:37 +0300 Subject: =?UTF-8?B?UmU6IE5naW5YINC60YDQvtGI0LjRgtGB0Y8g0YEgbGlicGVybC01LjMw?= In-Reply-To: <3347191.DbvyDg0hYd@note> References: <2785435.FqUjOj16l6@note> <20190629132800.GD1877@mdounin.ru> <4000386.dXMqPAoofX@note> <3347191.DbvyDg0hYd@note> Message-ID: <20190703001837.GH1877@mdounin.ru> Hello! On Sat, Jun 29, 2019 at 08:00:59PM +0300, Vadim A. Misbakh-Soloviov wrote: > Поправка: оно не падает в таком положении (даже на той машине) ТОЛЬКО если > цепляться по -p (без дебага, замечу, падает. Так что странно). > > Попробовал запустить напрямую под gdb, получил такое: > > ``` > #0 0x00007ffff492d0c7 in raise () from /lib64/libc.so.6 > #1 0x00007ffff492eaf9 in abort () from /lib64/libc.so.6 > #2 0x00007ffff49242a9 in ?? () from /lib64/libc.so.6 > #3 0x00007ffff4924331 in __assert_fail () from /lib64/libc.so.6 > #4 0x00007ffff4e1d28f in S__invlist_len (invlist=0x555555ea8078) at > invlist_inline.h:49 [...] > #11 0x00007ffff4e5d0d2 in S_reg (my_perl=0x555555dd5c60, > pRExC_state=0x7fffffff8da0, paren=0, flagp=0x7fffffff8ad8, depth=1) at > regcomp.c:12088 > #12 0x00007ffff4e3ebf7 in Perl_re_op_compile (my_perl=0x555555dd5c60, > patternp=0x0, pat_count=1, expr=0x555555dee908, eng=0x7ffff532b9a0 > , old_re=0x0, is_bare_re=0x0, orig_rx_flags=0, > pm_flags=1073741824) at regcomp.c:7705 Всё это по прежнему выгядит как падение собственно перла в процессе компиляции регулярного выражения. Судя по: > #16 0x00007ffff500f64e in S_require_file (my_perl=0x555555dd5c60, > sv=0x555555b9ce10) at pp_ctl.c:4322 > #17 0x00007ffff500f7aa in Perl_pp_require (my_perl=0x555555dd5c60) at > pp_ctl.c:4346 и по: > #26 0x00007ffff500f64e in S_require_file (my_perl=0x555555dd5c60, > sv=0x555555e35038) at pp_ctl.c:4322 > #27 0x00007ffff500f7aa in Perl_pp_require (my_perl=0x555555dd5c60) at > pp_ctl.c:4346 в процессе загрузки какого-то модуля, видимо второго по вложенности. С учётом того, что при создании perl-интерпретатора nginx автоматически загружает модуль nginx - видимо, падение вызывает что-то, что подтягивается из nginx.pm. Там в свою очередь используются Exporter и XSLoader, но ничего нетривиального в них не видно. Впрочем, это может быть и что-то из site-local загрузки. Для начала, наверное, имеет смысл разобраться, что именно за регулярное выражение падает, и из какого именно файла. Ну а дальше - смотреть соответствующие коммиты/тикеты в перле, воспроизводить и так далее. Впрочем, если перл в nginx'е не используется - проще всего perl-модуль убрать из сборки и заб(ы|и)ть. [...] -- Maxim Dounin http://mdounin.ru/ From swood на fotofor.biz Wed Jul 3 09:36:52 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Wed, 3 Jul 2019 10:36:52 +0100 Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?= In-Reply-To: <2616263.FslVnxXefZ@vbart-laptop> References: <2616263.FslVnxXefZ@vbart-laptop> Message-ID: Валентин, подскажите, тогда, пожалуйста. У меня вот есть связка nginx + unit (php). И иногда на сайте получается 500-я ошибка. Логи php пишутся и там кроме огромного количества строчек вида: [03-Jul-2019 10:46:01 Europe/Moscow] Failed to connect [111]: Connection refused Нет больше ничего полезного. Смотрю в лог unit и там тоже нет хоть какого-либо прямого или косвенного сообщения о том, что пошло не так. Кроме того, о чем я писал выше. В этом смысле nginx + php-fpm давал более прозрачную картину мира. Есть ошибка - она есть в логе. Тут вот как-то не всегда. Может быть я что-то не знаю или упустил во время настройки? Конфиг unit у меня весьма тривиальный: { "listeners": { "127.0.0.1:8091": { "application": "direct_php" } }, "direct_php": { "type": "php5.6", "processes": { "max": 13, "spare": 0 }, "user": "www-data", "group": "www-data", "root": "/data/site.ru/web/", "index": "index.php" } }, "access_log": "/var/log/nginx/unit_access.log" } Может быть у меня воркеры иногда заканчиваются и эта 500я вовсе не от php, а от unit, но почему бы тогда куда-то об этом не сообщать? вс, 16 июн. 2019 г. в 04:29, Валентин Бартенев : > On Sunday, 16 June 2019 00:31:15 MSK Anton Kiryushkin wrote: > > Здравствуйте. > > > > Подскажите, пожалуйста, как правильно читать лог unitd: > > > > 2019/06/15 23:08:18 [info] 890#1012 *959 shutdown(182, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:08:25 [info] 890#1011 *1008 shutdown(182, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:09:16 [info] 890#1004 *1009 shutdown(186, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:09:21 [info] 890#1013 *1266 shutdown(180, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:10:25 [info] 890#1007 *1493 shutdown(187, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:10:40 [info] 890#1007 *1633 shutdown(176, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:10:43 [info] 890#1007 *1647 shutdown(183, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:10:46 [info] 890#1012 *1653 shutdown(182, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:10:50 [info] 890#1013 *1682 shutdown(183, 2) failed (107: > > Transport endpoint is not connected) > > 2019/06/15 23:11:14 [info] 890#1007 *1769 shutdown(179, 2) failed (107: > > Transport endpoint is not connected) > > Клиент успел закрыть соединение раньше, чем это сделал Unit. > Абсолютно нормальная ситуация. > > > > 2019/06/15 23:11:18 [error] 890#1007 *1782 send(180, 7F1195A6AF80, > 1283623) > > failed (32: Broken pipe) > > Клиент закрыл соединение не дождавшись ответа, так бывает. > > > > > > Тут есть info и error. Верно ли, что info это про то, что запрос > > завершился, все хорошо, просто ответ был отправлен клиенту. Про что > error? > > > > Попутно, можно ли keepalive использовать между nginx и unit? > > > > Можно. > > -- > Валентин Бартенев > _______________________________________________ > 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 vbart на nginx.com Wed Jul 3 11:10:43 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 03 Jul 2019 14:10:43 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?= In-Reply-To: References: <2616263.FslVnxXefZ@vbart-laptop> Message-ID: <7040126.BHQ139x8JR@vbart-workstation> On Wednesday 03 July 2019 10:36:52 Anton Kiryushkin wrote: > Валентин, подскажите, тогда, пожалуйста. > > У меня вот есть связка nginx + unit (php). > И иногда на сайте получается 500-я ошибка. Логи php пишутся и там кроме > огромного количества строчек вида: > > [03-Jul-2019 10:46:01 Europe/Moscow] Failed to connect [111]: Connection > refused > > > Нет больше ничего полезного. Смотрю в лог unit и там тоже нет хоть > какого-либо прямого или косвенного сообщения о том, что пошло не так. Кроме > того, о чем я писал выше. > В этом смысле nginx + php-fpm давал более прозрачную картину мира. Есть > ошибка - она есть в логе. Тут вот как-то не всегда. [..] А какую ошибку в этом случае писал php-fpm? Можно пример? Я бы посмотрел по исходникам php, где она возникает и в каких случаях пишется. > Может быть я что-то не знаю или упустил во время настройки? Конфиг unit у > меня весьма тривиальный: > > { > "listeners": { > "127.0.0.1:8091": { > "application": "direct_php" > } > }, > "direct_php": { > "type": "php5.6", > "processes": { > "max": 13, > "spare": 0 > }, > > "user": "www-data", > "group": "www-data", > "root": "/data/site.ru/web/", > "index": "index.php" > } > }, > "access_log": "/var/log/nginx/unit_access.log" > } > > Может быть у меня воркеры иногда заканчиваются и эта 500я вовсе не от php, > а от unit, но почему бы тогда куда-то об этом не сообщать? [..] Unit обычно громко ругается в лог, если что-то пошло не так и он сам был вынужден сгенерировать 500-ую ошибку. Но если 500 код ответа был возвращен из приложения нормальным путем, то тут нечего больше добавить. Также как и php-fpm мы отдаем запрос php интерпретатору, тот генерирует какой-то ответ с определенным кодом и отдает его обратно. Попутно он может сам что-то логгировать, но это никак не конролируется со стороны SAPI, будь то php-fpm, будь то Unit. Возможно имеет смысл добавить логгирование о том, что вот мол приложение вернуло нам 500, чтобы не возникало вопросов, откуда этот ответ родился. Стоит учесть, что php-fpm и libphp (которую Unit использует) обычно используют разные php.ini файлы. И настройки логгирования и репортинга ошибок там могут отличаться. Имеет смысл сделать ревизию используемого с Unit-том php.ini на предмет соответствующих настроек: https://www.php.net/manual/en/errorfunc.configuration.php -- Валентин Бартенев From swood на fotofor.biz Wed Jul 3 11:47:01 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Wed, 3 Jul 2019 12:47:01 +0100 Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?= In-Reply-To: <7040126.BHQ139x8JR@vbart-workstation> References: <2616263.FslVnxXefZ@vbart-laptop> <7040126.BHQ139x8JR@vbart-workstation> Message-ID: Спасибо за ваш ответ. Ответ от php-fpm я мог найти в error-log nginx-a. Ну я не скажу, какую именно. Еще раз, проблема заключается в том, что в логе в access.log nginx есть 500-й код ответа. Но причину этого 500-го кода нельзя найти в логе ошибок php (а там прописана опция error_log), и логе unit и в логе nginx, потому что там в принципе не должно быть этих ошибок. В случае с fpm в логе ошибок nginx гарантированно причину можно было найти. Приложение не возвращает просто так 500-ю ошибку. Поэтому и возник вопрос, как же можно заставить unit писать лог любых своих ошибок в какой-то файл. Ну или куда вообще можно было бы копать, так как возможные вещи, которые есть возможность предпринять в php, на мой взгляд, предприняты. ср, 3 июл. 2019 г. в 12:10, Валентин Бартенев : > On Wednesday 03 July 2019 10:36:52 Anton Kiryushkin wrote: > > Валентин, подскажите, тогда, пожалуйста. > > > > У меня вот есть связка nginx + unit (php). > > И иногда на сайте получается 500-я ошибка. Логи php пишутся и там кроме > > огромного количества строчек вида: > > > > [03-Jul-2019 10:46:01 Europe/Moscow] Failed to connect [111]: Connection > > refused > > > > > > Нет больше ничего полезного. Смотрю в лог unit и там тоже нет хоть > > какого-либо прямого или косвенного сообщения о том, что пошло не так. > Кроме > > того, о чем я писал выше. > > В этом смысле nginx + php-fpm давал более прозрачную картину мира. Есть > > ошибка - она есть в логе. Тут вот как-то не всегда. > [..] > > А какую ошибку в этом случае писал php-fpm? Можно пример? > > Я бы посмотрел по исходникам php, где она возникает и в каких случаях > пишется. > > > > Может быть я что-то не знаю или упустил во время настройки? Конфиг unit у > > меня весьма тривиальный: > > > > { > > "listeners": { > > "127.0.0.1:8091": { > > "application": "direct_php" > > } > > }, > > "direct_php": { > > "type": "php5.6", > > "processes": { > > "max": 13, > > "spare": 0 > > }, > > > > "user": "www-data", > > "group": "www-data", > > "root": "/data/site.ru/web/", > > "index": "index.php" > > } > > }, > > "access_log": "/var/log/nginx/unit_access.log" > > } > > > > Может быть у меня воркеры иногда заканчиваются и эта 500я вовсе не от > php, > > а от unit, но почему бы тогда куда-то об этом не сообщать? > [..] > > Unit обычно громко ругается в лог, если что-то пошло не так и он сам был > вынужден сгенерировать 500-ую ошибку. Но если 500 код ответа был возвращен > из приложения нормальным путем, то тут нечего больше добавить. > > Также как и php-fpm мы отдаем запрос php интерпретатору, тот генерирует > какой-то ответ с определенным кодом и отдает его обратно. Попутно он > может сам что-то логгировать, но это никак не конролируется со стороны > SAPI, будь то php-fpm, будь то Unit. > > Возможно имеет смысл добавить логгирование о том, что вот мол приложение > вернуло нам 500, чтобы не возникало вопросов, откуда этот ответ родился. > > Стоит учесть, что php-fpm и libphp (которую Unit использует) обычно > используют > разные php.ini файлы. И настройки логгирования и репортинга ошибок там > могут > отличаться. Имеет смысл сделать ревизию используемого с Unit-том php.ini > на > предмет соответствующих настроек: > > https://www.php.net/manual/en/errorfunc.configuration.php > > -- > Валентин Бартенев > _______________________________________________ > 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 nginx-forum на forum.nginx.org Wed Jul 3 13:41:56 2019 From: nginx-forum на forum.nginx.org (sla1733) Date: Wed, 03 Jul 2019 09:41:56 -0400 Subject: =?UTF-8?B?0J7Qs9GA0LDQvdC40YfQtdC90LjQtSDQtNC+0YHRgtGD0L/QsCDQuiBVUkw=?= Message-ID: <967bbf1f9217b2e4aaca9fb1552139dc.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Подскажите, можно ли каким-нибудь образом заблокировать доступ к определенному location для входящего запроса от конкретного сервиса (например, запрос отправленный от Zabbix)? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284744,284744#msg-284744 From nginx-forum на forum.nginx.org Wed Jul 3 13:46:06 2019 From: nginx-forum на forum.nginx.org (avl) Date: Wed, 03 Jul 2019 09:46:06 -0400 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0LogVVJM?= In-Reply-To: <967bbf1f9217b2e4aaca9fb1552139dc.NginxMailingListRussian@forum.nginx.org> References: <967bbf1f9217b2e4aaca9fb1552139dc.NginxMailingListRussian@forum.nginx.org> Message-ID: <24432b4549cdc1af7aae9d6a04976d42.NginxMailingListRussian@forum.nginx.org> Проверять user agent? Посмотрите openresty Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284744,284745#msg-284745 From nginx-forum на forum.nginx.org Wed Jul 3 13:49:59 2019 From: nginx-forum на forum.nginx.org (avl) Date: Wed, 03 Jul 2019 09:49:59 -0400 Subject: =?UTF-8?B?UmU6IE5naW54K0x10LA9INCd0LXQvNC90L7QttC60L4g0L7QsdC70LDRh9C90L4g?= =?UTF-8?B?0YEgV0VCREFW?= In-Reply-To: <7875fe266a403e004a176b23ca8c3c60.NginxMailingListRussian@forum.nginx.org> References: <7875fe266a403e004a176b23ca8c3c60.NginxMailingListRussian@forum.nginx.org> Message-ID: <9ff32402cb1fef2eb7ac51c9be9d24ed.NginxMailingListRussian@forum.nginx.org> Хотел посмотреть реализацию модуля auth-dav.lua - авторизатор для HTTP/HTTPS/WEBDAV Нигде нет кода. Он совсем исчез с концами? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,259941,284746#msg-284746 From nginx-forum на forum.nginx.org Wed Jul 3 14:21:47 2019 From: nginx-forum на forum.nginx.org (sla1733) Date: Wed, 03 Jul 2019 10:21:47 -0400 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0LogVVJM?= In-Reply-To: <24432b4549cdc1af7aae9d6a04976d42.NginxMailingListRussian@forum.nginx.org> References: <967bbf1f9217b2e4aaca9fb1552139dc.NginxMailingListRussian@forum.nginx.org> <24432b4549cdc1af7aae9d6a04976d42.NginxMailingListRussian@forum.nginx.org> Message-ID: Есть location который проверяется простой проверкой Заббикса на доступность. Нужно запретить доступ к этому location для Заббикса Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284744,284747#msg-284747 From vbart на nginx.com Wed Jul 3 17:47:31 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 03 Jul 2019 20:47:31 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?= In-Reply-To: References: <7040126.BHQ139x8JR@vbart-workstation> Message-ID: <5408858.Yfk6DYrYlT@vbart-workstation> On Wednesday 03 July 2019 12:47:01 Anton Kiryushkin wrote: > Спасибо за ваш ответ. > > Ответ от php-fpm я мог найти в error-log nginx-a. Ну я не скажу, какую > именно. Еще раз, проблема заключается в том, что в логе в access.log nginx > есть 500-й код ответа. Но причину этого 500-го кода нельзя найти в логе > ошибок php (а там прописана опция error_log), и логе unit и в логе nginx, > потому что там в принципе не должно быть этих ошибок. В случае с fpm в логе > ошибок nginx гарантированно причину можно было найти. Приложение не > возвращает просто так 500-ю ошибку. > > Поэтому и возник вопрос, как же можно заставить unit писать лог любых своих > ошибок в какой-то файл. Ну или куда вообще можно было бы копать, так как > возможные вещи, которые есть возможность предпринять в php, на мой взгляд, > предприняты. [..] В error-log nginx писалось то, что приходило от php-fpm через stderr-канал, а тот в свою очередь посылал туда то, что php писал в stderr. В случае Unit-а весь stderr из php направляется в unit.log и собственно там и должен быть. Могу предложить попробовать собрать php модуль с патчем ниже. В этом случае всякий раз, когда php-интерпретатор возвращает ответ с 500-ым кодом, в unit.log будет об этом запись. 2019/07/03 20:45:02.899 [warn] 14919#14919 [unit] #7: application returned 500 response Это, как минимум, позволит исключить ситуацию, что 500-ую генерирует сам Unit и не сообщает об этом по какой-то причине. -- Валентин Бартенев diff -r 2b068c8361f9 src/nxt_php_sapi.c --- a/src/nxt_php_sapi.c Tue Jul 02 16:44:08 2019 +0300 +++ b/src/nxt_php_sapi.c Wed Jul 03 20:32:38 2019 +0300 @@ -774,6 +774,10 @@ nxt_php_send_headers(sapi_headers_struct status = 200; } + if (status == 500) { + nxt_unit_req_warn(req, "application returned 500 response"); + } + rc = nxt_unit_response_init(req, status, fields_count, resp_size); if (nxt_slow_path(rc != NXT_UNIT_OK)) { return SAPI_HEADER_SEND_FAILED; From chipitsine на gmail.com Wed Jul 3 19:09:22 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 4 Jul 2019 00:09:22 +0500 Subject: =?UTF-8?B?c3NsX2Vhcmx5X2RhdGEg0LTQu9GPIFRMUzEuMiA/?= Message-ID: привет! в конфиге на уровне http указано "ssl_early_data on;" в сервере, в котором нужен TLS1.2 (не задан TLS1.3) не задан никак ssl_early_data. судя по debug-логу - наследуется от уровня http, и пытается найти в пакетах early data. по спецификации, на TLS1.2 такого не должно быть. может проверять наличие TLS1.3 для включения этой опции (даже унаследованной от более высоких уровней) ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Jul 3 19:44:06 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 4 Jul 2019 00:44:06 +0500 Subject: =?UTF-8?B?0YHQsdC+0YDQutCwIG9wZW5zc2wg0L/RgNC4INC/0L7QvNC+0YnQuCAtLXdpdGgt?= =?UTF-8?B?b3BlbnNzbD08cGF0aD4=?= Message-ID: привет! а почему, если я задаю ./configure --with-cc=clang --with-openssl= то openssl собирается компилятором gcc ? по задумке не должно было взять clang ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Jul 4 05:31:49 2019 From: nginx-forum на forum.nginx.org (sla1733) Date: Thu, 04 Jul 2019 01:31:49 -0400 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0LogVVJM?= In-Reply-To: References: <967bbf1f9217b2e4aaca9fb1552139dc.NginxMailingListRussian@forum.nginx.org> <24432b4549cdc1af7aae9d6a04976d42.NginxMailingListRussian@forum.nginx.org> Message-ID: <6bd73eb774dca4206b424a8ead0532e1.NginxMailingListRussian@forum.nginx.org> Настроил блокировку по user agent. Всем спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284744,284756#msg-284756 From max.romanov на nginx.com Thu Jul 4 12:52:42 2019 From: max.romanov на nginx.com (Max Romanov) Date: Thu, 4 Jul 2019 15:52:42 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?= In-Reply-To: <986eb9367ecfe675b88ce1fec4884533.NginxMailingListRussian@forum.nginx.org> References: <2632802.ZtBez7UN1Q@vbart-workstation> <986eb9367ecfe675b88ce1fec4884533.NginxMailingListRussian@forum.nginx.org> Message-ID: > On 16 Jun 2019, at 15:53 , S.A.N wrote: ... > Возможно уже есть документация и открытое бета тестирования для Node.js? Открыто бета-тестирование поддержки WebSocket в Node.js и Java. Unit надо собирать из исходников вот отсюда: https://github.com/mar0x/unit/tree/websocket . Для использования в Node.js надо исправить: var http = require('http’); var webSocketServer = require('websocket').server; на var http = require('unit-http’); var webSocketServer = require('unit-http/websocket').server; — Max ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Fri Jul 5 16:17:01 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 5 Jul 2019 19:17:01 +0300 Subject: location Message-ID: <20190705161701.GQ2161@zxy.spb.ru> есть кусок конфига location /pkg { alias /poudriere/data/packages; index index.html index.htm; } добавляем location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; } nginx -s reload и призапросе получеам такую ошибку: 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "pkg.int.integros.com" что за фигня? а если сделать /usr/local/etc/rc.d/nginx restart то все начинает работать что за нафиг? From nginx-forum на forum.nginx.org Sat Jul 6 14:43:36 2019 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Sat, 06 Jul 2019 10:43:36 -0400 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgSByZXdyaXRl?= Message-ID: <0cc70027c220a51d1c8e81dc62eeebdf.NginxMailingListRussian@forum.nginx.org> Чего-то видимо туплю. Подскажите как такое организовать: есть урл вида http://somesite.com/directory/?arg1=SOME-ARG1&arg2=SOME-ARG2 нужно получить редирект на http://somesite.com/directory/SOME-ARG1/SOME-ARG2 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284765,284765#msg-284765 From mdounin на mdounin.ru Sat Jul 6 17:38:19 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 6 Jul 2019 20:38:19 +0300 Subject: location In-Reply-To: <20190705161701.GQ2161@zxy.spb.ru> References: <20190705161701.GQ2161@zxy.spb.ru> Message-ID: <20190706173819.GO1877@mdounin.ru> Hello! On Fri, Jul 05, 2019 at 07:17:01PM +0300, Slawa Olhovchenkov wrote: > есть кусок конфига > > location /pkg { alias /poudriere/data/packages; index index.html index.htm; } > > добавляем > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; } > > nginx -s reload > > и призапросе получеам такую ошибку: > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "pkg.int.integros.com" > > что за фигня? > а если сделать > > /usr/local/etc/rc.d/nginx restart > > то все начинает работать > что за нафиг? In no particular order: - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не одно и то же, и могут делать совсем разное, если, например, на машине более чем один nginx; - reload может быть невозможен при некоторых изменениях - в частности, "на лету" нельзя менять путь и levels у кэша, так как для их изменения требуется повторная загрузка кэша - либо же может просто завершиться ошибкой по внешним причинам; ошибки об этом будут в глобальном логе в процессе перезагрузки конфигурации; -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Sat Jul 6 18:04:00 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sat, 6 Jul 2019 21:04:00 +0300 Subject: location In-Reply-To: <20190706173819.GO1877@mdounin.ru> References: <20190705161701.GQ2161@zxy.spb.ru> <20190706173819.GO1877@mdounin.ru> Message-ID: <20190706180400.GR2161@zxy.spb.ru> On Sat, Jul 06, 2019 at 08:38:19PM +0300, Maxim Dounin wrote: > Hello! > > On Fri, Jul 05, 2019 at 07:17:01PM +0300, Slawa Olhovchenkov wrote: > > > есть кусок конфига > > > > location /pkg { alias /poudriere/data/packages; index index.html index.htm; } > > > > добавляем > > > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; } > > > > nginx -s reload > > > > и призапросе получеам такую ошибку: > > > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "pkg.int.integros.com" > > > > что за фигня? > > а если сделать > > > > /usr/local/etc/rc.d/nginx restart > > > > то все начинает работать > > что за нафиг? > > In no particular order: > > - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не action тут разный. я на этом внимание не заострил, думал и так понятно > одно и то же, и могут делать совсем разное, если, например, на > машине более чем один nginx; один > - reload может быть невозможен при некоторых изменениях - в > частности, "на лету" нельзя менять путь и levels у кэша, так как > для их изменения требуется повторная загрузка кэша - либо же кэш не менялся, я привел разницу в строках. > может просто завершиться ошибкой по внешним причинам; ошибки об > этом будут в глобальном логе в процессе перезагрузки конфигурации; а вот тут интересный момент. restart прошел успешно с тем же конфигом. значит конфиг норм, да? а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг поймешь (такой уж лог). 2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is not equal to the number of "worker_cpu_affinity" masks, using last mask for remaining worker processes 2019/07/05 19:13:59 [notice] 81052#0: signal process started 2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from 81052, reconfiguring 2019/07/05 19:13:59 [notice] 939#0: reconfiguring 2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already loaded in /usr/local/etc/nginx/nginx.conf:1 2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "" ну вот что я должен заключить? вроде emerg. но написанно is already loaded. т.е. фиг с ним? From mdounin на mdounin.ru Sat Jul 6 18:08:54 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 6 Jul 2019 21:08:54 +0300 Subject: =?UTF-8?B?UmU6IHNzbF9lYXJseV9kYXRhINC00LvRjyBUTFMxLjIgPw==?= In-Reply-To: References: Message-ID: <20190706180854.GP1877@mdounin.ru> Hello! On Thu, Jul 04, 2019 at 12:09:22AM +0500, Илья Шипицин wrote: > привет! > > в конфиге на уровне http указано "ssl_early_data on;" > > в сервере, в котором нужен TLS1.2 (не задан TLS1.3) не задан никак > ssl_early_data. > судя по debug-логу - наследуется от уровня http, и пытается найти в пакетах > early data. > > по спецификации, на TLS1.2 такого не должно быть. > > может проверять наличие TLS1.3 для включения этой опции (даже > унаследованной от более высоких уровней) ? Чтобы что? В случае, если соединение использует TLSv1.2 - соединение уйдёт в обычное чтение, как только OpenSSL нам об этом скажет. Дублировать знание о том, где именно бывает early data, а где не бывает, в самом nginx'е - выглядит как ненужное усложнение. Правильнее всего это место сделано в BoringSSL - там вообще один интерфейс для чтения, и если чтение early data включено - то этот интерфейс он просто возвращает 0-rtt-данные в случае их наличия. -- Maxim Dounin http://mdounin.ru/ From vladget на gmail.com Sun Jul 7 08:20:02 2019 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Sun, 7 Jul 2019 11:20:02 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YEgcmV3cml0ZQ==?= In-Reply-To: <0cc70027c220a51d1c8e81dc62eeebdf.NginxMailingListRussian@forum.nginx.org> References: <0cc70027c220a51d1c8e81dc62eeebdf.NginxMailingListRussian@forum.nginx.org> Message-ID: Не уверен, но мне кажется вот так: return http://somesite.com/directory/$arg_arg1/$arg_arg2 301; http://nginx.org/en/docs/http/ngx_http_core_module.html#variables On Sat, Jul 6, 2019 at 5:43 PM Dmytro Lavryk wrote: > Чего-то видимо туплю. Подскажите как такое организовать: > есть урл вида http://somesite.com/directory/?arg1=SOME-ARG1&arg2=SOME-ARG2 > нужно получить редирект на > http://somesite.com/directory/SOME-ARG1/SOME-ARG2 > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,284765,284765#msg-284765 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Jul 8 13:29:06 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 8 Jul 2019 16:29:06 +0300 Subject: location In-Reply-To: <20190706180400.GR2161@zxy.spb.ru> References: <20190705161701.GQ2161@zxy.spb.ru> <20190706173819.GO1877@mdounin.ru> <20190706180400.GR2161@zxy.spb.ru> Message-ID: <20190708132906.GR1877@mdounin.ru> Hello! On Sat, Jul 06, 2019 at 09:04:00PM +0300, Slawa Olhovchenkov wrote: > On Sat, Jul 06, 2019 at 08:38:19PM +0300, Maxim Dounin wrote: > > > Hello! > > > > On Fri, Jul 05, 2019 at 07:17:01PM +0300, Slawa Olhovchenkov wrote: > > > > > есть кусок конфига > > > > > > location /pkg { alias /poudriere/data/packages; index index.html index.htm; } > > > > > > добавляем > > > > > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; } > > > > > > nginx -s reload > > > > > > и призапросе получеам такую ошибку: > > > > > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "pkg.int.integros.com" > > > > > > что за фигня? > > > а если сделать > > > > > > /usr/local/etc/rc.d/nginx restart > > > > > > то все начинает работать > > > что за нафиг? > > > > In no particular order: > > > > - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не > > action тут разный. я на этом внимание не заострил, думал и так понятно Понятно. И также понятно, что даже при одном и том же action - приведённые команды делают разное, и результаты могут кардинально отличаться в том числе из-за этого. Именно поэтому я и указал на эту проблему как на одну из возможных причин наблюдаемого поведения. Дабы подобную проблему гарантированно исключить - лучше всего использовать одну и ту же форму команды. [...] > > - reload может быть невозможен при некоторых изменениях - в > > частности, "на лету" нельзя менять путь и levels у кэша, так как > > для их изменения требуется повторная загрузка кэша - либо же > > кэш не менялся, я привел разницу в строках. С учётом того, что ошибка reload'а нашлась только после явного указания на то, что надо искать - мы не знаем, что менялось, а что нет. > > может просто завершиться ошибкой по внешним причинам; ошибки об > > этом будут в глобальном логе в процессе перезагрузки конфигурации; > > а вот тут интересный момент. > restart прошел успешно с тем же конфигом. значит конфиг норм, да? > а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг > поймешь (такой уж лог). > > 2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is not equal to the number of "worker_cpu_affinity" masks, using last mask for remaining worker processes > 2019/07/05 19:13:59 [notice] 81052#0: signal process started > 2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from 81052, reconfiguring > 2019/07/05 19:13:59 [notice] 939#0: reconfiguring > 2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already loaded in /usr/local/etc/nginx/nginx.conf:1 > 2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "" > > ну вот что я должен заключить? вроде emerg. но написанно is already loaded. т.е. фиг с ним? Уровень emerg - это фатальная ошибка, после таких ошибок парсинг конфигурации прекращается. Если бы nginx считал, что проблему можно игнорировать - уровень ошибки был бы другой, и, для высоких уровней, рядом было бы написано "ignored". Что до самой ошибки и того факта, что ломается оно только на релоаде, но не на рестарте - то единственный сценарий, который приходит в голову, какой-то такой: - Был загружен модуль, совмещающий в одном so-файле что-то ещё и ndk_http_module; - Файл *.so на диске поменялся, и теперь содержит только что-то ещё, а ndk_http_module был добавлен отдельной директивой load_module. - После чего был сделан reload - и привёл к той же ошибке "module ... is already loaded", что было проигнорировано. Так происходит, потому что с помощью reload'а нельзя изменить ранее загруженный модуль - so-шка уже в памяти, и при попытке её снова открыть - откроется старая so-шка. Чтобы загрузить новые модули после изменения их so-файлов на диске - нужно делать upgrade. -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Mon Jul 8 13:55:40 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Mon, 8 Jul 2019 16:55:40 +0300 Subject: location In-Reply-To: <20190708132906.GR1877@mdounin.ru> References: <20190705161701.GQ2161@zxy.spb.ru> <20190706173819.GO1877@mdounin.ru> <20190706180400.GR2161@zxy.spb.ru> <20190708132906.GR1877@mdounin.ru> Message-ID: <20190708135540.GT2161@zxy.spb.ru> On Mon, Jul 08, 2019 at 04:29:06PM +0300, Maxim Dounin wrote: > > > > есть кусок конфига > > > > location /pkg { alias /poudriere/data/packages; index index.html index.htm; } > > > > добавляем > > > > > > > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; } > > > > nginx -s reload > > > > > > > > и призапросе получеам такую ошибку: > > > > > > > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "pkg.int.integros.com" > > > > > > > > что за фигня? > > > > а если сделать > > > > > > > > /usr/local/etc/rc.d/nginx restart > > > > > > > > то все начинает работать > > > > что за нафиг? > > > > > > In no particular order: > > > > > > - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не > > > > action тут разный. я на этом внимание не заострил, думал и так понятно > > Понятно. И также понятно, что даже при одном и том же action - > приведённые команды делают разное, и результаты могут кардинально > отличаться в том числе из-за этого. Именно поэтому я и указал на > эту проблему как на одну из возможных причин наблюдаемого > поведения. Дабы подобную проблему гарантированно исключить - > лучше всего использовать одну и ту же форму команды. так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start` > [...] > > > > - reload может быть невозможен при некоторых изменениях - в > > > частности, "на лету" нельзя менять путь и levels у кэша, так как > > > для их изменения требуется повторная загрузка кэша - либо же > > > > кэш не менялся, я привел разницу в строках. > > С учётом того, что ошибка reload'а нашлась только после явного > указания на то, что надо искать - мы не знаем, что менялось, а что > нет. > > > > может просто завершиться ошибкой по внешним причинам; ошибки об > > > этом будут в глобальном логе в процессе перезагрузки конфигурации; > > > > а вот тут интересный момент. > > restart прошел успешно с тем же конфигом. значит конфиг норм, да? > > а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг > > поймешь (такой уж лог). > > > > 2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is not equal to the number of "worker_cpu_affinity" masks, using last mask for remaining worker processes > > 2019/07/05 19:13:59 [notice] 81052#0: signal process started > > 2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from 81052, reconfiguring > > 2019/07/05 19:13:59 [notice] 939#0: reconfiguring > > 2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already loaded in /usr/local/etc/nginx/nginx.conf:1 > > 2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "" > > > > ну вот что я должен заключить? вроде emerg. но написанно is already loaded. т.е. фиг с ним? > > Уровень emerg - это фатальная ошибка, после таких ошибок парсинг > конфигурации прекращается. Если бы nginx считал, что проблему > можно игнорировать - уровень ошибки был бы другой, и, для высоких > уровней, рядом было бы написано "ignored". а alert у нас что? > Что до самой ошибки и того факта, что ломается оно только на > релоаде, но не на рестарте - то единственный сценарий, который > приходит в голову, какой-то такой: > > - Был загружен модуль, совмещающий в одном so-файле что-то ещё и > ndk_http_module; lua скорее всего. > - Файл *.so на диске поменялся, и теперь содержит только что-то ещё, > а ndk_http_module был добавлен отдельной директивой load_module. не исключаю что так и было. > - После чего был сделан reload - и привёл к той же ошибке "module > ... is already loaded", что было проигнорировано. Так нет, он не нашел ndk_* символов. после чего я добавил строку с загрузко ndk_http. > происходит, потому что с помощью reload'а нельзя изменить ранее > загруженный модуль - so-шка уже в памяти, и при попытке её снова > открыть - откроется старая so-шка. Чтобы загрузить новые модули > после изменения их so-файлов на диске - нужно делать upgrade. а чего он их тогда полез открывать-то? меня устроили бы старые модули. From mdounin на mdounin.ru Mon Jul 8 16:11:59 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 8 Jul 2019 19:11:59 +0300 Subject: location In-Reply-To: <20190708135540.GT2161@zxy.spb.ru> References: <20190705161701.GQ2161@zxy.spb.ru> <20190706173819.GO1877@mdounin.ru> <20190706180400.GR2161@zxy.spb.ru> <20190708132906.GR1877@mdounin.ru> <20190708135540.GT2161@zxy.spb.ru> Message-ID: <20190708161159.GT1877@mdounin.ru> Hello! On Mon, Jul 08, 2019 at 04:55:40PM +0300, Slawa Olhovchenkov wrote: > On Mon, Jul 08, 2019 at 04:29:06PM +0300, Maxim Dounin wrote: > > > > > > есть кусок конфига > > > > > location /pkg { alias /poudriere/data/packages; index index.html index.htm; } > > > > > добавляем > > > > > > > > > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; } > > > > > nginx -s reload > > > > > > > > > > и призапросе получеам такую ошибку: > > > > > > > > > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "pkg.int.integros.com" > > > > > > > > > > что за фигня? > > > > > а если сделать > > > > > > > > > > /usr/local/etc/rc.d/nginx restart > > > > > > > > > > то все начинает работать > > > > > что за нафиг? > > > > > > > > In no particular order: > > > > > > > > - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не > > > > > > action тут разный. я на этом внимание не заострил, думал и так понятно > > > > Понятно. И также понятно, что даже при одном и том же action - > > приведённые команды делают разное, и результаты могут кардинально > > отличаться в том числе из-за этого. Именно поэтому я и указал на > > эту проблему как на одну из возможных причин наблюдаемого > > поведения. Дабы подобную проблему гарантированно исключить - > > лучше всего использовать одну и ту же форму команды. > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start` Зато бывает "service nginx reload" и "service nginx restart". (Ну и вообще, использовать "nginx -s ..." на юникс-системах - странно. Как минимум попадаем на двойной парсинг конфигурации, как максимум - на невозможность использовать эти команды, если PID-файл надо переложить в другое место.) > > [...] > > > > > > - reload может быть невозможен при некоторых изменениях - в > > > > частности, "на лету" нельзя менять путь и levels у кэша, так как > > > > для их изменения требуется повторная загрузка кэша - либо же > > > > > > кэш не менялся, я привел разницу в строках. > > > > С учётом того, что ошибка reload'а нашлась только после явного > > указания на то, что надо искать - мы не знаем, что менялось, а что > > нет. > > > > > > может просто завершиться ошибкой по внешним причинам; ошибки об > > > > этом будут в глобальном логе в процессе перезагрузки конфигурации; > > > > > > а вот тут интересный момент. > > > restart прошел успешно с тем же конфигом. значит конфиг норм, да? > > > а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг > > > поймешь (такой уж лог). > > > > > > 2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is not equal to the number of "worker_cpu_affinity" masks, using last mask for remaining worker processes > > > 2019/07/05 19:13:59 [notice] 81052#0: signal process started > > > 2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from 81052, reconfiguring > > > 2019/07/05 19:13:59 [notice] 939#0: reconfiguring > > > 2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already loaded in /usr/local/etc/nginx/nginx.conf:1 > > > 2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: "" > > > > > > ну вот что я должен заключить? вроде emerg. но написанно is already loaded. т.е. фиг с ним? > > > > Уровень emerg - это фатальная ошибка, после таких ошибок парсинг > > конфигурации прекращается. Если бы nginx считал, что проблему > > можно игнорировать - уровень ошибки был бы другой, и, для высоких > > уровней, рядом было бы написано "ignored". > > а alert у нас что? Уровень alert используется для логгирования серьёзных проблем, однако, в отличи от emerg, он не означает, что дальнейшая работа невозможна. > > Что до самой ошибки и того факта, что ломается оно только на > > релоаде, но не на рестарте - то единственный сценарий, который > > приходит в голову, какой-то такой: > > > > - Был загружен модуль, совмещающий в одном so-файле что-то ещё и > > ndk_http_module; > > lua скорее всего. > > > - Файл *.so на диске поменялся, и теперь содержит только что-то ещё, > > а ndk_http_module был добавлен отдельной директивой load_module. > > не исключаю что так и было. > > > - После чего был сделан reload - и привёл к той же ошибке "module > > ... is already loaded", что было проигнорировано. Так > > нет, он не нашел ndk_* символов. > после чего я добавил строку с загрузко ndk_http. Не нашёл символов - в процессе тестирования конфигурации с помощью "nginx -t" и/или при парсинге конфигурации в процессе запуска "nginx -s"? Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет загруженных модулей, и они получают то, что было на диске. И это одна из причин, почему reload не стоит предварять запуском "nginx -t", и не стоит использовать "nginx -s". > > происходит, потому что с помощью reload'а нельзя изменить ранее > > загруженный модуль - so-шка уже в памяти, и при попытке её снова > > открыть - откроется старая so-шка. Чтобы загрузить новые модули > > после изменения их so-файлов на диске - нужно делать upgrade. > > а чего он их тогда полез открывать-то? > меня устроили бы старые модули. В новой конфигурации - новый список модулей, они открываются / загружаются в соответствии с тем, что задано в директивах load_module в конфиге. Поскольку в список добавился ndk - nginx его попытался загрузить, поскольку в результате оказалось загружено два одинаковых модуля - выдал ошибку и откатился на предыдущую конфигурацию. -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Mon Jul 8 16:24:33 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Mon, 8 Jul 2019 19:24:33 +0300 Subject: location In-Reply-To: <20190708161159.GT1877@mdounin.ru> References: <20190705161701.GQ2161@zxy.spb.ru> <20190706173819.GO1877@mdounin.ru> <20190706180400.GR2161@zxy.spb.ru> <20190708132906.GR1877@mdounin.ru> <20190708135540.GT2161@zxy.spb.ru> <20190708161159.GT1877@mdounin.ru> Message-ID: <20190708162433.GU2161@zxy.spb.ru> On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote: > > > > action тут разный. я на этом внимание не заострил, думал и так понятно > > > > > > Понятно. И также понятно, что даже при одном и том же action - > > > приведённые команды делают разное, и результаты могут кардинально > > > отличаться в том числе из-за этого. Именно поэтому я и указал на > > > эту проблему как на одну из возможных причин наблюдаемого > > > поведения. Дабы подобную проблему гарантированно исключить - > > > лучше всего использовать одну и ту же форму команды. > > > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start` > > Зато бывает "service nginx reload" и "service nginx restart". > > (Ну и вообще, использовать "nginx -s ..." на юникс-системах - > странно. Как минимум попадаем на двойной парсинг конфигурации, > как максимум - на невозможность использовать эти команды, если > PID-файл надо переложить в другое место.) набирать короче, давно заучил, а эти service вечно меняются... > > > - После чего был сделан reload - и привёл к той же ошибке "module > > > ... is already loaded", что было проигнорировано. Так > > > > нет, он не нашел ndk_* символов. > > после чего я добавил строку с загрузко ndk_http. > > Не нашёл символов - в процессе тестирования конфигурации с помощью > "nginx -t" и/или при парсинге конфигурации в процессе запуска > "nginx -s"? вот тут не помню. > Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет > загруженных модулей, и они получают то, что было на диске. И это > одна из причин, почему reload не стоит предварять запуском "nginx -t", > и не стоит использовать "nginx -s". ничего не понял. > > > происходит, потому что с помощью reload'а нельзя изменить ранее > > > загруженный модуль - so-шка уже в памяти, и при попытке её снова > > > открыть - откроется старая so-шка. Чтобы загрузить новые модули > > > после изменения их so-файлов на диске - нужно делать upgrade. > > > > а чего он их тогда полез открывать-то? > > меня устроили бы старые модули. > > В новой конфигурации - новый список модулей, они открываются / > загружаются в соответствии с тем, что задано в директивах > load_module в конфиге. Поскольку в список добавился ndk - nginx > его попытался загрузить, поскольку в результате оказалось > загружено два одинаковых модуля - выдал ошибку и откатился на > предыдущую конфигурацию. погоди. изначально список модулей не менялся, но конфигурация не применилась потому что при открытии модуля выяснилось что его разбили на два и теперь у него символы не находятся. но как сказанно выше -- изменять загруженные модули нельзя, т.е. его и не надо было открывать и тогда этой ошибки и не было бы. так? From chipitsine на gmail.com Mon Jul 8 21:20:49 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 9 Jul 2019 02:20:49 +0500 Subject: =?UTF-8?B?dmFsZ3JpbmQg0YDRg9Cz0LDQtdGC0YHRjw==?= Message-ID: привет! смотрю valgrind-ом (nginx-1.17.1, openssl-1.1.1) ==12862== 8 bytes in 1 blocks are possibly lost in loss record 1 of 348 ==12862== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==12862== by 0x606D48D: CRYPTO_zalloc (mem.c:230) ==12862== by 0x5FD3956: CTLOG_STORE_new (ct_log.c:94) ==12862== by 0x5C99241: SSL_CTX_new (ssl_lib.c:2946) ==12862== by 0x44EE99: ngx_ssl_create (ngx_event_openssl.c:253) ==12862== by 0x4B6008: ngx_http_proxy_set_ssl (ngx_http_proxy_module.c:4265) ==12862== by 0x4B6008: ngx_http_proxy_merge_loc_conf (ngx_http_proxy_module.c:3231) ==12862== by 0x456FC2: ngx_http_merge_locations (ngx_http.c:648) ==12862== by 0x457E57: ngx_http_merge_servers (ngx_http.c:605) ==12862== by 0x457E57: ngx_http_block (ngx_http.c:268) ==12862== by 0x432915: ngx_conf_handler (ngx_conf_file.c:463) ==12862== by 0x432915: ngx_conf_parse (ngx_conf_file.c:319) ==12862== by 0x42FD69: ngx_init_cycle (ngx_cycle.c:275) ==12862== by 0x41C5B6: main (nginx.c:291) из-за чего такое может быть? есть какие-то best practice, как запускать valgrind ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jul 9 08:51:19 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 9 Jul 2019 11:51:19 +0300 Subject: location In-Reply-To: <20190708162433.GU2161@zxy.spb.ru> References: <20190705161701.GQ2161@zxy.spb.ru> <20190706173819.GO1877@mdounin.ru> <20190706180400.GR2161@zxy.spb.ru> <20190708132906.GR1877@mdounin.ru> <20190708135540.GT2161@zxy.spb.ru> <20190708161159.GT1877@mdounin.ru> <20190708162433.GU2161@zxy.spb.ru> Message-ID: <20190709085119.GV1877@mdounin.ru> Hello! On Mon, Jul 08, 2019 at 07:24:33PM +0300, Slawa Olhovchenkov wrote: > On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote: > > > > > > action тут разный. я на этом внимание не заострил, думал и так понятно > > > > > > > > Понятно. И также понятно, что даже при одном и том же action - > > > > приведённые команды делают разное, и результаты могут кардинально > > > > отличаться в том числе из-за этого. Именно поэтому я и указал на > > > > эту проблему как на одну из возможных причин наблюдаемого > > > > поведения. Дабы подобную проблему гарантированно исключить - > > > > лучше всего использовать одну и ту же форму команды. > > > > > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start` > > > > Зато бывает "service nginx reload" и "service nginx restart". > > > > (Ну и вообще, использовать "nginx -s ..." на юникс-системах - > > странно. Как минимум попадаем на двойной парсинг конфигурации, > > как максимум - на невозможность использовать эти команды, если > > PID-файл надо переложить в другое место.) > > набирать короче, давно заучил, а эти service вечно меняются... Форма "service " работает начиная с FreeBSD 7.3, и с момента появления не менялась. > > > > - После чего был сделан reload - и привёл к той же ошибке "module > > > > ... is already loaded", что было проигнорировано. Так > > > > > > нет, он не нашел ndk_* символов. > > > после чего я добавил строку с загрузко ndk_http. > > > > Не нашёл символов - в процессе тестирования конфигурации с помощью > > "nginx -t" и/или при парсинге конфигурации в процессе запуска > > "nginx -s"? > > вот тут не помню. > > > Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет > > загруженных модулей, и они получают то, что было на диске. И это > > одна из причин, почему reload не стоит предварять запуском "nginx -t", > > и не стоит использовать "nginx -s". > > ничего не понял. В рассматриваемом случае содержимое бинарных файлов на диске (nginx + модули) - поменялось. Более того, поменялось - несовместимо, для работы старых бинарных файлов требовалась одна конфигурация, для работы новых - другая. Когда такое происходит, использование "nginx -t" и "nginx -s " совместно с перезагрузкой конфигурации на лету - невозможно. Проблема в том, что эти команды требуют конфигурацию, совместимую с новыми бинарными файлами, тогда как для перезагрузки конфигурации работающего nginx'а - нужна конфигурация, совместимая со старыми бинарными файлами. Проще всего - в такую ситуацию не попадать, и после обновления бинарных файлов (что самого nginx'а, что модулей) - сразу делать upgrade, синхронизируя бинарники на дисках, и в памяти. Но вообще говоря работа в несинхронизированном состоянии тоже возможна - просто надо пользоваться сигналами, а не пытаться использовать nginx с диска (который не совпадает с тем, что в памяти). > > > > происходит, потому что с помощью reload'а нельзя изменить ранее > > > > загруженный модуль - so-шка уже в памяти, и при попытке её снова > > > > открыть - откроется старая so-шка. Чтобы загрузить новые модули > > > > после изменения их so-файлов на диске - нужно делать upgrade. > > > > > > а чего он их тогда полез открывать-то? > > > меня устроили бы старые модули. > > > > В новой конфигурации - новый список модулей, они открываются / > > загружаются в соответствии с тем, что задано в директивах > > load_module в конфиге. Поскольку в список добавился ndk - nginx > > его попытался загрузить, поскольку в результате оказалось > > загружено два одинаковых модуля - выдал ошибку и откатился на > > предыдущую конфигурацию. > > погоди. изначально список модулей не менялся, но конфигурация не > применилась потому что при открытии модуля выяснилось что его разбили > на два и теперь у него символы не находятся. Нет. Если бы конфигурацию, не меняя, перегрузили в работающем nginx'е с помощью сигналов - она бы прекрасно применилась. Проблема именно в том, что конфигурацию - изменили на такую, которая не совместима с работающим nginx'ом. > но как сказанно выше -- изменять загруженные модули нельзя, т.е. его и > не надо было открывать и тогда этой ошибки и не было бы. так? Когда дело дошло до загрузки конфигурации в работающем nginx'е - в этой самой конфигурации присутствовал как ранее загруженный модуль, так и дополнительный модуль, дублирующий часть ранее загруженного. Ранее загруженный модуль - фактически, просто перенесли как есть в новую конфигурацию в памяти. А при попытке загрузить дополнительный модуль (загружать новые модули - можно, в общем случае никаких проблем с этим нет) - произошла ошибка, из-за этого конфигурация не применилась. Единственное действие, которое могло бы предотвратить проблему - это не загружать _новый_ модуль. Но догадаться, что явно добавленный в конфигурацию модуль на самом деле загружать не надо - nginx не может. -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Tue Jul 9 09:07:52 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Tue, 9 Jul 2019 12:07:52 +0300 Subject: location In-Reply-To: <20190709085119.GV1877@mdounin.ru> References: <20190705161701.GQ2161@zxy.spb.ru> <20190706173819.GO1877@mdounin.ru> <20190706180400.GR2161@zxy.spb.ru> <20190708132906.GR1877@mdounin.ru> <20190708135540.GT2161@zxy.spb.ru> <20190708161159.GT1877@mdounin.ru> <20190708162433.GU2161@zxy.spb.ru> <20190709085119.GV1877@mdounin.ru> Message-ID: <20190709090752.GV2161@zxy.spb.ru> On Tue, Jul 09, 2019 at 11:51:19AM +0300, Maxim Dounin wrote: > Hello! > > On Mon, Jul 08, 2019 at 07:24:33PM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote: > > > > > > > > action тут разный. я на этом внимание не заострил, думал и так понятно > > > > > > > > > > Понятно. И также понятно, что даже при одном и том же action - > > > > > приведённые команды делают разное, и результаты могут кардинально > > > > > отличаться в том числе из-за этого. Именно поэтому я и указал на > > > > > эту проблему как на одну из возможных причин наблюдаемого > > > > > поведения. Дабы подобную проблему гарантированно исключить - > > > > > лучше всего использовать одну и ту же форму команды. > > > > > > > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start` > > > > > > Зато бывает "service nginx reload" и "service nginx restart". > > > > > > (Ну и вообще, использовать "nginx -s ..." на юникс-системах - > > > странно. Как минимум попадаем на двойной парсинг конфигурации, > > > как максимум - на невозможность использовать эти команды, если > > > PID-файл надо переложить в другое место.) > > > > набирать короче, давно заучил, а эти service вечно меняются... > > Форма "service " работает начиная с FreeBSD 7.3, и > с момента появления не менялась. есть еще линуксы в разных вариантах и они сбивают. а у них еще и имя сервиса различается в зависимости от пакета. ну и я с фрей работаю начиная с 2.0.5 :) > > > > > - После чего был сделан reload - и привёл к той же ошибке "module > > > > > ... is already loaded", что было проигнорировано. Так > > > > > > > > нет, он не нашел ndk_* символов. > > > > после чего я добавил строку с загрузко ndk_http. > > > > > > Не нашёл символов - в процессе тестирования конфигурации с помощью > > > "nginx -t" и/или при парсинге конфигурации в процессе запуска > > > "nginx -s"? > > > > вот тут не помню. > > > > > Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет > > > загруженных модулей, и они получают то, что было на диске. И это > > > одна из причин, почему reload не стоит предварять запуском "nginx -t", > > > и не стоит использовать "nginx -s". > > > > ничего не понял. > > В рассматриваемом случае содержимое бинарных файлов на диске > (nginx + модули) - поменялось. Более того, поменялось - > несовместимо, для работы старых бинарных файлов требовалась одна > конфигурация, для работы новых - другая. > > Когда такое происходит, использование "nginx -t" и "nginx -s > " совместно с перезагрузкой конфигурации на лету - > невозможно. Проблема в том, что эти команды требуют конфигурацию, > совместимую с новыми бинарными файлами, тогда как для перезагрузки > конфигурации работающего nginx'а - нужна конфигурация, совместимая > со старыми бинарными файлами. > > Проще всего - в такую ситуацию не попадать, и после обновления > бинарных файлов (что самого nginx'а, что модулей) - сразу делать > upgrade, синхронизируя бинарники на дисках, и в памяти. Но вообще > говоря работа в несинхронизированном состоянии тоже возможна - > просто надо пользоваться сигналами, а не пытаться использовать > nginx с диска (который не совпадает с тем, что в памяти). так, т.е. nginx -s reload не эквивалентно kill -HUP `cat /var/run/nginx.pid`? и вторая комманда срабоатла бы по старому варианту конфига и не стала бы ругаться на неопределенные символы? From mdounin на mdounin.ru Tue Jul 9 09:22:54 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 9 Jul 2019 12:22:54 +0300 Subject: location In-Reply-To: <20190709090752.GV2161@zxy.spb.ru> References: <20190705161701.GQ2161@zxy.spb.ru> <20190706173819.GO1877@mdounin.ru> <20190706180400.GR2161@zxy.spb.ru> <20190708132906.GR1877@mdounin.ru> <20190708135540.GT2161@zxy.spb.ru> <20190708161159.GT1877@mdounin.ru> <20190708162433.GU2161@zxy.spb.ru> <20190709085119.GV1877@mdounin.ru> <20190709090752.GV2161@zxy.spb.ru> Message-ID: <20190709092254.GX1877@mdounin.ru> Hello! On Tue, Jul 09, 2019 at 12:07:52PM +0300, Slawa Olhovchenkov wrote: > On Tue, Jul 09, 2019 at 11:51:19AM +0300, Maxim Dounin wrote: > > > Hello! > > > > On Mon, Jul 08, 2019 at 07:24:33PM +0300, Slawa Olhovchenkov wrote: > > > > > On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote: > > > > > > > > > > action тут разный. я на этом внимание не заострил, думал и так понятно > > > > > > > > > > > > Понятно. И также понятно, что даже при одном и том же action - > > > > > > приведённые команды делают разное, и результаты могут кардинально > > > > > > отличаться в том числе из-за этого. Именно поэтому я и указал на > > > > > > эту проблему как на одну из возможных причин наблюдаемого > > > > > > поведения. Дабы подобную проблему гарантированно исключить - > > > > > > лучше всего использовать одну и ту же форму команды. > > > > > > > > > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start` > > > > > > > > Зато бывает "service nginx reload" и "service nginx restart". > > > > > > > > (Ну и вообще, использовать "nginx -s ..." на юникс-системах - > > > > странно. Как минимум попадаем на двойной парсинг конфигурации, > > > > как максимум - на невозможность использовать эти команды, если > > > > PID-файл надо переложить в другое место.) > > > > > > набирать короче, давно заучил, а эти service вечно меняются... > > > > Форма "service " работает начиная с FreeBSD 7.3, и > > с момента появления не менялась. > > есть еще линуксы в разных вариантах и они сбивают. > а у них еще и имя сервиса различается в зависимости от пакета. > ну и я с фрей работаю начиная с 2.0.5 :) Если подходить к проблеме с точки зрения "есть ещё", то "nginx -s" вообще непоняно что делает, потому что a) nginx может быть более чем один, и б) в скриптах запуска может быть всяких опций прописано, включая другой конфиг. > > > > > > - После чего был сделан reload - и привёл к той же ошибке "module > > > > > > ... is already loaded", что было проигнорировано. Так > > > > > > > > > > нет, он не нашел ndk_* символов. > > > > > после чего я добавил строку с загрузко ndk_http. > > > > > > > > Не нашёл символов - в процессе тестирования конфигурации с помощью > > > > "nginx -t" и/или при парсинге конфигурации в процессе запуска > > > > "nginx -s"? > > > > > > вот тут не помню. > > > > > > > Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет > > > > загруженных модулей, и они получают то, что было на диске. И это > > > > одна из причин, почему reload не стоит предварять запуском "nginx -t", > > > > и не стоит использовать "nginx -s". > > > > > > ничего не понял. > > > > В рассматриваемом случае содержимое бинарных файлов на диске > > (nginx + модули) - поменялось. Более того, поменялось - > > несовместимо, для работы старых бинарных файлов требовалась одна > > конфигурация, для работы новых - другая. > > > > Когда такое происходит, использование "nginx -t" и "nginx -s > > " совместно с перезагрузкой конфигурации на лету - > > невозможно. Проблема в том, что эти команды требуют конфигурацию, > > совместимую с новыми бинарными файлами, тогда как для перезагрузки > > конфигурации работающего nginx'а - нужна конфигурация, совместимая > > со старыми бинарными файлами. > > > > Проще всего - в такую ситуацию не попадать, и после обновления > > бинарных файлов (что самого nginx'а, что модулей) - сразу делать > > upgrade, синхронизируя бинарники на дисках, и в памяти. Но вообще > > говоря работа в несинхронизированном состоянии тоже возможна - > > просто надо пользоваться сигналами, а не пытаться использовать > > nginx с диска (который не совпадает с тем, что в памяти). > > так, т.е. nginx -s reload не эквивалентно kill -HUP `cat /var/run/nginx.pid`? > и вторая комманда срабоатла бы по старому варианту конфига и не стала > бы ругаться на неопределенные символы? Именно так. Команда "nginx -s reload" сначала парсит конфиг, чтобы найти путь к этому самому /var/run/nginx.pid - и на этом пути делает много лишней (но неизбежной) работы, в частности - ругается, встретив неправильную с её точки зрения конфигурацию. Впрочем, завести привычку после обновления модулей делать upgrade (равно как и после обновления самого nginx'а) - в любом случае стоит. Если upgrade не сделать, а продолжать работать с тем, что в памяти, то при перезагрузке машины, например, может случиться неприятный сюрприз. -- Maxim Dounin http://mdounin.ru/ From swood на fotofor.biz Tue Jul 9 11:21:44 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Tue, 9 Jul 2019 12:21:44 +0100 Subject: too long parameter Message-ID: Здравствуйте. Пока не получается воспроизвести проблему, но в логе ошибок переодически возникает сообщение вида: too long parameter "# На строке, которая, и является комментарием: # this is search location for service srv784 Таких строчек-комментариев (конфиг генерируется скриптом) у меня в файле довольно много. Все бы и ничего, но nginx по каким-то причинам после этого сообщения перестает слушать порты на какое-то время. Что с этим можно сделать и вообще что это такое? Гугл не помог. Версия nginx 1.12.0. Сам конфиг, ну примитивный, 5 location без реврайтов и regexp. -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart на nginx.com Tue Jul 9 11:43:40 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 09 Jul 2019 14:43:40 +0300 Subject: =?UTF-8?B?UmU6IFtVbml0XSDQnNC40LPRgNCw0YbQuNGPINGBIGZhc3RjZ2kg0Lgg0LXRkSA=?= =?UTF-8?B?0L/QvtC00LLQvtC00L3Ri9C1INC60LDQvNC90Lg=?= In-Reply-To: <5415045.4z6ftBVuLT@note> References: <5415045.4z6ftBVuLT@note> Message-ID: <2066417.hUrgPIXCvX@vbart-laptop> On Tuesday, 2 July 2019 10:21:53 MSK Vadim A. Misbakh-Soloviov wrote: > Здравствуйте! > > Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз > столкнулся с проблемой того, что у fastcgi есть такая полезная штука как > split_path_info, где можно задать какая часть URI является значением > SCRIPT_NAME (да и вообще существует возможность динамического формирования > этого значения при запросе), а какая - идёт в PATH_INFO. [..] Добавили обработку PATH_INFO: http://hg.nginx.org/unit/rev/2a71417d297f Теперь всё, что будет следовать за ".php/" в запросе, попадет в PATH_INFO. -- Валентин Бартенев From mdounin на mdounin.ru Tue Jul 9 12:52:18 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 9 Jul 2019 15:52:18 +0300 Subject: too long parameter In-Reply-To: References: Message-ID: <20190709125218.GY1877@mdounin.ru> Hello! On Tue, Jul 09, 2019 at 12:21:44PM +0100, Anton Kiryushkin wrote: > Здравствуйте. > > Пока не получается воспроизвести проблему, но в логе ошибок переодически > возникает сообщение вида: > > too long parameter "# > На строке, которая, и является комментарием: > # this is search location for service srv784 > > Таких строчек-комментариев (конфиг генерируется скриптом) у меня в файле > довольно много. > Все бы и ничего, но nginx по каким-то причинам после этого сообщения > перестает слушать порты на какое-то время. > > Что с этим можно сделать и вообще что это такое? Гугл не помог. Версия > nginx 1.12.0. > Сам конфиг, ну примитивный, 5 location без реврайтов и regexp. Длина комментария, как и любого параметра, не может превышать 4096 байт. Если nginx ругается - скорее всего длина превышена. Если и правда ругается сообщением вида: > too long parameter "# то есть без каких-либо дополнительных символов после "#", то скорее всего речь о том, что файл застали в процессе генерации, и следом прочитались нули в больших количествах. -- Maxim Dounin http://mdounin.ru/ From swood на fotofor.biz Sun Jul 14 21:09:01 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sun, 14 Jul 2019 22:09:01 +0100 Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?= In-Reply-To: <5408858.Yfk6DYrYlT@vbart-workstation> References: <7040126.BHQ139x8JR@vbart-workstation> <5408858.Yfk6DYrYlT@vbart-workstation> Message-ID: Валентин, спасибо, за ваш совет, пересобрал Unit и получил довольно загадочную картину. К примеру. Вот сообщение в логе Unit: 2019/07/15 00:02:48.152 [warn] 20971#20971 [unit] #174772: application returned 500 response Окей, идем в лог ошибок php и ищем, что ж было: [15-Jul-2019 00:02:48 Europe/Moscow] Failed to connect [111]: Connection refused Внимание вопрос. Как тут узнать причину? ср, 3 июл. 2019 г. в 18:47, Валентин Бартенев : > On Wednesday 03 July 2019 12:47:01 Anton Kiryushkin wrote: > > Спасибо за ваш ответ. > > > > Ответ от php-fpm я мог найти в error-log nginx-a. Ну я не скажу, какую > > именно. Еще раз, проблема заключается в том, что в логе в access.log > nginx > > есть 500-й код ответа. Но причину этого 500-го кода нельзя найти в логе > > ошибок php (а там прописана опция error_log), и логе unit и в логе nginx, > > потому что там в принципе не должно быть этих ошибок. В случае с fpm в > логе > > ошибок nginx гарантированно причину можно было найти. Приложение не > > возвращает просто так 500-ю ошибку. > > > > Поэтому и возник вопрос, как же можно заставить unit писать лог любых > своих > > ошибок в какой-то файл. Ну или куда вообще можно было бы копать, так как > > возможные вещи, которые есть возможность предпринять в php, на мой > взгляд, > > предприняты. > [..] > > В error-log nginx писалось то, что приходило от php-fpm через stderr-канал, > а тот в свою очередь посылал туда то, что php писал в stderr. > > В случае Unit-а весь stderr из php направляется в unit.log и собственно там > и должен быть. > > Могу предложить попробовать собрать php модуль с патчем ниже. В этом > случае > всякий раз, когда php-интерпретатор возвращает ответ с 500-ым кодом, в > unit.log > будет об этом запись. > > 2019/07/03 20:45:02.899 [warn] 14919#14919 [unit] #7: application returned > 500 response > > Это, как минимум, позволит исключить ситуацию, что 500-ую генерирует сам > Unit > и не сообщает об этом по какой-то причине. > > -- > Валентин Бартенев > > > diff -r 2b068c8361f9 src/nxt_php_sapi.c > --- a/src/nxt_php_sapi.c Tue Jul 02 16:44:08 2019 +0300 > +++ b/src/nxt_php_sapi.c Wed Jul 03 20:32:38 2019 +0300 > @@ -774,6 +774,10 @@ nxt_php_send_headers(sapi_headers_struct > status = 200; > } > > + if (status == 500) { > + nxt_unit_req_warn(req, "application returned 500 response"); > + } > + > rc = nxt_unit_response_init(req, status, fields_count, resp_size); > if (nxt_slow_path(rc != NXT_UNIT_OK)) { > return SAPI_HEADER_SEND_FAILED; > > > _______________________________________________ > 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 vbart на nginx.com Mon Jul 15 14:51:16 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 15 Jul 2019 17:51:16 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?= In-Reply-To: References: <5408858.Yfk6DYrYlT@vbart-workstation> Message-ID: <1900499.Ib5OkVJtOm@vbart-workstation> On Sunday 14 July 2019 22:09:01 Anton Kiryushkin wrote: > Валентин, спасибо, за ваш совет, пересобрал Unit и получил довольно > загадочную картину. К примеру. > Вот сообщение в логе Unit: > 2019/07/15 00:02:48.152 [warn] 20971#20971 [unit] #174772: application > returned 500 response > > Окей, идем в лог ошибок php и ищем, что ж было: > [15-Jul-2019 00:02:48 Europe/Moscow] Failed to connect [111]: Connection > refused > > Внимание вопрос. Как тут узнать причину? > Ни в исходниках интерпретатора PHP, ни в исходниках Unit-а нет таких строчек. Следовательно строчка генерируется и пишется самими php скриптами. Имеет смысл сделать grep по всем php скриптам и таким образом найти где именно создается эта строчка и генерируется 500-ый ответ. С php-fpm в данном случае было бы ровно то же самое. -- Валентин Бартенев > ср, 3 июл. 2019 г. в 18:47, Валентин Бартенев : > > > On Wednesday 03 July 2019 12:47:01 Anton Kiryushkin wrote: > > > Спасибо за ваш ответ. > > > > > > Ответ от php-fpm я мог найти в error-log nginx-a. Ну я не скажу, какую > > > именно. Еще раз, проблема заключается в том, что в логе в access.log > > nginx > > > есть 500-й код ответа. Но причину этого 500-го кода нельзя найти в логе > > > ошибок php (а там прописана опция error_log), и логе unit и в логе nginx, > > > потому что там в принципе не должно быть этих ошибок. В случае с fpm в > > логе > > > ошибок nginx гарантированно причину можно было найти. Приложение не > > > возвращает просто так 500-ю ошибку. > > > > > > Поэтому и возник вопрос, как же можно заставить unit писать лог любых > > своих > > > ошибок в какой-то файл. Ну или куда вообще можно было бы копать, так как > > > возможные вещи, которые есть возможность предпринять в php, на мой > > взгляд, > > > предприняты. > > [..] > > > > В error-log nginx писалось то, что приходило от php-fpm через stderr-канал, > > а тот в свою очередь посылал туда то, что php писал в stderr. > > > > В случае Unit-а весь stderr из php направляется в unit.log и собственно там > > и должен быть. > > > > Могу предложить попробовать собрать php модуль с патчем ниже. В этом > > случае > > всякий раз, когда php-интерпретатор возвращает ответ с 500-ым кодом, в > > unit.log > > будет об этом запись. > > > > 2019/07/03 20:45:02.899 [warn] 14919#14919 [unit] #7: application returned > > 500 response > > > > Это, как минимум, позволит исключить ситуацию, что 500-ую генерирует сам > > Unit > > и не сообщает об этом по какой-то причине. > > > > -- > > Валентин Бартенев > > > > > > diff -r 2b068c8361f9 src/nxt_php_sapi.c > > --- a/src/nxt_php_sapi.c Tue Jul 02 16:44:08 2019 +0300 > > +++ b/src/nxt_php_sapi.c Wed Jul 03 20:32:38 2019 +0300 > > @@ -774,6 +774,10 @@ nxt_php_send_headers(sapi_headers_struct > > status = 200; > > } > > > > + if (status == 500) { > > + nxt_unit_req_warn(req, "application returned 500 response"); > > + } > > + > > rc = nxt_unit_response_init(req, status, fields_count, resp_size); > > if (nxt_slow_path(rc != NXT_UNIT_OK)) { > > return SAPI_HEADER_SEND_FAILED; > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Best regards, > Anton Kiryushkin From swood на fotofor.biz Mon Jul 15 22:11:07 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Mon, 15 Jul 2019 23:11:07 +0100 Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?= In-Reply-To: <1900499.Ib5OkVJtOm@vbart-workstation> References: <5408858.Yfk6DYrYlT@vbart-workstation> <1900499.Ib5OkVJtOm@vbart-workstation> Message-ID: Я прошу прощения, но все же можно ли выдрать по мотивам последнего патча хоть что-то еще, что, вероятно, вернул интерпретатор? Не только код, но может быть и хоть какое-то сообщение, а-ля дебаг-хардкор-только не в продакшн? Все exception в коде всегда имеют сообщение, но 500-е коды продолжаются. пн, 15 июл. 2019 г. в 15:51, Валентин Бартенев : > On Sunday 14 July 2019 22:09:01 Anton Kiryushkin wrote: > > Валентин, спасибо, за ваш совет, пересобрал Unit и получил довольно > > загадочную картину. К примеру. > > Вот сообщение в логе Unit: > > 2019/07/15 00:02:48.152 [warn] 20971#20971 [unit] #174772: application > > returned 500 response > > > > Окей, идем в лог ошибок php и ищем, что ж было: > > [15-Jul-2019 00:02:48 Europe/Moscow] Failed to connect [111]: Connection > > refused > > > > Внимание вопрос. Как тут узнать причину? > > > > Ни в исходниках интерпретатора PHP, ни в исходниках Unit-а нет таких > строчек. > > Следовательно строчка генерируется и пишется самими php скриптами. Имеет > смысл > сделать grep по всем php скриптам и таким образом найти где именно > создается эта > строчка и генерируется 500-ый ответ. > > С php-fpm в данном случае было бы ровно то же самое. > > -- > Валентин Бартенев > > > > > ср, 3 июл. 2019 г. в 18:47, Валентин Бартенев : > > > > > On Wednesday 03 July 2019 12:47:01 Anton Kiryushkin wrote: > > > > Спасибо за ваш ответ. > > > > > > > > Ответ от php-fpm я мог найти в error-log nginx-a. Ну я не скажу, > какую > > > > именно. Еще раз, проблема заключается в том, что в логе в access.log > > > nginx > > > > есть 500-й код ответа. Но причину этого 500-го кода нельзя найти в > логе > > > > ошибок php (а там прописана опция error_log), и логе unit и в логе > nginx, > > > > потому что там в принципе не должно быть этих ошибок. В случае с fpm > в > > > логе > > > > ошибок nginx гарантированно причину можно было найти. Приложение не > > > > возвращает просто так 500-ю ошибку. > > > > > > > > Поэтому и возник вопрос, как же можно заставить unit писать лог любых > > > своих > > > > ошибок в какой-то файл. Ну или куда вообще можно было бы копать, так > как > > > > возможные вещи, которые есть возможность предпринять в php, на мой > > > взгляд, > > > > предприняты. > > > [..] > > > > > > В error-log nginx писалось то, что приходило от php-fpm через > stderr-канал, > > > а тот в свою очередь посылал туда то, что php писал в stderr. > > > > > > В случае Unit-а весь stderr из php направляется в unit.log и > собственно там > > > и должен быть. > > > > > > Могу предложить попробовать собрать php модуль с патчем ниже. В этом > > > случае > > > всякий раз, когда php-интерпретатор возвращает ответ с 500-ым кодом, в > > > unit.log > > > будет об этом запись. > > > > > > 2019/07/03 20:45:02.899 [warn] 14919#14919 [unit] #7: application > returned > > > 500 response > > > > > > Это, как минимум, позволит исключить ситуацию, что 500-ую генерирует > сам > > > Unit > > > и не сообщает об этом по какой-то причине. > > > > > > -- > > > Валентин Бартенев > > > > > > > > > diff -r 2b068c8361f9 src/nxt_php_sapi.c > > > --- a/src/nxt_php_sapi.c Tue Jul 02 16:44:08 2019 +0300 > > > +++ b/src/nxt_php_sapi.c Wed Jul 03 20:32:38 2019 +0300 > > > @@ -774,6 +774,10 @@ nxt_php_send_headers(sapi_headers_struct > > > status = 200; > > > } > > > > > > + if (status == 500) { > > > + nxt_unit_req_warn(req, "application returned 500 response"); > > > + } > > > + > > > rc = nxt_unit_response_init(req, status, fields_count, resp_size); > > > if (nxt_slow_path(rc != NXT_UNIT_OK)) { > > > return SAPI_HEADER_SEND_FAILED; > > > > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru на nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > -- > > Best regards, > > Anton Kiryushkin > _______________________________________________ > 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 vbart на nginx.com Tue Jul 16 13:27:58 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 16 Jul 2019 16:27:58 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?= In-Reply-To: References: <1900499.Ib5OkVJtOm@vbart-workstation> Message-ID: <2675709.WDslNrlF7B@vbart-workstation> On Monday 15 July 2019 23:11:07 Anton Kiryushkin wrote: > Я прошу прощения, но все же можно ли выдрать по мотивам последнего патча > хоть что-то еще, что, вероятно, вернул интерпретатор? Не только код, но > может быть и хоть какое-то сообщение, а-ля дебаг-хардкор-только не в > продакшн? > Все exception в коде всегда имеют сообщение, но 500-е коды продолжаются. Дело в том, что судя по всему там не бросается exception, либо он молча перехватывается где-то там же в php коде. Вот пример с исключением. Конфигурация: { "listeners": { "127.0.0.1:8000": { "pass": "applications/500", } }, "applications": { "500": { "type": "php 5", "script": "500.php", "root": "/home/vbart/Development/tests/" } } } Содержимое 500.php: > пн, 15 июл. 2019 г. в 15:51, Валентин Бартенев : > > > On Sunday 14 July 2019 22:09:01 Anton Kiryushkin wrote: > > > Валентин, спасибо, за ваш совет, пересобрал Unit и получил довольно > > > загадочную картину. К примеру. > > > Вот сообщение в логе Unit: > > > 2019/07/15 00:02:48.152 [warn] 20971#20971 [unit] #174772: application > > > returned 500 response > > > > > > Окей, идем в лог ошибок php и ищем, что ж было: > > > [15-Jul-2019 00:02:48 Europe/Moscow] Failed to connect [111]: Connection > > > refused > > > > > > Внимание вопрос. Как тут узнать причину? > > > > > > > Ни в исходниках интерпретатора PHP, ни в исходниках Unit-а нет таких > > строчек. > > > > Следовательно строчка генерируется и пишется самими php скриптами. Имеет > > смысл > > сделать grep по всем php скриптам и таким образом найти где именно > > создается эта > > строчка и генерируется 500-ый ответ. > > > > С php-fpm в данном случае было бы ровно то же самое. > > > > -- > > Валентин Бартенев > > > > > > > > > ср, 3 июл. 2019 г. в 18:47, Валентин Бартенев : > > > > > > > On Wednesday 03 July 2019 12:47:01 Anton Kiryushkin wrote: > > > > > Спасибо за ваш ответ. > > > > > > > > > > Ответ от php-fpm я мог найти в error-log nginx-a. Ну я не скажу, > > какую > > > > > именно. Еще раз, проблема заключается в том, что в логе в access.log > > > > nginx > > > > > есть 500-й код ответа. Но причину этого 500-го кода нельзя найти в > > логе > > > > > ошибок php (а там прописана опция error_log), и логе unit и в логе > > nginx, > > > > > потому что там в принципе не должно быть этих ошибок. В случае с fpm > > в > > > > логе > > > > > ошибок nginx гарантированно причину можно было найти. Приложение не > > > > > возвращает просто так 500-ю ошибку. > > > > > > > > > > Поэтому и возник вопрос, как же можно заставить unit писать лог любых > > > > своих > > > > > ошибок в какой-то файл. Ну или куда вообще можно было бы копать, так > > как > > > > > возможные вещи, которые есть возможность предпринять в php, на мой > > > > взгляд, > > > > > предприняты. > > > > [..] > > > > > > > > В error-log nginx писалось то, что приходило от php-fpm через > > stderr-канал, > > > > а тот в свою очередь посылал туда то, что php писал в stderr. > > > > > > > > В случае Unit-а весь stderr из php направляется в unit.log и > > собственно там > > > > и должен быть. > > > > > > > > Могу предложить попробовать собрать php модуль с патчем ниже. В этом > > > > случае > > > > всякий раз, когда php-интерпретатор возвращает ответ с 500-ым кодом, в > > > > unit.log > > > > будет об этом запись. > > > > > > > > 2019/07/03 20:45:02.899 [warn] 14919#14919 [unit] #7: application > > returned > > > > 500 response > > > > > > > > Это, как минимум, позволит исключить ситуацию, что 500-ую генерирует > > сам > > > > Unit > > > > и не сообщает об этом по какой-то причине. > > > > > > > > -- > > > > Валентин Бартенев > > > > > > > > > > > > diff -r 2b068c8361f9 src/nxt_php_sapi.c > > > > --- a/src/nxt_php_sapi.c Tue Jul 02 16:44:08 2019 +0300 > > > > +++ b/src/nxt_php_sapi.c Wed Jul 03 20:32:38 2019 +0300 > > > > @@ -774,6 +774,10 @@ nxt_php_send_headers(sapi_headers_struct > > > > status = 200; > > > > } > > > > > > > > + if (status == 500) { > > > > + nxt_unit_req_warn(req, "application returned 500 response"); > > > > + } > > > > + > > > > rc = nxt_unit_response_init(req, status, fields_count, resp_size); > > > > if (nxt_slow_path(rc != NXT_UNIT_OK)) { > > > > return SAPI_HEADER_SEND_FAILED; > > > > > > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru на nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > -- > > > Best regards, > > > Anton Kiryushkin > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Best regards, > Anton Kiryushkin From nginx-forum на forum.nginx.org Fri Jul 19 16:17:14 2019 From: nginx-forum на forum.nginx.org (softshape) Date: Fri, 19 Jul 2019 12:17:14 -0400 Subject: =?UTF-8?B?QXV0b2luZGV4LCAibm8gbWFwcGluZyIg0Lgg0YDRg9GB0YHQutC40LUg0LjQvNC1?= =?UTF-8?B?0L3QsCDRhNCw0LnQu9C+0LIg0L/QvtC0IFdpbmRvd3M=?= Message-ID: Всем привет, у меня встала задача расшарить большой каталог под Windows "в Интернет" с помощью nginx. Autoindex on прекрасно справился с этой задачей, но только что касается английских имен файлов. Русские имена nginx показывает корректно, но при попытке перейти в русский каталог или скачать русский файл выходит 500я ошибка. В логах она звучит как "No mapping for the Unicode character exists in the target multi-byte code page" Что нужно донастроить, чтобы nginx под Windows начал понимать русские имена каталогов и файлов? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284913,284913#msg-284913 From nginx-forum на forum.nginx.org Sat Jul 20 09:56:40 2019 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Sat, 20 Jul 2019 05:56:40 -0400 Subject: =?UTF-8?B?YWNjZXB0LWVuY29kaW5nINC+0YIg0Y7Qt9C10YDQsA==?= Message-ID: <50dfc7dbc0e288472561fee71a7d3c3a.NginxMailingListRussian@forum.nginx.org> В документации не нашел. Есть ли какая-то переменная, чтобы посмотреть какие варианты encoding поддерживает клиент? Хоется что-то вроде такого реализовать: map $client_accept_encoding $myvar { "gzip" "zip" "br" "brotli" .... Вот $client_accept_encoding явно же где-то есть - не пойму где взять Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284937,284937#msg-284937 From rogat1y на gmail.com Sat Jul 20 18:23:28 2019 From: rogat1y на gmail.com (Maxim K) Date: Sat, 20 Jul 2019 21:23:28 +0300 Subject: =?UTF-8?B?UmU6IGFjY2VwdC1lbmNvZGluZyDQvtGCINGO0LfQtdGA0LA=?= In-Reply-To: <50dfc7dbc0e288472561fee71a7d3c3a.NginxMailingListRussian@forum.nginx.org> References: <50dfc7dbc0e288472561fee71a7d3c3a.NginxMailingListRussian@forum.nginx.org> Message-ID: https://nginx.org/en/docs/http/ngx_http_core_module.html#var_http_ сб, 20 июл. 2019 г. в 12:56, Dmytro Lavryk : > В документации не нашел. Есть ли какая-то переменная, чтобы посмотреть > какие > варианты encoding поддерживает клиент? Хоется что-то вроде такого > реализовать: > map $client_accept_encoding $myvar { > "gzip" "zip" > "br" "brotli" > .... > > Вот $client_accept_encoding явно же где-то есть - не пойму где взять > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,284937,284937#msg-284937 > > _______________________________________________ > 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 Jul 22 16:17:55 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Mon, 22 Jul 2019 12:17:55 -0400 Subject: =?UTF-8?B?U1NMINGB0LXRgNGC0LjRhNC40LrQsNGC0Ys=?= Message-ID: Можно как-то обойтись без reload (SIGHUP) nginx для того чтобы он перечитал с диска сертификаты (ssl_certificate)? Без этого он не бывает в курсе что они были обновлены. Но у релоад есть плохая штука что он наверняка забывает такие вещи как inactive=nnn в директиве proxy_cache_path, и если reload происходит раз в неделю, то любой inactive выше недели по сути ничего не делает. Также каждый релоад требует перечтения всех имеющихся данных cache loader'ом, а когда таких данных сотни гигов и диски (пока :)) крутящиеся, директива max_size не способна ограничивать дисковое пространство (т.к. пока loader все файлы не перечитает nginx не знает сколько пространства занято, если не ошибаюсь). Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284950#msg-284950 From mdounin на mdounin.ru Mon Jul 22 16:39:52 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 22 Jul 2019 19:39:52 +0300 Subject: =?UTF-8?B?UmU6IFNTTCDRgdC10YDRgtC40YTQuNC60LDRgtGL?= In-Reply-To: References: Message-ID: <20190722163952.GJ1877@mdounin.ru> Hello! On Mon, Jul 22, 2019 at 12:17:55PM -0400, rihad wrote: > Можно как-то обойтись без reload (SIGHUP) nginx для того чтобы он перечитал > с диска сертификаты (ssl_certificate)? Без этого он не бывает в курсе что > они были обновлены. В свежих версиях - можно, если в директиве ssl_certificate будут использоваться переменные, то nginx будет грузить эти сертификаты при каждом SSL handshake'е. Но лучше так не делать без острой нужды, так как у этого подхода хватает своих проблем - начиная от производительности (так как сертификаты и ключи загружаются при каждом handshake'е) и заканчивая безопасностью (при такой схеме требуются права на чтение ключей не только root'у, но и рабочим процессам nginx'а). > Но у релоад есть плохая штука что он наверняка забывает > такие вещи как inactive=nnn в директиве proxy_cache_path, и если reload > происходит раз в неделю, то любой inactive выше недели по сути ничего не > делает. Это не так. Если конфигурация кэша не менялась - то данные о активности элементов кэша при reload'е не теряются. > Также каждый релоад требует перечтения всех имеющихся данных cache > loader'ом, а когда таких данных сотни гигов и диски (пока :)) крутящиеся, > директива max_size не способна ограничивать дисковое пространство (т.к. пока > loader все файлы не перечитает nginx не знает сколько пространства занято, > если не ошибаюсь). И это не так. Если конфигурация кэша не менялась - информация о содержимом кэша при reload'е не перечитывается. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Jul 22 17:04:19 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Mon, 22 Jul 2019 13:04:19 -0400 Subject: =?UTF-8?B?UmU6IFNTTCDRgdC10YDRgtC40YTQuNC60LDRgtGL?= In-Reply-To: <20190722163952.GJ1877@mdounin.ru> References: <20190722163952.GJ1877@mdounin.ru> Message-ID: Спасибо! Да, проверил, если не меняется ничего, то cache loader при релоаде не запускается. Я просто релоадил когда что-то менял, поэтому подумал что всегда так ) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284952#msg-284952 From nginx-forum на forum.nginx.org Mon Jul 22 17:12:38 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Mon, 22 Jul 2019 13:12:38 -0400 Subject: =?UTF-8?B?UmU6IFNTTCDRgdC10YDRgtC40YTQuNC60LDRgtGL?= In-Reply-To: References: <20190722163952.GJ1877@mdounin.ru> Message-ID: И еще параллельно такой вопрос возник: у нас крутящиеся диски на одном из серверов, и proxy_cache_path levels=1:2 все это приводит к тому, что в каждой директории где-то 3-4 тысячи файлов (я так понимаю поменять на 2:2 + reload уже нельзя?). cache_loader при старте работает довольно долго, но не грузит. Он очень мало CPU времени тратит или дискового, за сутки работы сейчас он потратил 0:04.37 (согласно ps) это 4 минуты, но он не заканчивается. lsof показывает что он очень много времени проводит на каждой из директорий кэша. А их тысячи. Надеюсь он не читает весь файл (преимущественно картинки), а только его начало с заголовками? )) Может ли его такая тормознутость привести к повторному запросу ресурса из источника и повторному кэшированию? Что делает nginx когда в кэше пока объекта нет, пытается ли сам к диску обратиться? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284953#msg-284953 From mdounin на mdounin.ru Mon Jul 22 18:12:36 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 22 Jul 2019 21:12:36 +0300 Subject: =?UTF-8?B?UmU6IFNTTCDRgdC10YDRgtC40YTQuNC60LDRgtGL?= In-Reply-To: References: <20190722163952.GJ1877@mdounin.ru> Message-ID: <20190722181236.GK1877@mdounin.ru> Hello! On Mon, Jul 22, 2019 at 01:12:38PM -0400, rihad wrote: > И еще параллельно такой вопрос возник: у нас крутящиеся диски на одном из > серверов, и proxy_cache_path levels=1:2 все это приводит к тому, что в > каждой директории где-то 3-4 тысячи файлов 3-4 тысячи файлов на каталог - это плюс-минус нормально. > (я так понимаю поменять на 2:2 + reload уже нельзя?). Да, поменять levels можно только создав новый кэш, перекладывать из одной структуры в другую nginx не умеет. Если попытаться поменять levels при reload'е - nginx выругается и откажется загружать новую конфигурацию. Если остановить и запустить заново - сотрёт содержимое, не соответствующее заданным levels. > cache_loader при старте работает довольно долго, но не > грузит. Он очень мало CPU времени тратит или дискового, за сутки работы > сейчас он потратил 0:04.37 (согласно ps) это 4 минуты, но он не > заканчивается. lsof показывает что он очень много времени проводит на каждой > из директорий кэша. А их тысячи. Надеюсь он не читает весь файл > (преимущественно картинки), а только его начало с заголовками? )) Сейчас cache loader вообще не читает файлы, только каталоги. Чтобы работал побыстрее - можно поиграться с параметрами loader_files, loader_threshold и loader_sleep, подробности тут: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path Алгоритм загрузки кэша такой, чтобы не создавать излишней нагрузки на диски, и соответственно чтобы сервис не деградировал в процессе загрузки кэша. При параметрах по умолчанию - loader_files 100, loader_sleep 50 миллисекунд - и бесконечно быстрых дисках - загрузка кэша с 16 миллионами файлов (16 x 16 x 16 x 4000 = 16384000) должна занимать чуть больше трёх часов (50ms * 16384000 / 100 = 8192000ms = 8192s). Если загрузка занимает больше - значит, срабатывает loader_threshold, и loader спит чаще, чем раз в 100 файлов. Для вращающихся дисков это нормально. Но это и в свою очередь означает, что если для ускорения загрузки начать увеличивать loader_files и loader_threshold, а равно уменьшать loader_sleep - нагрузка на диски станет больше, и кэш может начать тормозить. > Может ли > его такая тормознутость привести к повторному запросу ресурса из источника и > повторному кэшированию? Что делает nginx когда в кэше пока объекта нет, > пытается ли сам к диску обратиться? Если загрузка кэша не завершена - nginx при обращении к элементу кэша, которого ещё нет в памяти, явно проверяет, есть ли соответствующий файл на диске. То есть к лишним обращениям на бэкенд это не приводит. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Jul 22 18:20:16 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Mon, 22 Jul 2019 14:20:16 -0400 Subject: =?UTF-8?B?UmU6IFNTTCDRgdC10YDRgtC40YTQuNC60LDRgtGL?= In-Reply-To: <20190722181236.GK1877@mdounin.ru> References: <20190722181236.GK1877@mdounin.ru> Message-ID: <9a3bca25b82354b88e5e96a5b61d5114.NginxMailingListRussian@forum.nginx.org> Спасибо огромное за инфу! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284955#msg-284955 From nginx-forum на forum.nginx.org Tue Jul 23 03:44:27 2019 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Mon, 22 Jul 2019 23:44:27 -0400 Subject: 110 Connection time out (keepalive upstream) Message-ID: <6dab3fe25cc3ae4133627853a5335398.NginxMailingListRussian@forum.nginx.org> Тестирую использование кэша соединений для группы серверов. Настройка дефолтная: keepalive 32; keepalive_timeout 30; keepalive_requests 100; proxy_connect_timeout 1; proxy_send_timeout 60; proxy_read_timeout 60; При отключении одного бекенда из апстрима, ловим порядка 6-8 (110 Connection time out) при 100rps, использование дин портов 150 Попытки покрутить keepalive, keepalive_timeout, keepalive_requests привели к 1-2 (110 Connection time out) со следующими значениями : keepalive 8; keepalive_timeout 1; keepalive_requests 200; использование дин портов на уровне 2000 Есть ли какие-то бестпрактикс по данному кейсу, на что стоит обратить внимание? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284957,284957#msg-284957 From nginx-forum на forum.nginx.org Tue Jul 23 06:40:59 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Tue, 23 Jul 2019 02:40:59 -0400 Subject: =?UTF-8?B?UmU6IFNTTCDRgdC10YDRgtC40YTQuNC60LDRgtGL?= In-Reply-To: <20190722181236.GK1877@mdounin.ru> References: <20190722181236.GK1877@mdounin.ru> Message-ID: <551e6fe8c2e78f9a7858ce4bd09f97c9.NginxMailingListRussian@forum.nginx.org> > Если загрузка кэша не завершена - nginx при обращении к элементу > кэша, которого ещё нет в памяти, явно проверяет, есть ли > соответствующий файл на диске. То есть к лишним обращениям на > бэкенд это не приводит. Глядя на объемы памяти RSS, а также на текущий обрабатываемый каталог из вывода lsof, у меня такое впечатление что при SIGHUP nginx и запуске второго cache loader (первый при этом не умирает, убиваю его через TERM вручную) уже прочитанные объекты из shared memory не стираются, т.е. он просто продолжает откуда его прервали. Так ли это? Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284958#msg-284958 From mdounin на mdounin.ru Tue Jul 23 08:53:12 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 23 Jul 2019 11:53:12 +0300 Subject: =?UTF-8?B?UmU6IFNTTCDRgdC10YDRgtC40YTQuNC60LDRgtGL?= In-Reply-To: <551e6fe8c2e78f9a7858ce4bd09f97c9.NginxMailingListRussian@forum.nginx.org> References: <20190722181236.GK1877@mdounin.ru> <551e6fe8c2e78f9a7858ce4bd09f97c9.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190723085312.GM1877@mdounin.ru> Hello! On Tue, Jul 23, 2019 at 02:40:59AM -0400, rihad wrote: > > Если загрузка кэша не завершена - nginx при обращении к элементу > > кэша, которого ещё нет в памяти, явно проверяет, есть ли > > соответствующий файл на диске. То есть к лишним обращениям на > > бэкенд это не приводит. > > Глядя на объемы памяти RSS, а также на текущий обрабатываемый каталог из > вывода lsof, у меня такое впечатление что при SIGHUP nginx и запуске > второго cache loader (первый при этом не умирает, убиваю его через TERM > вручную) уже прочитанные объекты из shared memory не стираются, т.е. он > просто продолжает откуда его прервали. Так ли это? Спасибо. Вообще если cache loader уже работает с кэшом, то новый cache loader при релоаде не запускается. Может запуститься, если кэшей больше одного - и начнёт загружать другие кэши. Каждый кэш загружается единожды, так что наличие больее чем одного cache loader'а - влияет разве что на параллелизм процесса. Уже загруженные элементы из памяти, естественно, не стираются, но продолжать откуда прервали cache loader не умеет, и в случае чего будет обходить каталог кэша заново. Если кэшей много, и какие-то полностью загружены - они загружаться заново не будут. Но вообще убивать старый cache loader - это в любом случае плохая идея, с некоторой вероятностью не повезёт (практически гарантированно, если не успеть в первую минуту после запуска нового cache loader'а), и кэш, с которым он работал, так и останется незагруженным. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Jul 23 12:23:15 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 23 Jul 2019 15:23:15 +0300 Subject: nginx-1.17.2 Message-ID: <20190723122315.GS1877@mdounin.ru> Изменения в nginx 1.17.2 23.07.2019 *) Изменение: минимальная поддерживаемая версия zlib - 1.2.0.4. Спасибо Илье Леошкевичу. *) Изменение: метод $r->internal_redirect() встроенного перла теперь ожидает закодированный URI. *) Добавление: теперь с помощью метода $r->internal_redirect() встроенного перла можно перейти в именованный location. *) Исправление: в обработке ошибок во встроенном перле. *) Исправление: на старте или во время переконфигурации мог произойти segmentation fault, если в конфигурации использовалось значение hash bucket size больше 64 килобайт. *) Исправление: при использовании методов обработки соединений select, poll и /dev/poll nginx мог нагружать процессор во время небуферизованного проксирования и при проксировании WebSocket-соединений. *) Исправление: в модуле ngx_http_xslt_filter_module. *) Исправление: в модуле ngx_http_ssi_filter_module. -- Maxim Dounin http://nginx.org/ From simplebox66 на gmail.com Fri Jul 26 07:56:35 2019 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 26 Jul 2019 10:56:35 +0300 Subject: =?UTF-8?B?UmU6INC+0LHRgNCw0LHQvtGC0LrQsCBzZXRfcmVhbF9pcF9mcm9tINC00LvRjyA0?= =?UTF-8?B?MDAt0YUg0YHRgtCw0YLRg9GB0L7Qsg==?= In-Reply-To: References: Message-ID: Столкнулся с такой же проблемой. Есть какое-то объяснение этому? пт, 14 июн. 2019 г. в 20:12, Илья Шипицин : > привет! > > стенд: > > nginx-1.17.0 из официального репо. > конфиг > > user root; > worker_processes 1; > > error_log /var/log/nginx/error.log warn; > pid /var/run/nginx.pid; > > events { > worker_connections 1024; > } > > > http { > include /etc/nginx/mime.types; > default_type application/octet-stream; > > log_format custom '$remote_addr\t$http_x_real_ip\t$status\t$uri'; > set_real_ip_from 127.0.0.1; > > access_log /var/log/nginx/access.log custom; > > server { > listen 80; > server_name localhost; > location / { return 200; } > } > > server { > listen 80; > server_name _; > location / { return 200; } > } > > } > > > ========================= > делаю два запроса > > curl --header "X-Real-IP: 8.9.10.11" -vvvv -I -k http://localhost/test > curl --header "X-Real-IP: 8.9.10.11" -vvvv -I -k http://localhost/%%%%% > > получаю > > # cat /var/log/nginx/access.log > 8.9.10.11 8.9.10.11 200 /test > 127.0.0.1 - 400 > > > почему магия с форматом лога и хедерами работает на 200-х статусах и не > работает на 400-х ? это такая задумка ? выглядит как баг. > > Илья Шипицин > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Jul 29 13:22:05 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Jul 2019 16:22:05 +0300 Subject: =?UTF-8?B?UmU6INC+0LHRgNCw0LHQvtGC0LrQsCBzZXRfcmVhbF9pcF9mcm9tINC00LvRjyA0?= =?UTF-8?B?MDAt0YUg0YHRgtCw0YLRg9GB0L7Qsg==?= In-Reply-To: References: Message-ID: <20190729132205.GZ1877@mdounin.ru> Hello! On Fri, Jul 26, 2019 at 10:56:35AM +0300, Иван Мишин wrote: > Столкнулся с такой же проблемой. Есть какое-то объяснение этому? [...] > > curl --header "X-Real-IP: 8.9.10.11" -vvvv -I -k http://localhost/test > > curl --header "X-Real-IP: 8.9.10.11" -vvvv -I -k http://localhost/%%%%% > > > > получаю > > > > # cat /var/log/nginx/access.log > > 8.9.10.11 8.9.10.11 200 /test > > 127.0.0.1 - 400 > > > > > > почему магия с форматом лога и хедерами работает на 200-х статусах и не > > работает на 400-х ? это такая задумка ? выглядит как баг. Запрос к "/%%%%%" распарсить невозможно, так как сочетание "%%" недопустимо по стандартну HTTP. Соответственно ошибка возникает уже на этапе парсинга request line, и ни о какой обработке такого запроса речи не идёт. Соответственно не будет работать и realip-модуль. Более того - в данном конкретном случае, так как ошибка возникает на этапе парсинга request line, то в тех ошмётках запроса, которые nginx успел распарсить - заголовка X-Real-IP не будет. То есть в данном случае даже если бы модуль realip что-то попытался сделать с запросом - у него ничего бы не получилось. А равно ничего не получится увидеть при логгировании $http_x_real_ip. Отдельно отмечу, что с точки зрения логики работы - текущее поведение выглядит как наиболее правильное. Если с IP-адреса приходит невалидный HTTP-запрос, то даже если этот адрес вдруг значится в set_real_ip_from - логгировать надо именно адрес, с которого нам прислали этот невалидный запрос, потому как разбираться надо именно с тем софтом, что на этом адресе стоит и невалидный запрос сформировал. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Jul 29 14:36:18 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Mon, 29 Jul 2019 10:36:18 -0400 Subject: could not allocate node in cache keys zone "xxx" Message-ID: <15e4a1f81a647ff03ad41d45ac849a55.NginxMailingListRussian@forum.nginx.org> Когда cache loader читает эакешированные файлы при запуске nginx, если proxy_cache_path max_size недостаточно велика, вот такие ошибки начинают сыпаться под конец. Насколько это плохо? Может это повлиять на невозможность кэшировать новые файлы, и в целом на нормальную работу? Можно чтобы это предотвратить выделить сразу много памяти, все равно как я понял nginx выделяет эту память мелкими порциями и используется в RSS не больше, чем нужно, так ли это? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285024,285024#msg-285024