From mif на me.com  Sat Jun  1 10:57:30 2019
From: mif на me.com (Alexey Galygin)
Date: Sat, 1 Jun 2019 13:57:30 +0300
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <CAFHpkQE79aTtDAsy7d=X-LB9CxREf5MgmGPk2E+1X2Dp1jzbFw@mail.gmail.com>
References: <4629586a-6a30-4b84-a701-ac32ad230483@Spark>
 <8a61154607f5f49bcfb184d9e3118078.NginxMailingListRussian@forum.nginx.org>
 <9c1fae5f-8755-4a65-ab5d-d7390622b4cc@Spark>
 <CAFHpkQE79aTtDAsy7d=X-LB9CxREf5MgmGPk2E+1X2Dp1jzbFw@mail.gmail.com>
Message-ID: <70bd2b61-b048-4279-987b-841f9c231e7f@Spark>

там на самом деле 6 точек
и ни в одной нет проверок

я посмотрел по другим модулям – там хоть как-то проверяют

в зависимости от назначения функций могут быть разные требования к логике

я пока такие правки внёс

~/work/nginx-1.16.0/src/http/modules/perl # diff nginx.xs nginx.xs.bak
75,76d74
< if (!ctx)
< return NGX_ERROR;
384,385d381
< if (!ctx)
< XSRETURN_UNDEF;
554,555d549
< if (!ctx)
< XSRETURN_UNDEF;
797,798d790
< if (!ctx)
< XSRETURN_EMPTY;
929,930d920
< if (!ctx)
< XSRETURN_UNDEF;
1013,1014d1002
< if (!ctx)
< XSRETURN_UNDEF;

я не разработчик nginx и не знаю насколько это корректно

буду наблюдать дальше за падениями
On 1 Jun 2019, 01:19 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> а попробуйте вот так
>
> if (ctx && ctx->ssi) {
>
> > сб, 1 июн. 2019 г. в 01:58, Alexey Galygin via nginx-ru <nginx-ru на nginx.org>:
> > > понятно, спасибо
> > > подумаем над отдельным инстансом
> > >
> > > на всякий случай я тикет завёл
> > >
> > > https://trac.nginx.org/nginx/ticket/1786#ticket
> > >
> > > в идеале бы, конечно кэш как-то пересчитывать бы надо после падения воркеров…
> > > On 31 May 2019, 23:50 +0300, ngnx8810773a83 <nginx-forum на forum.nginx.org>, wrote:
> > > > Если воркер отваливается по сигналу, то все что им было залочено в кеше
> > > > остается залоченым навечно (до перезапуска мастера). Мастер запускает нового
> > > > воркера поэтому внешне все продолжает работать,, но если в момент падения
> > > > были залочены элементы кеша то ой.. они залочены. снять лок некому, джругие
> > > > воркеры подождут сняти лока да и дальше пойдут в соотв с настройками... Судя
> > > > по всему такое поведение было всегда. Покрайней мере мы это проходили много
> > > > лет назад. нет падений - нет проблем с кешом. есть падения - надо из лечить
> > > > и тогда уходят проблемы с кешоми.
> > > >
> > > > Перловый модуль вообще падучий, если нет возможности от него отказаться
> > > > совсем, то я бы на вашем месте поппробовал вынести его в отдельный инстанс,
> > > > чтобы падения перлового модуля не отражались на остальном хотябы.. Хотя бы
> > > > даже если не из за падений, а из за того что рерл модуль лочит весь воркер,
> > > > пока перл работает воркер более запросов не обрабатывает (вот где
> > > > остановлись запросы, там и висят, ждут перла)..
> > > >
> > > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284370,284386#msg-284386
> > > >
> > > > _______________________________________________
> > > > nginx-ru mailing list
> > > > nginx-ru на nginx.org
> > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > > _______________________________________________
> > > nginx-ru mailing list
> > > nginx-ru на nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190601/9960305d/attachment.html>

From nginx на mva.name  Sat Jun  1 18:14:13 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sat, 01 Jun 2019 21:14:13 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?=
In-Reply-To: <2632802.ZtBez7UN1Q@vbart-workstation>
References: <2632802.ZtBez7UN1Q@vbart-workstation>
Message-ID: <19074713.0MHNi1taL6@note>

К слову:


src/nxt_string.c: In function ‘nxt_strverscmp’:
src/nxt_string.c:414:12: warning: this statement may fall through [-Wimplicit-
fallthrough=]
src/nxt_string.c:420:5: note: here
src/nxt_murmur_hash.c: In function ‘nxt_murmur_hash2’:
src/nxt_murmur_hash.c:39:11: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_murmur_hash.c:41:5: note: here
src/nxt_murmur_hash.c:42:11: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_murmur_hash.c:44:5: note: here
src/nxt_vector.c: In function ‘nxt_vector_destroy’:
src/nxt_vector.c:63:9: warning: this statement may fall through [-Wimplicit-
fallthrough=]
src/nxt_vector.c:67:5: note: here
src/nxt_timer.c: In function ‘nxt_timer_changes_commit’:
src/nxt_timer.c:191:16: warning: this statement may fall through [-Wimplicit-
fallthrough=]
src/nxt_timer.c:197:9: note: here
src/nxt_http_parse.c: In function ‘nxt_http_parse_request_line’:
src/nxt_http_parse.c:365:20: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:369:13: note: here
src/nxt_http_parse.c:370:20: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:374:13: note: here
src/nxt_http_parse.c:375:20: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:379:13: note: here
src/nxt_http_parse.c: In function ‘nxt_http_parse_complex_target’:
src/nxt_http_parse.c:902:36: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:904:13: note: here
src/nxt_http_parse.c:936:36: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:938:13: note: here
src/nxt_http_parse.c:973:36: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:975:13: note: here
src/nxt_http_parse.c:1017:36: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:1019:13: note: here
src/nxt_http_parse.c: In function ‘nxt_http_lookup_field_end’:
src/nxt_http_parse.c:739:78: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:741:5: note: here
src/nxt_http_parse.c:742:78: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_parse.c:744:5: note: here
src/nxt_conf_validation.c: In function ‘nxt_conf_vldt_match_pattern’:
src/nxt_conf_validation.c:800:16: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_conf_validation.c:811:9: note: here
src/nxt_http_route.c: In function ‘nxt_http_route_pattern’:
src/nxt_http_route.c:1566:21: warning: this statement may fall through [-
Wimplicit-fallthrough=]
src/nxt_http_route.c:1570:5: note: here



From vbart на nginx.com  Sat Jun  1 18:44:02 2019
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Sat, 01 Jun 2019 21:44:02 +0300
Subject: Unitd + client_addr
In-Reply-To: <CAM_jxg2ebcKT6tJ7U1OkB2n5yFhbY3Em8eQ08+o3wmLp6n1h5A@mail.gmail.com>
References: <CAM_jxg2ebcKT6tJ7U1OkB2n5yFhbY3Em8eQ08+o3wmLp6n1h5A@mail.gmail.com>
Message-ID: <1867308.vFq0PfKWZg@vbart-laptop>

On Friday, 31 May 2019 18:51:15 MSK Anton Kiryushkin wrote:
> Здравствуйте.
> 
> Не подскажете, какова судьба вот этого тикета:
> https://github.com/nginx/unit/issues/132
> 
> А так же, возможно, есть прямой способ, как получить в php, запускаемом
> через unit клиентский айпишник? Сейчас там 127.0.0.1, что очень и очень
> плохо и ставит использование unit под жирный вопрос.
> 
[..]


Самый простой способ сейчас - это сделать прослойку в виде отдельного .php
скрипта, который будет подменять REMOTE_ADDR из заголовка и include-ить скрипты
приложения.

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

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

--
Валентин Бартенев

From vbart на nginx.com  Sat Jun  1 18:47:37 2019
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Sat, 01 Jun 2019 21:47:37 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?=
In-Reply-To: <19074713.0MHNi1taL6@note>
References: <2632802.ZtBez7UN1Q@vbart-workstation> <19074713.0MHNi1taL6@note>
Message-ID: <222779983.lpQCaMCqRc@vbart-laptop>

On Saturday, 1 June 2019 21:14:13 MSK Vadim A. Misbakh-Soloviov wrote:
> К слову:
> 
> 
> src/nxt_string.c: In function ‘nxt_strverscmp’:
> src/nxt_string.c:414:12: warning: this statement may fall through [-Wimplicit-
> fallthrough=]
[..]

Во всех этих местах стоит комментарий /* Fall through. */ и современный GCC
умеет их распознавать и не выдавать warning-а в этих случаях.

--
Валентин Бартенев

From nginx на mva.name  Sat Jun  1 23:05:47 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sun, 02 Jun 2019 02:05:47 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?=
In-Reply-To: <222779983.lpQCaMCqRc@vbart-laptop>
References: <2632802.ZtBez7UN1Q@vbart-workstation> <19074713.0MHNi1taL6@note>
 <222779983.lpQCaMCqRc@vbart-laptop>
Message-ID: <9197637.6rt8WEU2qH@note>

Ну, видимо, или gcc-9.1.0 более не удовлетворён ими, или, возможно, это 
произошло из-за рассинхрона версий distcc на хостах (впрочем, 7-то, вроде, 
тоже уже умел).

Попробую проверить при ближайшем ребилде...

From pluknet на nginx.com  Mon Jun  3 11:07:01 2019
From: pluknet на nginx.com (Sergey Kandaurov)
Date: Mon, 3 Jun 2019 14:07:01 +0300
Subject: =?UTF-8?B?UmU6IHNlcnZlciBuYW1lINGBINC80LDRgdC60LDQvNC4INCyINGA0LDQt9C90Ys=?=
 =?UTF-8?B?0LUg0LrQvtC90YTQuNCz0Lg=?=
In-Reply-To: <e7bad74624e04af3d7c094ecc59d7fa6.NginxMailingListRussian@forum.nginx.org>
References: <e7bad74624e04af3d7c094ecc59d7fa6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <A3BB0474-20CB-46DD-8C53-9A46E57FE8C2@nginx.com>


> On 1 Jun 2019, at 00:07, valet <nginx-forum на forum.nginx.org> wrote:
> 
> Есть 3 конфига nginx:
> 1. общий для всех сайтов (домены типа sub1.site.ru, sub2.site.ru, ... ,
> subn.site.ru)
> 2. общий для для всех статистик сайтов (домены типа stat.sub1.site.ru,
> stat.sub2.site.ru, ... , stat.subn.site.ru)
> 3. общий для всех изображений (домены типа images.sub1.site.ru,
> images.sub2.site.ru, ... , images.subn.site.ru)
> 
> То есть:
> любой поддомен, начинающийся на stat. должен попадать в конфиг 2
> любой поддомен, начинающийся на images. должен попадать в конфиг 3
> а все остальные поддомены должны попадать в конфиг 1
> 
> Для этих конфигов в server_name прописал так
> 1. server_name *.site.ru
> 2. server_name stat.*
> 3. server_name images.*
> 
> Но это работает неправильно. Подскажите пожалуйста как правильно?

Первый вариант будет в приоритете, так устроен
порядок обхода виртуальных серверов, см.
http://nginx.org/ru/docs/http/server_names.html

Как вариант - переделать на регулярные выражения.

-- 
Sergey Kandaurov


From nginx-forum на forum.nginx.org  Tue Jun  4 14:40:23 2019
From: nginx-forum на forum.nginx.org (kron)
Date: Tue, 04 Jun 2019 10:40:23 -0400
Subject: proxy_pass to variable and upstream server temporarily disabled
 variable
In-Reply-To: <681DB322-92CF-4261-AC07-7EF14A00A617@nginx.com>
References: <681DB322-92CF-4261-AC07-7EF14A00A617@nginx.com>
Message-ID: <5a381e879e59f7991c459655e385d397.NginxMailingListRussian@forum.nginx.org>

> В случае если адрес сервера в proxy_pass с переменными определяется
> с помощью resolver'а, то на каждый запрос создаётся новый апстрим.
> Это может быть не так e.g. в случае алиасинга с неявным апстримом;
> я бы проверил это в первую очередь. 

Да, в моем случае в переменной DNS адрес, который резолвится с помощью
резолвера и адрес точно резолвится в несколько адресов.
Таким образом получается, что при каждом запросе создается новый upstream с
адресом в который разрезолвилась переменная и пока этот адрес есть в
резолвере, каждый новый запрос будет фейлить?
Кажется крутым решением было бы брать набор адресов из резолвера и из них
уже делать апстрим с дефолтным фоллбэком. Хотя вероятно делать это на каждый
запрос было бы ресурсоемко.

Спасибо большое за ответ!

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


From mdounin на mdounin.ru  Tue Jun  4 15:34:16 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 4 Jun 2019 18:34:16 +0300
Subject: proxy_pass to variable and upstream server temporarily disabled
 variable
In-Reply-To: <5a381e879e59f7991c459655e385d397.NginxMailingListRussian@forum.nginx.org>
References: <681DB322-92CF-4261-AC07-7EF14A00A617@nginx.com>
 <5a381e879e59f7991c459655e385d397.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190604153416.GB1877@mdounin.ru>

Hello!

On Tue, Jun 04, 2019 at 10:40:23AM -0400, kron wrote:

> > В случае если адрес сервера в proxy_pass с переменными определяется
> > с помощью resolver'а, то на каждый запрос создаётся новый апстрим.
> > Это может быть не так e.g. в случае алиасинга с неявным апстримом;
> > я бы проверил это в первую очередь. 
> 
> Да, в моем случае в переменной DNS адрес, который резолвится с помощью
> резолвера и адрес точно резолвится в несколько адресов.
> Таким образом получается, что при каждом запросе создается новый upstream с
> адресом в который разрезолвилась переменная и пока этот адрес есть в
> резолвере, каждый новый запрос будет фейлить?

Не совсем так.  Если у вас один из N возвращаемых из DNS бэкендов 
нерабочий - то при исползовании переменных с вероятностью 1/N 
nginx попытается сначала отправить запрос именно на него, и 
получит ошибку.  После чего пойдёт на другой бэкенд в соответствии 
с proxy_next_upstream.

> Кажется крутым решением было бы брать набор адресов из резолвера и из них
> уже делать апстрим с дефолтным фоллбэком. Хотя вероятно делать это на каждый
> запрос было бы ресурсоемко.

Если хочется, чтобы полученный набор серверов использовался не 
только для одного запроса - это можно сделать, описав блок 
upstream и/или написав в конфиге proxy_pass без переменных.  Так, 
собственно, nginx работает по умолчанию.

Если же хочется, чтобы полученный набор адресов периодечески 
обновлялся - то такая фича есть в платной версии, подробности тут:

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#resolve

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Tue Jun  4 16:02:47 2019
From: nginx-forum на forum.nginx.org (kron)
Date: Tue, 04 Jun 2019 12:02:47 -0400
Subject: upstream_response_time larger than request_time
Message-ID: <bada9ab765a8af1ce4dc08a981b7e09f.NginxMailingListRussian@forum.nginx.org>

Доброго дня.
Наблюдаю странную картину в логах. Логируется две переменных - request_time
и upstream_response_time.
Судя по документации логично предположить, что request_time будет всегда
либо больше, либо равной upstream_response_time, но по факту оказалось, что
upstream_response_time хоть и не значительно, но бывает больше чем
request_time. Хотелось бы понять в каких случаях такое возможно?

Пример таймингов:
request_time upstream_response_time method
5.954 5.956 GET
5.421 5.424 GET
30.576 30.577 GET
2.302 2.304 GET
2.298 2.300 GET
1.923 1.924 GET
1.898 1.900 GET
1.802 1.804 GET
1.774 1.776 GET
1.683 1.684 GET

версия nginx - 1.15.5

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


From nginx-forum на forum.nginx.org  Tue Jun  4 16:11:08 2019
From: nginx-forum на forum.nginx.org (kron)
Date: Tue, 04 Jun 2019 12:11:08 -0400
Subject: proxy_pass to variable and upstream server temporarily disabled
 variable
In-Reply-To: <20190604153416.GB1877@mdounin.ru>
References: <20190604153416.GB1877@mdounin.ru>
Message-ID: <27162ee43abdb3aa9cb273fbfd81a8b2.NginxMailingListRussian@forum.nginx.org>

> Не совсем так. Если у вас один из N возвращаемых из DNS бэкендов
> нерабочий - то при исползовании переменных с вероятностью 1/N
> nginx попытается сначала отправить запрос именно на него, и
> получит ошибку. После чего пойдёт на другой бэкенд в соответствии
> с proxy_next_upstream.

На другой бэкенд имеется ввиду на следующий адрес из списка который
разрезолвил DNS/

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


From mdounin на mdounin.ru  Tue Jun  4 16:49:02 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 4 Jun 2019 19:49:02 +0300
Subject: upstream_response_time larger than request_time
In-Reply-To: <bada9ab765a8af1ce4dc08a981b7e09f.NginxMailingListRussian@forum.nginx.org>
References: <bada9ab765a8af1ce4dc08a981b7e09f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190604164902.GC1877@mdounin.ru>

Hello!

On Tue, Jun 04, 2019 at 12:02:47PM -0400, kron wrote:

> Доброго дня.
> Наблюдаю странную картину в логах. Логируется две переменных - request_time
> и upstream_response_time.
> Судя по документации логично предположить, что request_time будет всегда
> либо больше, либо равной upstream_response_time, но по факту оказалось, что
> upstream_response_time хоть и не значительно, но бывает больше чем
> request_time. Хотелось бы понять в каких случаях такое возможно?
> 
> Пример таймингов:
> request_time upstream_response_time method
> 5.954 5.956 GET
> 5.421 5.424 GET
> 30.576 30.577 GET
> 2.302 2.304 GET
> 2.298 2.300 GET
> 1.923 1.924 GET
> 1.898 1.900 GET
> 1.802 1.804 GET
> 1.774 1.776 GET
> 1.683 1.684 GET
> 
> версия nginx - 1.15.5

Это связано с тем, что сейчас на Линуксе $upstream_response_time 
считается через clock_gettime(CLOCK_MONOTONIC_COARSE), и при 
типичных значениях CONFIG_HZ=250 оно может отставать на время до 4 
миллисекунд.  В то же время время для расчёта $request_time 
используется не монотонное время, а результат gettimeofday(), то 
есть время по настенным часам.  Так что в некоторых случаях 
$upstream_response_time может быть незначительно больше 
$request_time.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Wed Jun  5 00:27:14 2019
From: nginx-forum на forum.nginx.org (gont)
Date: Tue, 04 Jun 2019 20:27:14 -0400
Subject: =?UTF-8?B?0JrQsNC6INC00LXQutC+0LTQuNGA0L7QstCw0YLRjCB1cmwgd2luZG93cy0xMjUx?=
 =?UTF-8?B?Pw==?=
Message-ID: <03202640471363b61cef681fb2c10555.NginxMailingListRussian@forum.nginx.org>

Есть программа для скачивания файлов updater.exe она обращается на сайт к
файлу patchlist.xml
внутри patchlist.xml ссылки на файлы которые на русском языке, файл
patchlist.xml в кодировке windows-1251,
файлы не скачивает потому как их не находит на сервере, если поменять
кодировку patchlist.xml на utf8 то файлы качает,
но их сохраняет с названиями крякозябры (РЁРёСЂРѕРєР), видел хостинг на
котором работает всё нормально файл patchlist.xml у них в windows-1251 и
качаются файлы.
Что бы всё работало надо как то что бы сервер нормально декодировал url в
кодировке windows-1251.

Содержимое patchlist.xml:
<list>
	<archive filename="textures\Lobby_terrain_t.utx" checksum="3356B2BF"
original="88D8A29C" size="2340547"/>
	<archive filename="Дополнительно\Активное окно\system\l2ui.dll"
checksum="8DD5C631" original="48EC41DC" size="3072"/>
	<archive filename="Дополнительно\Анти AGP\system\D3DDrv.dll"
checksum="88C3D3F4" original="C7673732" size="1277972"/>
	<archive filename="Дополнительно\Стандартная анимация хилов и гидро
бласта\system\skillgrp.dat" checksum="05A9549C" original="9B279B4D"
size="162610"/>
</list>

Файл должен оставатся в кодировке windows-1251.
Может кто сталкивался и может подсказать как заставить linux обрабатывать
url в кодировке windows-1251?
Сайт стоит на nginx 1.16.0

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


From nginx-forum на forum.nginx.org  Wed Jun  5 05:16:52 2019
From: nginx-forum на forum.nginx.org (kron)
Date: Wed, 05 Jun 2019 01:16:52 -0400
Subject: upstream_response_time larger than request_time
In-Reply-To: <20190604164902.GC1877@mdounin.ru>
References: <20190604164902.GC1877@mdounin.ru>
Message-ID: <47bf915dae6e57ee18e60bfd5d357c9a.NginxMailingListRussian@forum.nginx.org>

Спасибо большое за ответ!
Теперь все ясно.

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


From nginx-forum на forum.nginx.org  Wed Jun  5 08:12:39 2019
From: nginx-forum на forum.nginx.org (avinchakov)
Date: Wed, 05 Jun 2019 04:12:39 -0400
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSDQsNC/0YHRgtGA0LjQvNCw0LzQuA==?=
Message-ID: <ea06d78b2c99648ccab51a68f1cd7bce.NginxMailingListRussian@forum.nginx.org>

Всем привет, уже долго время пытаюсь найти причину постоянных ошибок "no
live upstreams while connecting to upstream". Флоу такой:
Интернет->"Балансер" с nginx->Сервера с приложением Nginx+FPM в другой
подсети.

Основаная часть конфига "Балансера":
location / {
                proxy_pass           http://ps1;
                proxy_next_upstream  error timeout http_500 http_502;
                include              /etc/nginx/proxy_params;
                proxy_set_header     X-HTTPS $https;
        }

proxy_param:
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-SSL-Protocol $ssl_protocol;

upstreams:
upstream ps1 {
        server server1.local  max_fails=1 fail_timeout=15s; 
        server server2.local  max_fails=1 fail_timeout=15s backup;
}

Конфиг сервера с приложением:
location ~ \.php$ {
  
    fastcgi_pass                 unix:/var/run/php5-fpm.sock;
    fastcgi_index                index.php;
    include                      fastcgi_params;
    fastcgi_param                SCRIPT_FILENAME 
$realpath_root$fastcgi_script_name;
    fastcgi_param                DOCUMENT_ROOT    $realpath_root;
  
    fastcgi_intercept_errors     on;
    fastcgi_ignore_client_abort  off;
    fastcgi_connect_timeout      60;
    fastcgi_send_timeout         180;
    fastcgi_read_timeout         180;
    fastcgi_buffer_size          128k;
    fastcgi_buffers              4 256k;
    fastcgi_busy_buffers_size    256k;
    fastcgi_temp_file_write_size 256k;
  }


Трафика немного, порядка 5rps. Коннектов в среднем держится 30. FPM воркеров
тотал 35 но никогда больше половины не используется. 
Ошибки только на балансере, на nginx самого приложения никаких ошибок нет.
Сетевых проблем тоже не видно, ни на интерфейсах серверов ни на активном
оборудовании.
Подскажите пожалуйста как можно отловить причину ошибки. Спасибо.

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


From andrey на kopeyko.ru  Wed Jun  5 08:52:04 2019
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Wed, 05 Jun 2019 11:52:04 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQtNC10LrQvtC00LjRgNC+0LLQsNGC0YwgdXJsIHdpbmRvd3Mt?=
 =?UTF-8?B?MTI1MT8=?=
In-Reply-To: <03202640471363b61cef681fb2c10555.NginxMailingListRussian@forum.nginx.org>
References: <03202640471363b61cef681fb2c10555.NginxMailingListRussian@forum.nginx.org>
Message-ID: <a21f678d6348071dd87e07f287e5348c@kopeyko.ru>

gont писал 2019-06-05 03:27:
> Есть программа для скачивания файлов updater.exe она обращается на сайт 
> к
> файлу patchlist.xml
> внутри patchlist.xml ссылки на файлы которые на русском языке, файл
> patchlist.xml в кодировке windows-1251,
> файлы не скачивает потому как их не находит на сервере, если поменять
> кодировку patchlist.xml на utf8 то файлы качает,
> но их сохраняет с названиями крякозябры (РЁРёСЂРѕРєР), видел хостинг на
> котором работает всё нормально файл patchlist.xml у них в windows-1251 
> и
> качаются файлы.

Добрый день!

Дабы браузер сохранял файл под нужным вам именем - требуется выдавать 
заголовок "Content-Disposition: ", примерно так

location / {
   root  /path/to/root;
   add_header 'Content-Disposition' 'attachment; 
filename=$filename_utf8';
}

> Что бы всё работало надо как то что бы сервер нормально декодировал url 
> в
> кодировке windows-1251.

"Имя файла в кодировке uft8" -
- вы можете выбирать по пре-геренённой мапе (если файлов небольшое 
количество)
- или перекодировать на лету из имени запрашиваемого файла (используя 
либо встроенные perl, lua, либо получая с бэкенда на любом удобном вам 
языке)


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

From mdounin на mdounin.ru  Wed Jun  5 13:16:17 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 5 Jun 2019 16:16:17 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0LDQv9GB0YLRgNC40LzQsNC80Lg=?=
In-Reply-To: <ea06d78b2c99648ccab51a68f1cd7bce.NginxMailingListRussian@forum.nginx.org>
References: <ea06d78b2c99648ccab51a68f1cd7bce.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190605131617.GE1877@mdounin.ru>

Hello!

On Wed, Jun 05, 2019 at 04:12:39AM -0400, avinchakov wrote:

> Всем привет, уже долго время пытаюсь найти причину постоянных ошибок "no
> live upstreams while connecting to upstream". Флоу такой:
> Интернет->"Балансер" с nginx->Сервера с приложением Nginx+FPM в другой
> подсети.

Причина ошибок "no live upstreams ..." - в том, что все бэкенды 
выключены из-за ранее прозошедших ошибок, в соответствии с 
max_fails / fail_timeout в конфигурации.  Ищите, какие ошибки были 
до этого.

-- 
Maxim Dounin
http://mdounin.ru/

From alnkapa на gmail.com  Fri Jun  7 08:36:31 2019
From: alnkapa на gmail.com (Aln Kapa)
Date: Fri, 7 Jun 2019 11:36:31 +0300
Subject: =?UTF-8?B?0L3QtdC/0L7QvdGP0YLQvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1?=
Message-ID: <CAJqqVEVu8-gwdK5wbz3_n0g_6pm6tvf6B0uZ3fLce5VCns909A@mail.gmail.com>

Добрый день.

Случайно наткнулся вот на это:

185.172.110.221 - - [07/Jun/2019:07:03:52 +0300] "GET
http://185.172.110.221:80/proxy_get.php?ip=62.122.99.46&foo=bar HTTP/1.0"
302 138 "-" "HTTP-Proxy-Tester"

Правильно ли я понимаю, так как 185.172.110.221 не мой IP, соответственно
ответ должен быть 4xx.
Почему 302 вот не разу не понял?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190607/d70f1e20/attachment.html>

From swood на fotofor.biz  Fri Jun  7 10:31:51 2019
From: swood на fotofor.biz (Anton Kiryushkin)
Date: Fri, 7 Jun 2019 12:31:51 +0200
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3QvtC1INC/0L7QstC10LTQtdC90LjQtQ==?=
In-Reply-To: <CAJqqVEVu8-gwdK5wbz3_n0g_6pm6tvf6B0uZ3fLce5VCns909A@mail.gmail.com>
References: <CAJqqVEVu8-gwdK5wbz3_n0g_6pm6tvf6B0uZ3fLce5VCns909A@mail.gmail.com>
Message-ID: <CAM_jxg31MBDtnp+kZMfYhPeTX3hjWDdZoYriH9YhnBUofCHrgQ@mail.gmail.com>

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

Без конфигурационного сервера всем тоже не понятно.

On Fri, 7 Jun 2019 at 10:37, Aln Kapa <alnkapa на gmail.com> wrote:

> Добрый день.
>
> Случайно наткнулся вот на это:
>
> 185.172.110.221 - - [07/Jun/2019:07:03:52 +0300] "GET
> http://185.172.110.221:80/proxy_get.php?ip=62.122.99.46&foo=bar HTTP/1.0"
> 302 138 "-" "HTTP-Proxy-Tester"
>
> Правильно ли я понимаю, так как 185.172.110.221 не мой IP, соответственно
> ответ должен быть 4xx.
> Почему 302 вот не разу не понял?
>
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190607/0fe582b3/attachment.html>

From mdounin на mdounin.ru  Fri Jun  7 11:24:14 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 7 Jun 2019 14:24:14 +0300
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3QvtC1INC/0L7QstC10LTQtdC90LjQtQ==?=
In-Reply-To: <CAJqqVEVu8-gwdK5wbz3_n0g_6pm6tvf6B0uZ3fLce5VCns909A@mail.gmail.com>
References: <CAJqqVEVu8-gwdK5wbz3_n0g_6pm6tvf6B0uZ3fLce5VCns909A@mail.gmail.com>
Message-ID: <20190607112414.GN1877@mdounin.ru>

Hello!

On Fri, Jun 07, 2019 at 11:36:31AM +0300, Aln Kapa wrote:

> Добрый день.
> 
> Случайно наткнулся вот на это:
> 
> 185.172.110.221 - - [07/Jun/2019:07:03:52 +0300] "GET
> http://185.172.110.221:80/proxy_get.php?ip=62.122.99.46&foo=bar HTTP/1.0"
> 302 138 "-" "HTTP-Proxy-Tester"
> 
> Правильно ли я понимаю, так как 185.172.110.221 не мой IP, соответственно
> ответ должен быть 4xx.
> Почему 302 вот не разу не понял?

Неправильно понимаете.  Всё зависит от конфигруации.  При 
обращении к имени, не описанному в конфигурации - запрос 
обрабатывается в сервере по умолчанию, и ответ будет такой, как 
гласит конфигурация сервера по умолчанию.

Подробнее обо всём этот можно почитать тут:

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

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Sun Jun  9 11:00:45 2019
From: nginx-forum на forum.nginx.org (ocadihoh)
Date: Sun, 09 Jun 2019 07:00:45 -0400
Subject: =?UTF-8?B?d2hpdGUgJiBiYWQgYm90cyDQn9C+0LzQvtCz0LjRgtC1?=
Message-ID: <c8a20607cb2f7c1637ec6a4f83660cee.NginxMailingListRussian@forum.nginx.org>

Здравствуйте помогите пожалуйста.
есть список плохих ботов
if ($http_user_agent ~*
(360Spider|80legs.com|Abonti|AcoonBot|Acunetix||ZyBorg|google) ) {
				return 410;
			}
там присутствует google - но в таком варианте банит всех ботов гугла,!
Нужно забанить всех кроме мобильного бота

Обычные user agent
Подскажите пожалуйста как пропускать только мобильного бота Google остальных
банить
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible;
Googlebot/2.1; +http://www.google.com/bot.html) Safari/537.36
Googlebot/2.1 (+http://www.google.com/bot.html)

mobile
Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46
(KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1 (compatible;
AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)

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

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


From nginx-forum на forum.nginx.org  Mon Jun 10 03:24:19 2019
From: nginx-forum на forum.nginx.org (Raven_kg)
Date: Sun, 09 Jun 2019 23:24:19 -0400
Subject: =?UTF-8?B?UmU6IHdoaXRlICYgYmFkIGJvdHMg0J/QvtC80L7Qs9C40YLQtQ==?=
In-Reply-To: <c8a20607cb2f7c1637ec6a4f83660cee.NginxMailingListRussian@forum.nginx.org>
References: <c8a20607cb2f7c1637ec6a4f83660cee.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4ead5ca73dbf62740ae499d94f852303.NginxMailingListRussian@forum.nginx.org>

map $http_user_agent $bad_bot {
    default 0;
    ~*360Spider 1;
    ~*AdsBot-Google-Mobile 0;
    ~*google   1;
    ...
}

и в нужном  локейшене:

if ($bad_bot) {
    return 410;
}

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


From alnkapa на gmail.com  Mon Jun 10 06:16:40 2019
From: alnkapa на gmail.com (Aln Kapa)
Date: Mon, 10 Jun 2019 09:16:40 +0300
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3QvtC1INC/0L7QstC10LTQtdC90LjQtQ==?=
In-Reply-To: <20190607112414.GN1877@mdounin.ru>
References: <CAJqqVEVu8-gwdK5wbz3_n0g_6pm6tvf6B0uZ3fLce5VCns909A@mail.gmail.com>
 <20190607112414.GN1877@mdounin.ru>
Message-ID: <CAJqqVEVba8TLuPt5BVHaoT0SUJ=dbavRG_TYNQpQrR2+Kt9tfA@mail.gmail.com>

server {
    server_name xx.xxxx.xxxx;
    listen 443 http2;

    .............................

    location / {
        proxy_pass http://127.0.0.1:10080;
        ..................................................
    }
}

server {
    listen   80;
    server_name xx.xxxx.xxxx;
    return 302 https://xx.xxxx.xxxx/$request_uri;
}
Да у меня в конфигурации есть редирект, но разве "listen 80" означает любой
в интернете IP адрес, по идеи тут должно быть любой мой?
и потом указано же "server_name xx.xxxx.xxxx;" как с этим быть?




пт, 7 июн. 2019 г. в 14:24, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Fri, Jun 07, 2019 at 11:36:31AM +0300, Aln Kapa wrote:
>
> > Добрый день.
> >
> > Случайно наткнулся вот на это:
> >
> > 185.172.110.221 - - [07/Jun/2019:07:03:52 +0300] "GET
> > http://185.172.110.221:80/proxy_get.php?ip=62.122.99.46&foo=bar
> HTTP/1.0"
> > 302 138 "-" "HTTP-Proxy-Tester"
> >
> > Правильно ли я понимаю, так как 185.172.110.221 не мой IP, соответственно
> > ответ должен быть 4xx.
> > Почему 302 вот не разу не понял?
>
> Неправильно понимаете.  Всё зависит от конфигруации.  При
> обращении к имени, не описанному в конфигурации - запрос
> обрабатывается в сервере по умолчанию, и ответ будет такой, как
> гласит конфигурация сервера по умолчанию.
>
> Подробнее обо всём этот можно почитать тут:
>
> http://nginx.org/ru/docs/http/request_processing.html
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190610/81894e6c/attachment.html>

From nginx-forum на forum.nginx.org  Mon Jun 10 06:37:41 2019
From: nginx-forum на forum.nginx.org (ngnx8810773a83)
Date: Mon, 10 Jun 2019 02:37:41 -0400
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3QvtC1INC/0L7QstC10LTQtdC90LjQtQ==?=
In-Reply-To: <CAJqqVEVba8TLuPt5BVHaoT0SUJ=dbavRG_TYNQpQrR2+Kt9tfA@mail.gmail.com>
References: <CAJqqVEVba8TLuPt5BVHaoT0SUJ=dbavRG_TYNQpQrR2+Kt9tfA@mail.gmail.com>
Message-ID: <4dedf5edbc410ef60c5fbbfab6670265.NginxMailingListRussian@forum.nginx.org>

А где Вы в  Вашем логе нашли что  ктото соеденился не на Ваш IP ? Если GET
http://x.x.x.x/ то listen тут не причем. Это всего лишь текст переданный
удаленной стороной на Ваш сервер, с чего бы он дорлжен совпадать с вашим IP
- не ясно. По счастливой случайности, если не был передан заголовох хост, то
оно будет заполнено из этого x.x.x.x. Ну ищет ктото открытые прокси, не
проверящиеи поле Host и джелающие проксиования proxy_pass
http://$host$request_uri;

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


From mdounin на mdounin.ru  Mon Jun 10 11:53:18 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 10 Jun 2019 14:53:18 +0300
Subject: =?UTF-8?B?UmU6IHdoaXRlICYgYmFkIGJvdHMg0J/QvtC80L7Qs9C40YLQtQ==?=
In-Reply-To: <c8a20607cb2f7c1637ec6a4f83660cee.NginxMailingListRussian@forum.nginx.org>
References: <c8a20607cb2f7c1637ec6a4f83660cee.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190610115318.GQ1877@mdounin.ru>

Hello!

On Sun, Jun 09, 2019 at 07:00:45AM -0400, ocadihoh wrote:

> Здравствуйте помогите пожалуйста.
> есть список плохих ботов
> if ($http_user_agent ~*
> (360Spider|80legs.com|Abonti|AcoonBot|Acunetix||ZyBorg|google) ) {
> 				return 410;
> 			}
> там присутствует google - но в таком варианте банит всех ботов гугла,!
> Нужно забанить всех кроме мобильного бота
> 
> Обычные user agent
> Подскажите пожалуйста как пропускать только мобильного бота Google остальных
> банить
> Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
> Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible;
> Googlebot/2.1; +http://www.google.com/bot.html) Safari/537.36
> Googlebot/2.1 (+http://www.google.com/bot.html)
> 
> mobile
> Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46
> (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1 (compatible;
> AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)
> 
> 4 день голову ломаю.
> Зарание огромное спасибо.

Читайте про negative look-ahead assertions, что-то вроде 
"google(?!.*mobile)" должно сработать.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Mon Jun 10 12:34:42 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 10 Jun 2019 15:34:42 +0300
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3QvtC1INC/0L7QstC10LTQtdC90LjQtQ==?=
In-Reply-To: <CAJqqVEVba8TLuPt5BVHaoT0SUJ=dbavRG_TYNQpQrR2+Kt9tfA@mail.gmail.com>
References: <CAJqqVEVu8-gwdK5wbz3_n0g_6pm6tvf6B0uZ3fLce5VCns909A@mail.gmail.com>
 <20190607112414.GN1877@mdounin.ru>
 <CAJqqVEVba8TLuPt5BVHaoT0SUJ=dbavRG_TYNQpQrR2+Kt9tfA@mail.gmail.com>
Message-ID: <20190610123442.GS1877@mdounin.ru>

Hello!

On Mon, Jun 10, 2019 at 09:16:40AM +0300, Aln Kapa wrote:

> server {
>     server_name xx.xxxx.xxxx;
>     listen 443 http2;
> 
>     .............................
> 
>     location / {
>         proxy_pass http://127.0.0.1:10080;
>         ..................................................
>     }
> }
> 
> server {
>     listen   80;
>     server_name xx.xxxx.xxxx;
>     return 302 https://xx.xxxx.xxxx/$request_uri;
> }
> Да у меня в конфигурации есть редирект, но разве "listen 80" означает любой
> в интернете IP адрес, по идеи тут должно быть любой мой?
> и потом указано же "server_name xx.xxxx.xxxx;" как с этим быть?

"listen 80" означает - отвечать на любые запросы, поступающие по 
IPv4 на порт 80.  Что при этом написано в запросе - не важно, 
важно - куда было установлено TCP-соединение.  А оно, очевидно, 
было на 80-й порт.

Что до "server_name", то для выбора блока server это важно тогда и 
только тогда, когда в конфигурации есть другие блоки server, 
использующие тот же listen-сокет.  В данном случае блок server 
для 80-го порта - единственный, он же сервер по умолчанию, и 
запрос будет обработан именно в этом блоке server.

Как я уже писал, подробнее обо всём этом можно прочитать тут:

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

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Wed Jun 12 22:44:11 2019
From: nginx-forum на forum.nginx.org (darksmoke)
Date: Wed, 12 Jun 2019 18:44:11 -0400
Subject: =?UTF-8?B?0J7RgtC00LDRgtGMIEpTT04g0LIg0LfQsNCy0LjRgdC40LzQvtGB0YLQuCDQvtGC?=
 =?UTF-8?B?INGC0LXQu9CwIFBPU1QnYQ==?=
Message-ID: <e25c40e568b9b48e18585857e8dfaeb3.NginxMailingListRussian@forum.nginx.org>

Добрый день
Подскажите, может кто-то знает, есть один урл и он отдает разный JSON в
зависимости от того какая переменная в него пришла POST'ом.

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

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


From nginx на mva.name  Thu Jun 13 13:39:08 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 13 Jun 2019 16:39:08 +0300
Subject: =?UTF-8?B?W1VuaXRdIHBocC3QvNC+0LTRg9C70YwsIFVidW50dSfRiNC90YvQtSDQv9Cw0Lo=?=
 =?UTF-8?B?0LXRgtGL?=
Message-ID: <10837153.IPHkPqdKna@note>

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

Подскажите, пожалуйста, никто ли не сталкивался с тем, что на Ubuntu (xenial, 
bionic) при использовании php-модуля с php7.1 при попытке загрузки приложения 
оно сегфолтится (юнит сообщает про то, что оно выходит с сигналом 11, что на 
сколько я помню, является сегфолтом).
Контекст выяснить пока не удалось, к сожалению.

Плюс, на одном из bionic-инстансов "чинится" переустановкой `update-
alternatives --set php/libphp7` заново на 7.1, а вот на xenial не помогло даже 
вынести все версии кроме 7.1. Сейчас, вот, пробую проапгрейдить до bionic, 
посмотрю как там себя поведёт...

К сожалению, подебажить нормально не получается: debug-версия юнита ничего 
связанного с сегфолтом модуля (дебаг символы от него тоже стоят) не пишет ни в 
лог, ни на stdout. А если запустить юнит под gdb, то сегфолт модуля не 
отлавливается (впрочем, я не такой уж и гуру gdb, если честно).


P.S. В то же время на Gentoo, где под каждую версию php собирается отдельный 
модуль, именуемый соответствующе, а нужный путь до libphp7 прописывается через 
RUNPATH, такой проблемы с сегфолтами не наблюдается...

From vbart на nginx.com  Thu Jun 13 15:01:12 2019
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 13 Jun 2019 18:01:12 +0300
Subject: =?UTF-8?B?UmU6IFtVbml0XSBwaHAt0LzQvtC00YPQu9GMLCBVYnVudHUn0YjQvdGL0LUg0L8=?=
 =?UTF-8?B?0LDQutC10YLRiw==?=
In-Reply-To: <10837153.IPHkPqdKna@note>
References: <10837153.IPHkPqdKna@note>
Message-ID: <2553148.WisjVBUdru@vbart-workstation>

On Thursday 13 June 2019 16:39:08 Vadim A. Misbakh-Soloviov wrote:
> Здравствуйте!
> 
> Подскажите, пожалуйста, никто ли не сталкивался с тем, что на Ubuntu (xenial, 
> bionic) при использовании php-модуля с php7.1 при попытке загрузки приложения 
> оно сегфолтится (юнит сообщает про то, что оно выходит с сигналом 11, что на 
> сколько я помню, является сегфолтом).
> Контекст выяснить пока не удалось, к сожалению.
[..]

Любого приложения?  Даже пустого php-файла?  Это из чьих-то пакетов
или сборка из исходников?


> 
> Плюс, на одном из bionic-инстансов "чинится" переустановкой `update-
> alternatives --set php/libphp7` заново на 7.1, а вот на xenial не помогло даже 
> вынести все версии кроме 7.1. Сейчас, вот, пробую проапгрейдить до bionic, 
> посмотрю как там себя поведёт...
> 
> К сожалению, подебажить нормально не получается: debug-версия юнита ничего 
> связанного с сегфолтом модуля (дебаг символы от него тоже стоят) не пишет ни в 
> лог, ни на stdout. А если запустить юнит под gdb, то сегфолт модуля не 
> отлавливается (впрочем, я не такой уж и гуру gdb, если честно).
> 
[..]

https://sourceware.org/gdb/onlinedocs/gdb/Forks.html

--
Валентин Бартенев

From nginx на mva.name  Thu Jun 13 15:56:23 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 13 Jun 2019 18:56:23 +0300
Subject: =?UTF-8?B?UmU6IFtVbml0XSBwaHAt0LzQvtC00YPQu9GMLCBVYnVudHUn0YjQvdGL0LUg0L8=?=
 =?UTF-8?B?0LDQutC10YLRiw==?=
In-Reply-To: <2553148.WisjVBUdru@vbart-workstation>
References: <10837153.IPHkPqdKna@note> <2553148.WisjVBUdru@vbart-workstation>
Message-ID: <1641654.N7yGrjhHuc@note>

> Любого приложения?  Даже пустого php-файла? 

Как ни странно, но нет, c phpinfo-примером, идущим в коробке, не падает.
только с конфигом, натравленным на Symfony3, причём, не важно, укажу ли я ему 
script: app.php, или index: app.php

(да и вообще, странно, если написанный под фреймворком PHP-код не крошиться 
под FPM и крошится под embed SAPI)

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

> Это из чьих-то пакетов или сборка из исходников?

Из http://packages.nginx.org/unit/ubuntu/
// кстати, на bionic сейчас ведёт себя так же, обновление не помогло.


В общем, сейчас буду пробовать дебажить...

From nginx на mva.name  Thu Jun 13 16:08:50 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 13 Jun 2019 19:08:50 +0300
Subject: =?UTF-8?B?UmU6IFtVbml0XSBwaHAt0LzQvtC00YPQu9GMLCBVYnVudHUn0YjQvdGL0LUg0L8=?=
 =?UTF-8?B?0LDQutC10YLRiw==?=
In-Reply-To: <1641654.N7yGrjhHuc@note>
References: <10837153.IPHkPqdKna@note> <2553148.WisjVBUdru@vbart-workstation>
 <1641654.N7yGrjhHuc@note>
Message-ID: <3060502.zn2T4Cygzk@note>

До gdb пока не добрался, но забавное наблюдение:
Если я убираю из конфига секции (внутри "options"):

```
        "admin": {
          "memory_limit": "256M",
          "variables_order": "EGPCS",
          "expose_php": "0"
        },
        "user": {
          "display_errors": "0"
        }
```

То сегфолтиться перестаёт.

А с ними - сегфолтится (с любым из блоков)...

From nginx-forum на forum.nginx.org  Fri Jun 14 06:57:25 2019
From: nginx-forum на forum.nginx.org (Krelion)
Date: Fri, 14 Jun 2019 02:57:25 -0400
Subject: =?UTF-8?B?0JvQuNC80LjRgiDQv9C+0LTQutC70Y7Rh9C10L3QuNC5INCyIFdpbmRvd3MgMTAy?=
 =?UTF-8?B?NCB3b3JrZXIgY29ubmVjdGlvbnMgYXJlIG5vdCBlbm91Z2g=?=
Message-ID: <271bac2235fa6247d06776893ea45328.NginxMailingListRussian@forum.nginx.org>

Добрый день!

Nginx 1.15.9 для Windows

конфиг,

worker_processes  1;

events {
    worker_connections  8192;
}

в логах:

2019/06/07 14:17:20 [alert] 2424#2720: 1024 worker_connections are not
enough

Как поднять количество соединений больше 1024 в версии под Windows ?
В моем случае невозможно использовать Linux версию по ряду причин.

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


From nginx-forum на forum.nginx.org  Fri Jun 14 07:24:47 2019
From: nginx-forum на forum.nginx.org (Krelion)
Date: Fri, 14 Jun 2019 03:24:47 -0400
Subject: =?UTF-8?B?UmU6INCb0LjQvNC40YIg0L/QvtC00LrQu9GO0YfQtdC90LjQuSDQsiBXaW5kb3dz?=
 =?UTF-8?B?IDEwMjQgd29ya2VyIGNvbm5lY3Rpb25zIGFyZSBub3QgZW5vdWdo?=
In-Reply-To: <271bac2235fa6247d06776893ea45328.NginxMailingListRussian@forum.nginx.org>
References: <271bac2235fa6247d06776893ea45328.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e2adb1681ee2ab6f3181d6e78916c4ba.NginxMailingListRussian@forum.nginx.org>

*309644 maximum number of descriptors supported by select() is 1024 while
connecting to upstream

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


From chipitsine на gmail.com  Fri Jun 14 07:29:35 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 14 Jun 2019 12:29:35 +0500
Subject: =?UTF-8?B?UmU6INCb0LjQvNC40YIg0L/QvtC00LrQu9GO0YfQtdC90LjQuSDQsiBXaW5kb3dz?=
 =?UTF-8?B?IDEwMjQgd29ya2VyIGNvbm5lY3Rpb25zIGFyZSBub3QgZW5vdWdo?=
In-Reply-To: <e2adb1681ee2ab6f3181d6e78916c4ba.NginxMailingListRussian@forum.nginx.org>
References: <271bac2235fa6247d06776893ea45328.NginxMailingListRussian@forum.nginx.org>
 <e2adb1681ee2ab6f3181d6e78916c4ba.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQF0rtqC_qfkC5P=+J0ffpogfqXYje3HbeBBnQn=oF+Xcg@mail.gmail.com>

"while connecting to upstream" - подскажите, у вас кипэлайв до бекенда
используется ?
какие у вас нагрузки ?

пт, 14 июн. 2019 г. в 12:24, Krelion <nginx-forum на forum.nginx.org>:

> *309644 maximum number of descriptors supported by select() is 1024 while
> connecting to upstream
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,284527,284528#msg-284528
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190614/80be0ac1/attachment.html>

From postmaster на softsearch.ru  Fri Jun 14 08:18:40 2019
From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=)
Date: Fri, 14 Jun 2019 11:18:40 +0300
Subject: =?UTF-8?B?UmU6INCe0YLQtNCw0YLRjCBKU09OINCyINC30LDQstC40YHQuNC80L7RgdGC0Lgg?=
 =?UTF-8?B?0L7RgiDRgtC10LvQsCBQT1NUJ2E=?=
In-Reply-To: <e25c40e568b9b48e18585857e8dfaeb3.NginxMailingListRussian@forum.nginx.org>
References: <e25c40e568b9b48e18585857e8dfaeb3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <25777320.20190614111840@softsearch.ru>

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

> Подскажите, может кто-то знает, есть один урл и он отдает разный JSON в
> зависимости от того какая переменная в него пришла POST'ом.

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

С помощью map это возможно http://nginx.org/ru/docs/http/ngx_http_map_module.html

--
С уважением,
 Михаил                          mailto:postmaster на softsearch.ru


From nginx на mva.name  Fri Jun 14 11:45:25 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 14 Jun 2019 14:45:25 +0300
Subject: =?UTF-8?B?UmU6IFtVbml0XSBwaHAt0LzQvtC00YPQu9GMLCBVYnVudHUn0YjQvdGL0LUg0L8=?=
 =?UTF-8?B?0LDQutC10YLRiw==?=
In-Reply-To: <2553148.WisjVBUdru@vbart-workstation>
References: <10837153.IPHkPqdKna@note> <2553148.WisjVBUdru@vbart-workstation>
Message-ID: <2604328.ZhuLY4d4Ee@note>

Что-то я хоть тресни, но не могу из gdb попасть в процесс php-модуля, чтобы 
отловить его: либо если я включаю и follow=child и выключаю detach-on-fork, то 
ухожу не в те форки, что нужно (роутер, контроллер), а знаний как попасть в 
нужный - не хватает :'(.




Тут, кстати, один участник рассылки в обход неё, напрямую отправил письмо о 
том, что он сталкивался с таким же когда модуль был собран не под ту версию 
php.

Технически-то, так оно и есть: debug-модуль php у юнита собран под 7.0, а 
"продакшн" под 7.2
А использую я 7.1...

Но что-то на убунте-то как-то не хочется пересобирать вручную пакет с модулем 
php на каждом сервере, куда планируется воткнуть Юнит.

Может, тогда имеет смысл вам, как апстриму сделать пакеты "unit-php-{5.6,7-
{0,1,2,3}}?

From vbart на nginx.com  Fri Jun 14 12:32:45 2019
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 14 Jun 2019 15:32:45 +0300
Subject: =?UTF-8?B?UmU6IFtVbml0XSBwaHAt0LzQvtC00YPQu9GMLCBVYnVudHUn0YjQvdGL0LUg0L8=?=
 =?UTF-8?B?0LDQutC10YLRiw==?=
In-Reply-To: <2604328.ZhuLY4d4Ee@note>
References: <10837153.IPHkPqdKna@note> <2553148.WisjVBUdru@vbart-workstation>
 <2604328.ZhuLY4d4Ee@note>
Message-ID: <5174459.NWCDBqGPqM@vbart-laptop>

On Friday, 14 June 2019 14:45:25 MSK Vadim A. Misbakh-Soloviov wrote:
> Что-то я хоть тресни, но не могу из gdb попасть в процесс php-модуля, чтобы 
> отловить его: либо если я включаю и follow=child и выключаю detach-on-fork, то 
> ухожу не в те форки, что нужно (роутер, контроллер), а знаний как попасть в 
> нужный - не хватает :'(.
> 
> 
> 
> 
> Тут, кстати, один участник рассылки в обход неё, напрямую отправил письмо о 
> том, что он сталкивался с таким же когда модуль был собран не под ту версию 
> php.
> 
> Технически-то, так оно и есть: debug-модуль php у юнита собран под 7.0, а 
> "продакшн" под 7.2
> А использую я 7.1...
[..]

Так работать конечно не будет.
У libphp нет совместимости по ABI между 7.x версиями.


> 
> Но что-то на убунте-то как-то не хочется пересобирать вручную пакет с модулем 
> php на каждом сервере, куда планируется воткнуть Юнит.
> 
> Может, тогда имеет смысл вам, как апстриму сделать пакеты "unit-php-{5.6,7-
> {0,1,2,3}}?
[..]

Мы обычно собираем с тем, что есть в дистрибутиве.  Иначе это поддерживать
невозможно.  Вопрос в том, откуда возникло расхождение в 7.x версиях.

И откуда вообще взялся php 7.1 в убунтах?
Я что-то его не вижу в https://packages.ubuntu.com/ - ни в xenial, ни в bionic.

--
Валентин Бартенев

From chipitsine на gmail.com  Fri Jun 14 17:12:25 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 14 Jun 2019 22:12:25 +0500
Subject: =?UTF-8?B?0L7QsdGA0LDQsdC+0YLQutCwIHNldF9yZWFsX2lwX2Zyb20g0LTQu9GPIDQwMC0=?=
 =?UTF-8?B?0YUg0YHRgtCw0YLRg9GB0L7Qsg==?=
Message-ID: <CAFHpkQFJ+08D_o0_cohkiAsA0+rCo2og6G21Y9bZy7ddfCph7A@mail.gmail.com>

привет!

стенд:

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-х ? это такая задумка ? выглядит как баг.

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

From nginx на mva.name  Fri Jun 14 20:40:31 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 14 Jun 2019 23:40:31 +0300
Subject: =?UTF-8?B?UmU6IFtVbml0XSBwaHAt0LzQvtC00YPQu9GMLCBVYnVudHUn0YjQvdGL0LUg0L8=?=
 =?UTF-8?B?0LDQutC10YLRiw==?=
In-Reply-To: <5174459.NWCDBqGPqM@vbart-laptop>
References: <10837153.IPHkPqdKna@note> <2604328.ZhuLY4d4Ee@note>
 <5174459.NWCDBqGPqM@vbart-laptop>
Message-ID: <2251873.OXWCsJBFv8@tp>

Взяли из PPA http://ppa.launchpad.net/ondrej/php/ubuntu (как и все в 
интернетах, кому нужны отличные от апстримовых версии).
Ибо программисты пишут под 7.1 и пока не готовы к апгрейду...

К слову, на соседней-то машине, которая тоже bionic, юнит с 7.1 вполне себе 
работает...
Правда, там не lxc-контейнер и ядро поновее...

Да и на соседнем проекте, кстати, используют докерный образ nginx/unit:1.8.0-
php7.0 и доставляют в него в Dockerfile'е php7.2 и всё работает как часы...
Разве что берут они его там с https://packages.sury.org/php/ ибо контейнер 
дебиановый.

В общем, похоже, единственным выходом будет пересобирать юнитомодуль и класть 
нужные модули в свой PPA... :(

Хотя от понимания почему там работает - я бы не отказался :)

Пока склонен считать, что, как и сказал товарищ, ответивший мимо рассылки,

> Причина была в том, что использовались php плагины, собранные другой версией 
php или с другой  конфигурацией сборки php. Вам надо будет попробовать 
отключить плагины, или пересобрать их с текущей версией php.

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

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







В письме от пятница, 14 июня 2019 г. 15:32:45 MSK пользователь Валентин 
Бартенев написал:
> On Friday, 14 June 2019 14:45:25 MSK Vadim A. Misbakh-Soloviov wrote:
> > Что-то я хоть тресни, но не могу из gdb попасть в процесс php-модуля,
> > чтобы
> > отловить его: либо если я включаю и follow=child и выключаю
> > detach-on-fork, то ухожу не в те форки, что нужно (роутер, контроллер), а
> > знаний как попасть в нужный - не хватает :'(.
> > 
> > 
> > 
> > 
> > Тут, кстати, один участник рассылки в обход неё, напрямую отправил письмо
> > о
> > том, что он сталкивался с таким же когда модуль был собран не под ту
> > версию
> > php.
> > 
> > Технически-то, так оно и есть: debug-модуль php у юнита собран под 7.0, а
> > "продакшн" под 7.2
> > А использую я 7.1...
> 
> [..]
> 
> Так работать конечно не будет.
> У libphp нет совместимости по ABI между 7.x версиями.
> 
> > Но что-то на убунте-то как-то не хочется пересобирать вручную пакет с
> > модулем php на каждом сервере, куда планируется воткнуть Юнит.
> > 
> > Может, тогда имеет смысл вам, как апстриму сделать пакеты
> > "unit-php-{5.6,7-
> > {0,1,2,3}}?
> 
> [..]
> 
> Мы обычно собираем с тем, что есть в дистрибутиве.  Иначе это поддерживать
> невозможно.  Вопрос в том, откуда возникло расхождение в 7.x версиях.
> 
> И откуда вообще взялся php 7.1 в убунтах?
> Я что-то его не вижу в https://packages.ubuntu.com/ - ни в xenial, ни в
> bionic.
> 
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From vbart на nginx.com  Fri Jun 14 21:28:55 2019
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Sat, 15 Jun 2019 00:28:55 +0300
Subject: =?UTF-8?B?UmU6IFtVbml0XSBwaHAt0LzQvtC00YPQu9GMLCBVYnVudHUn0YjQvdGL0LUg0L8=?=
 =?UTF-8?B?0LDQutC10YLRiw==?=
In-Reply-To: <2251873.OXWCsJBFv8@tp>
References: <10837153.IPHkPqdKna@note> <5174459.NWCDBqGPqM@vbart-laptop>
 <2251873.OXWCsJBFv8@tp>
Message-ID: <2375243.nHdhOxtINi@vbart-laptop>

On Friday, 14 June 2019 23:40:31 MSK Vadim A. Misbakh-Soloviov wrote:
[..]
> Хотя от понимания почему там работает - я бы не отказался :)
[..]

Там бинарная совместимость зависит в том числе от параметров сборки так,
что ABI между двумя сборками libphp может разъехаться даже при совпадении
версии PHP.  Поэтому модуль должен быть собран именно с той сборкой php,
с которой он используется, иначе могут быть вот такие спецэффекты.

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

--
Валентин Бартенев

From swood на fotofor.biz  Sat Jun 15 21:31:15 2019
From: swood на fotofor.biz (Anton Kiryushkin)
Date: Sat, 15 Jun 2019 22:31:15 +0100
Subject: =?UTF-8?B?dW5pdCDQuCDQtdCz0L4g0LvQvtCz?=
Message-ID: <CAM_jxg2hPLw8Dfg7q454FtTgQihYpbn+aTkPUh-1U0faPrSdPg@mail.gmail.com>

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

Подскажите, пожалуйста, как правильно читать лог 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)
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?

-- 
Best regards,
Anton Kiryushkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190615/f7886224/attachment.html>

From vbart на nginx.com  Sun Jun 16 03:30:07 2019
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Sun, 16 Jun 2019 06:30:07 +0300
Subject: =?UTF-8?B?UmU6IHVuaXQg0Lgg0LXQs9C+INC70L7Qsw==?=
In-Reply-To: <CAM_jxg2hPLw8Dfg7q454FtTgQihYpbn+aTkPUh-1U0faPrSdPg@mail.gmail.com>
References: <CAM_jxg2hPLw8Dfg7q454FtTgQihYpbn+aTkPUh-1U0faPrSdPg@mail.gmail.com>
Message-ID: <2616263.FslVnxXefZ@vbart-laptop>

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?
> 

Можно.

--
Валентин Бартенев

From nginx-forum на forum.nginx.org  Sun Jun 16 12:53:25 2019
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Sun, 16 Jun 2019 08:53:25 -0400
Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?=
In-Reply-To: <2632802.ZtBez7UN1Q@vbart-workstation>
References: <2632802.ZtBez7UN1Q@vbart-workstation>
Message-ID: <986eb9367ecfe675b88ce1fec4884533.NginxMailingListRussian@forum.nginx.org>

> Тем временем, мы продолжаем трудиться над поддержкой WebSocket для
> модулей
> Node.js и Java.  Все почти готово; шансы на то, что это войдет в
> следующий
> выпуск - очень велики.

Возможно уже есть документация и открытое бета тестирования для Node.js?

> Напоминаю, что мы непрерывно находимся в поиске талантливых
> разработчиков,
> желающих присоединиться к нашей команде.  Вакансии в Москве и других
> локациях

Мы уже давно для WebSocket, используем Nginx модуль nchan, его разрабатывает
один парень `Leo`
https://github.com/slact
Возможно в составе вашей команды, он бы сделал еще больше.

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


From mdounin на mdounin.ru  Mon Jun 17 12:59:30 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 17 Jun 2019 15:59:30 +0300
Subject: =?UTF-8?B?UmU6INCb0LjQvNC40YIg0L/QvtC00LrQu9GO0YfQtdC90LjQuSDQsiBXaW5kb3dz?=
 =?UTF-8?B?IDEwMjQgd29ya2VyIGNvbm5lY3Rpb25zIGFyZSBub3QgZW5vdWdo?=
In-Reply-To: <271bac2235fa6247d06776893ea45328.NginxMailingListRussian@forum.nginx.org>
References: <271bac2235fa6247d06776893ea45328.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190617125930.GA1877@mdounin.ru>

Hello!

On Fri, Jun 14, 2019 at 02:57:25AM -0400, Krelion wrote:

> Добрый день!
> 
> Nginx 1.15.9 для Windows
> 
> конфиг,
> 
> worker_processes  1;
> 
> events {
>     worker_connections  8192;
> }
> 
> в логах:
> 
> 2019/06/07 14:17:20 [alert] 2424#2720: 1024 worker_connections are not
> enough
> 
> Как поднять количество соединений больше 1024 в версии под Windows ?
> В моем случае невозможно использовать Linux версию по ряду причин.

Если вам нужно больше 1024 соединений в Windows-версии, то вы, 
вероятно, используете nginx для Windows неправильно - не надо на 
этом гонять production, от этого может быть больно.  Впрочем, 
начиная с nginx 1.15.9 при условии использования Windows Vista и 
новее - это можно сделать, сказав к конфиге "use poll;" в секции 
events.

При этом, правда, отвалится детектирование ошибок на этапе 
установления соединения к бэкендам, так как правильную эмуляцию 
poll() в MS не осилили.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Mon Jun 17 14:03:10 2019
From: nginx-forum на forum.nginx.org (grey)
Date: Mon, 17 Jun 2019 10:03:10 -0400
Subject: =?UTF-8?B?0KXQvtGC0LvQuNC90Log0YDQsNCx0L7RgtCw0LXRgiDQutCw0Lot0YLQviDQvdC1?=
 =?UTF-8?B?INGC0LDQug==?=
Message-ID: <f612211139c7ec186c48f426d5dcd274.NginxMailingListRussian@forum.nginx.org>

Добрый день.


Сам конфиг, блокирующий картинки хотлинка с сайтов из "черного" списка:

	map $http_referer $bad_referer {
		hostnames;

		default				0;

		"~site.ru"		1;
		"~test.ru"		1;
}

	location ~* ^/secret-files/
	{
		internal;

		if ($bad_referer)
		{
			rewrite ^ /images/direct-url.gif last;
		}

		root   /inetpub/wwwroot/qwerty.ru;
	}


Пока запрашиваемая картинка на моем сервере существует, правило отрабатывает
верно и пользователи видят заглушку direct-url.gif, но если изображение на
моем сайте удалить, то они видят сообщение, которое отдает скрипт:

<?php
...
	header ("X-Accel-Redirect: /image-not-found.gif");
?>


Не понимаю, почему дело доходит до скрипта, если nginx видя хотлинк сразу
должен отдать заглушку.

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


From mdounin на mdounin.ru  Mon Jun 17 14:14:20 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 17 Jun 2019 17:14:20 +0300
Subject: =?UTF-8?B?UmU6INCl0L7RgtC70LjQvdC6INGA0LDQsdC+0YLQsNC10YIg0LrQsNC6LdGC0L4g?=
 =?UTF-8?B?0L3QtSDRgtCw0Lo=?=
In-Reply-To: <f612211139c7ec186c48f426d5dcd274.NginxMailingListRussian@forum.nginx.org>
References: <f612211139c7ec186c48f426d5dcd274.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190617141420.GD1877@mdounin.ru>

Hello!

On Mon, Jun 17, 2019 at 10:03:10AM -0400, grey wrote:

> Добрый день.
> 
> 
> Сам конфиг, блокирующий картинки хотлинка с сайтов из "черного" списка:
> 
> 	map $http_referer $bad_referer {
> 		hostnames;
> 
> 		default				0;
> 
> 		"~site.ru"		1;
> 		"~test.ru"		1;
> }
> 
> 	location ~* ^/secret-files/
> 	{
> 		internal;
> 
> 		if ($bad_referer)
> 		{
> 			rewrite ^ /images/direct-url.gif last;
> 		}
> 
> 		root   /inetpub/wwwroot/qwerty.ru;
> 	}
> 
> 
> Пока запрашиваемая картинка на моем сервере существует, правило отрабатывает
> верно и пользователи видят заглушку direct-url.gif, но если изображение на
> моем сайте удалить, то они видят сообщение, которое отдает скрипт:
> 
> <?php
> ...
> 	header ("X-Accel-Redirect: /image-not-found.gif");
> ?>
> 
> 
> Не понимаю, почему дело доходит до скрипта, если nginx видя хотлинк сразу
> должен отдать заглушку.

У вас в "location ~* ^/secret-files/" запрос попадает только после 
обработки скриптом, судя по всему.  И если скрипт не делает 
перенаправления в /secret-files/, то и проверки по $bad_referer не 
происходит.

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Tue Jun 18 03:31:24 2019
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 18 Jun 2019 06:31:24 +0300
Subject: =?UTF-8?B?bG9jYXRpb24gKyByZXdyaXRlINC4ICjQtNC1KdC60L7QtNC40YDQvtCy0LDQvdC4?=
 =?UTF-8?B?0LUgVVJJ?=
Message-ID: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>

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

Есть такой фрагмент документации на директиву location:

     Синтаксис: location [ = | ~ | ~* | ^~ ] uri { ... }

     Для сопоставления используется URI запроса в нормализованном виде,
     после декодирования текста, заданного в виде “%XX”, преобразования
     относительных элементов пути “.” и “..” в реальные и возможной
     замены двух и более подряд идущих слэшей на один.

Есть такой фрагмент конфига:

     location ~ ^/wiki/(?<title>.*) {
         return 301 https://$host/$title$is_args$args;
     }

Судя по документации, этот фрагмент конфига не должен работать, потому
что в $title ведь попадает уже декодированный русский текст из location?

Но почему-то эксперимент с помощью curl показывает, что в редиректе 
возвращается текст закодированный в виде “%XX”, а не обычный Unicode.

Почему все работает именно так и как тогда надо понимать документацию?

В каких случаях в nginx необходимо вручную кодировать/декодировать
фрагменты uri и/или переменные $arg_имя а когда этого делать не надо?

-- 
Best regards,
  Gena


From gmm на csdoc.com  Tue Jun 18 04:15:25 2019
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 18 Jun 2019 07:15:25 +0300
Subject: =?UTF-8?B?W25qc10g0LrQsNC6INGD0LfQvdCw0YLRjCDQuNC80LXQvdCwINCy0YHQtdGFINCw?=
 =?UTF-8?B?0YDQs9GD0LzQtdC90YLQvtCyINC/0LXRgNC10LTQsNC90L3Ri9GFINCyINC3?=
 =?UTF-8?B?0LDQv9GA0L7RgdC1Pw==?=
Message-ID: <dbbda4ac-ab8c-9d20-ad04-d8c7d872befa@csdoc.com>

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

Есть объект r.args, но он не работает согласно документации:

function redirect(r) {
  // ...
  r.warn(Object.values(r.args).join(','))
  // ...

- в лог пишется пустая строка. Хотя судя по документации,
Object.values(r.args) должен был бы возвращать массив:
https://nginx.org/en/docs/njs/reference.html#core_object

P.S.

Для организации редиректов на канонический урл (для защиты от DoS/DDoS
путем обхода/отравления кеша с помощью рандомных аргументов запроса)
необходимо узнать какие именно аргументы были переданы в запросе.
Каким образом это можно сделать с помощью njs ?
Только вручную в njs парсить переменную $args ?

Применяется это примерно таким образом:

js_include conf.d/example.com.js;
js_set $stopMobileRedirect stopMobileRedirect;
js_set $x_subdomain x_subdomain;
js_set $redirect redirect;

server {
     # ...
     location / {
             if ($redirect) {
                 add_header Set-Cookie $stopMobileRedirect;
                 return 302 $redirect;
             }
             # ...
     }
}

-- 
Best regards,
  Gena


From artem.povaluhin на gmail.com  Tue Jun 18 04:37:20 2019
From: artem.povaluhin на gmail.com (Artem S. Povalyukhin)
Date: Tue, 18 Jun 2019 07:37:20 +0300
Subject: =?UTF-8?B?UmU6IFtuanNdINC60LDQuiDRg9C30L3QsNGC0Ywg0LjQvNC10L3QsCDQstGB0LU=?=
 =?UTF-8?B?0YUg0LDRgNCz0YPQvNC10L3RgtC+0LIg0L/QtdGA0LXQtNCw0L3QvdGL0YUg?=
 =?UTF-8?B?0LIg0LfQsNC/0YDQvtGB0LU/?=
In-Reply-To: <dbbda4ac-ab8c-9d20-ad04-d8c7d872befa@csdoc.com>
References: <dbbda4ac-ab8c-9d20-ad04-d8c7d872befa@csdoc.com>
Message-ID: <cecb2195-4632-1eda-1723-545f156f7a69@gmail.com>

Привет!

On 6/18/19 7:15 AM, Gena Makhomed wrote:
> Здравствуйте, All!
>
> Есть объект r.args, но он не работает согласно документации:
>
> function redirect(r) {
>  // ...
>  r.warn(Object.values(r.args).join(','))
>  // ...
>
> - в лог пишется пустая строка. Хотя судя по документации,
> Object.values(r.args) должен был бы возвращать массив:
> https://nginx.org/en/docs/njs/reference.html#core_object
>
    var args = {};
    for (var k in r.args) {
        args[k] = r.args[k];
    }

    r.log(njs.dump(args));

Оно (r.args) не совсем объект обычный, проще скопировать.

wbr,
Artem


From mdounin на mdounin.ru  Tue Jun 18 08:27:41 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 18 Jun 2019 11:27:41 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
Message-ID: <20190618082741.GE1877@mdounin.ru>

Hello!

On Tue, Jun 18, 2019 at 06:31:24AM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> Есть такой фрагмент документации на директиву location:
> 
>      Синтаксис: location [ = | ~ | ~* | ^~ ] uri { ... }
> 
>      Для сопоставления используется URI запроса в нормализованном виде,
>      после декодирования текста, заданного в виде “%XX”, преобразования
>      относительных элементов пути “.” и “..” в реальные и возможной
>      замены двух и более подряд идущих слэшей на один.
> 
> Есть такой фрагмент конфига:
> 
>      location ~ ^/wiki/(?<title>.*) {
>          return 301 https://$host/$title$is_args$args;
>      }
> 
> Судя по документации, этот фрагмент конфига не должен работать, потому
> что в $title ведь попадает уже декодированный русский текст из location?
> 
> Но почему-то эксперимент с помощью curl показывает, что в редиректе 
> возвращается текст закодированный в виде “%XX”, а не обычный Unicode.

Эксперимент, видимо, плохой, негодный.

$ curl -vvv http://127.0.0.1:8080/wiki/%d1%82%d0%b5%d1%81%d1%82
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /wiki/%d1%82%d0%b5%d1%81%d1%82 HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.62.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.17.1
< Date: Tue, 18 Jun 2019 08:25:18 GMT
< Content-Type: text/html
< Content-Length: 169
< Connection: keep-alive
< Location: https://127.0.0.1/тест
< 
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.17.1</center>
</body>
</html>
* Connection #0 to host 127.0.0.1 left intact

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Tue Jun 18 10:27:36 2019
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 18 Jun 2019 13:27:36 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <20190618082741.GE1877@mdounin.ru>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
Message-ID: <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>

On 18.06.2019 11:27, Maxim Dounin wrote:

>> Есть такой фрагмент документации на директиву location:
>>
>>       Синтаксис: location [ = | ~ | ~* | ^~ ] uri { ... }
>>
>>       Для сопоставления используется URI запроса в нормализованном виде,
>>       после декодирования текста, заданного в виде “%XX”, преобразования
>>       относительных элементов пути “.” и “..” в реальные и возможной
>>       замены двух и более подряд идущих слэшей на один.

>> Есть такой фрагмент конфига:
>>
>>       location ~ ^/wiki/(?<title>.*) {
>>           return 301 https://$host/$title$is_args$args;
>>       }
>>

Получается, что в документации написано все правильно, приведенный
фрагмент конфига содержит ошибку, и правильно будет переписать его
таким образом:

======================================================================

Файл conf.d/example.com.js:

function title_encodeURIComponent(r) {
     return encodeURIComponent(r.variables.title);
}

Файл conf.d/example.com.conf:

js_include conf.d/example.com.js;
js_set $title_encodeURIComponent title_encodeURIComponent;

server {
     # ...
     location ~ ^/wiki/(?<title>.*) {
         return 301 https://$host/$title_encodeURIComponent$is_args$args;
     }
     # ...
}

======================================================================

?

Только в этом случае поведение nginx будет полностью соответствовать
RFC 3986 и более простого варианта решения этой задачи не существует?

-- 
Best regards,
  Gena


From mdounin на mdounin.ru  Tue Jun 18 11:09:57 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 18 Jun 2019 14:09:57 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
Message-ID: <20190618110957.GG1877@mdounin.ru>

Hello!

On Tue, Jun 18, 2019 at 01:27:36PM +0300, Gena Makhomed wrote:

> On 18.06.2019 11:27, Maxim Dounin wrote:
> 
> >> Есть такой фрагмент документации на директиву location:
> >>
> >>       Синтаксис: location [ = | ~ | ~* | ^~ ] uri { ... }
> >>
> >>       Для сопоставления используется URI запроса в нормализованном виде,
> >>       после декодирования текста, заданного в виде “%XX”, преобразования
> >>       относительных элементов пути “.” и “..” в реальные и возможной
> >>       замены двух и более подряд идущих слэшей на один.
> 
> >> Есть такой фрагмент конфига:
> >>
> >>       location ~ ^/wiki/(?<title>.*) {
> >>           return 301 https://$host/$title$is_args$args;
> >>       }
> >>
> 
> Получается, что в документации написано все правильно, приведенный
> фрагмент конфига содержит ошибку, и правильно будет переписать его
> таким образом:

[...]

> Только в этом случае поведение nginx будет полностью соответствовать
> RFC 3986 и более простого варианта решения этой задачи не существует?

Существует.  Проще всего сделать так:

    rewrite ^/wiki/(.*) https://$host/$1;

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Tue Jun 18 12:12:12 2019
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 18 Jun 2019 15:12:12 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <20190618110957.GG1877@mdounin.ru>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
Message-ID: <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>

On 18.06.2019 14:09, Maxim Dounin wrote:

> Проще всего сделать так:
> 
>      rewrite ^/wiki/(.*) https://$host/$1;

в таком случае в редиректе возвращается раскодированный урл:

$ curl -I https://example.com/wiki/%D1%82%D0%B5%D1%81%D1%82
HTTP/1.1 301 Moved Permanently
Location: https://example.com/тест

Более многословный вариант редиректа работает корректно,
так как и ожидается от него в соответствии с RFC 3986:

# curl -I https://example.com/wiki/%D1%82%D0%B5%D1%81%D1%82
HTTP/1.1 301 Moved Permanently
Location: https://example.com/%D1%82%D0%B5%D1%81%D1%82

Конфиг, который работает корректно:

Файл conf.d/example.com.js:

function title_encodeURIComponent(r) {
      return encodeURIComponent(r.variables.title);
}

Файл conf.d/example.com.conf:

js_include conf.d/example.com.js;
js_set $title_encodeURIComponent title_encodeURIComponent;

server {
      location ~ ^/wiki/(?<title>.*) {
         return 301 https://$host/$title_encodeURIComponent$is_args$args;
      }
}

-- 
Best regards,
  Gena


From mdounin на mdounin.ru  Tue Jun 18 12:26:52 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 18 Jun 2019 15:26:52 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
Message-ID: <20190618122652.GH1877@mdounin.ru>

Hello!

On Tue, Jun 18, 2019 at 03:12:12PM +0300, Gena Makhomed wrote:

> On 18.06.2019 14:09, Maxim Dounin wrote:
> 
> > Проще всего сделать так:
> > 
> >      rewrite ^/wiki/(.*) https://$host/$1;
> 
> в таком случае в редиректе возвращается раскодированный урл:
> 
> $ curl -I https://example.com/wiki/%D1%82%D0%B5%D1%81%D1%82
> HTTP/1.1 301 Moved Permanently
> Location: https://example.com/тест

И снова эксперимент плохой, негодный.

$ curl -vvv http://127.0.0.1:8080/wiki/%d1%82%d0%b5%d1%81%d1%82
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /wiki/%d1%82%d0%b5%d1%81%d1%82 HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.62.0
> Accept: */*
> 
< HTTP/1.1 302 Moved Temporarily
< Server: nginx/1.17.1
< Date: Tue, 18 Jun 2019 12:24:39 GMT
< Content-Type: text/html
< Content-Length: 145
< Connection: keep-alive
< Location: https://127.0.0.1/%D1%82%D0%B5%D1%81%D1%82
< 
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx/1.17.1</center>
</body>
</html>
* Connection #0 to host 127.0.0.1 left intact

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Tue Jun 18 13:45:13 2019
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 18 Jun 2019 16:45:13 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <20190618122652.GH1877@mdounin.ru>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
 <20190618122652.GH1877@mdounin.ru>
Message-ID: <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>

On 18.06.2019 15:26, Maxim Dounin wrote:

> И снова эксперимент плохой, негодный.

Вот полный конфиг тестового сервера:

server {
     listen 8080;

     location /wiki1/ {
         rewrite ^/wiki1/(.*) https://$host/$1;
     }

     location /wiki2/ {
         rewrite ^/wiki2/(?<title>.*) https://$host/$title;
     }
}

Вот запросы к первому и второму location`у:

$ curl -I http://127.0.0.1:8080/wiki1/%D1%82%D0%B5%D1%81%D1%82
Location: https://127.0.0.1/%D1%82%D0%B5%D1%81%D1%82

$ curl -I http://127.0.0.1:8080/wiki2/%D1%82%D0%B5%D1%81%D1%82
Location: https://127.0.0.1/тест

Первый и второй location отличаются между собой только тем,
что в первом используется неименованное выделение $1,
а во втором - именованное выделение $title.

И в то же время получаем такие разные результаты. Почему так?

Ведь с точки зрения пользователя и с точки зрения документации nginx
эти два location`а полностью идентичны по своему смыслу и поведению.

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Wed Jun 19 11:34:29 2019
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 19 Jun 2019 07:34:29 -0400
Subject: =?UTF-8?B?UmU6INCl0L7RgtC70LjQvdC6INGA0LDQsdC+0YLQsNC10YIg0LrQsNC6LdGC0L4g?=
 =?UTF-8?B?0L3QtSDRgtCw0Lo=?=
In-Reply-To: <20190617141420.GD1877@mdounin.ru>
References: <20190617141420.GD1877@mdounin.ru>
Message-ID: <a8259e00de69a7f98ae3041c976778a5.NginxMailingListRussian@forum.nginx.org>

Да, действительно так. Что-то я тупанул.

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


From mdounin на mdounin.ru  Wed Jun 19 11:54:10 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 19 Jun 2019 14:54:10 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
 <20190618122652.GH1877@mdounin.ru>
 <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>
Message-ID: <20190619115409.GI1877@mdounin.ru>

Hello!

On Tue, Jun 18, 2019 at 04:45:13PM +0300, Gena Makhomed wrote:

> On 18.06.2019 15:26, Maxim Dounin wrote:
> 
> > И снова эксперимент плохой, негодный.
> 
> Вот полный конфиг тестового сервера:
> 
> server {
>      listen 8080;
> 
>      location /wiki1/ {
>          rewrite ^/wiki1/(.*) https://$host/$1;
>      }
> 
>      location /wiki2/ {
>          rewrite ^/wiki2/(?<title>.*) https://$host/$title;
>      }
> }
> 
> Вот запросы к первому и второму location`у:
> 
> $ curl -I http://127.0.0.1:8080/wiki1/%D1%82%D0%B5%D1%81%D1%82
> Location: https://127.0.0.1/%D1%82%D0%B5%D1%81%D1%82
> 
> $ curl -I http://127.0.0.1:8080/wiki2/%D1%82%D0%B5%D1%81%D1%82
> Location: https://127.0.0.1/тест
> 
> Первый и второй location отличаются между собой только тем,
> что в первом используется неименованное выделение $1,
> а во втором - именованное выделение $title.
> 
> И в то же время получаем такие разные результаты. Почему так?

Потому что подстановка $1 делается из раскодированного URI 
запроса, и nginx знает, что данные в ней следует экранировать.  А 
$title - произвольная переменная, и как и любая произвольная 
переменная - подставляется в предположении, что данные в ней 
корректно экранированы.

В частности из-за этой магии обычно рекомендуют использовать 
return, где никакой подобной магии нет.  Но если речь идёт о 
изменениях URI с необходимостью снятия/восстановления 
экранирования - это один из наиболее простых путей.

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Wed Jun 19 13:46:46 2019
From: gmm на csdoc.com (Gena Makhomed)
Date: Wed, 19 Jun 2019 16:46:46 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <20190619115409.GI1877@mdounin.ru>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
 <20190618122652.GH1877@mdounin.ru>
 <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>
 <20190619115409.GI1877@mdounin.ru>
Message-ID: <7d4efca2-ce1a-66e7-8459-4938c36f84bc@csdoc.com>

On 19.06.2019 14:54, Maxim Dounin wrote:

>>       location /wiki1/ {
>>           rewrite ^/wiki1/(.*) https://$host/$1;
>>       }
>>
>>       location /wiki2/ {
>>           rewrite ^/wiki2/(?<title>.*) https://$host/$title;
>>       }
>>
>> Вот запросы к первому и второму location`у:
>>
>> $ curl -I http://127.0.0.1:8080/wiki1/%D1%82%D0%B5%D1%81%D1%82
>> Location: https://127.0.0.1/%D1%82%D0%B5%D1%81%D1%82
>>
>> $ curl -I http://127.0.0.1:8080/wiki2/%D1%82%D0%B5%D1%81%D1%82
>> Location: https://127.0.0.1/тест
>>
>> Первый и второй location отличаются между собой только тем,
>> что в первом используется неименованное выделение $1,
>> а во втором - именованное выделение $title.
>>
>> И в то же время получаем такие разные результаты. Почему так?

> Потому что подстановка $1 делается из раскодированного URI
> запроса, и nginx знает, что данные в ней следует экранировать.  А
> $title - произвольная переменная, и как и любая произвольная
> переменная - подставляется в предположении, что данные в ней
> корректно экранированы.
> 
> В частности из-за этой магии обычно рекомендуют использовать
> return, где никакой подобной магии нет.  Но если речь идёт о
> изменениях URI с необходимостью снятия/восстановления
> экранирования - это один из наиболее простых путей.

Понятно, спасибо.

Можно ли научить nginx, чтобы он писал в лог warn в том случае, если он
отправляет клиенту редирект с URI, который не соответствует требованиям
RFC 3986, например, когда там незакодированный текст на русском языке?

Например, можно ли сделать фильтр на njs, который будет проверять
все отправляемые клиенту редиректы и писать в лог warn в случае
ошибок в кодировании URI?

Можно ли в документации к nginx написать о той магии, которая есть
в директиве rewrite, в частности с автоматическим кодированием $1,$2,$3
и отсутствии автоматического кодирования обычных переменных?

Можно ли научить nginx, чтобы он делал warning во время парсинга
и проверки конфига в том случае, если в левой и в правой части
директивы rewrite присутствует одно и то же именованное выделение?

Или же, вместо этого, сделать магию не только с $1,$2,$3
но и с именованными выделениями, если одна и та же переменная
присутствует и в левой и в правой части директивы rewrite ?

Тогда location /wiki1/ и /wiki2/ будут вести себя идентично.
Чем меньше будет в nginx подобных подводных камней - тем меньше
он будет похож на sendmail в плане конфигурирования и использования.

-- 
Best regards,
  Gena


From bgx на protva.ru  Wed Jun 19 23:33:17 2019
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 20 Jun 2019 02:33:17 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <20190619115409.GI1877@mdounin.ru>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
 <20190618122652.GH1877@mdounin.ru>
 <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>
 <20190619115409.GI1877@mdounin.ru>
Message-ID: <20190619233317.GF5044@sie.protva.ru>

On Wed, Jun 19, 2019 at 02:54:10PM +0300, Maxim Dounin wrote:
> On Tue, Jun 18, 2019 at 04:45:13PM +0300, Gena Makhomed wrote:
> 
> > On 18.06.2019 15:26, Maxim Dounin wrote:
> > 
> > > И снова эксперимент плохой, негодный.
> > 
> > Вот полный конфиг тестового сервера:
> > 
> > server {
> >      listen 8080;
> > 
> >      location /wiki1/ {
> >          rewrite ^/wiki1/(.*) https://$host/$1;
> >      }
> > 
> >      location /wiki2/ {
> >          rewrite ^/wiki2/(?<title>.*) https://$host/$title;
> >      }
> > }
> > 
> > Вот запросы к первому и второму location`у:
> > 
> > $ curl -I http://127.0.0.1:8080/wiki1/%D1%82%D0%B5%D1%81%D1%82
> > Location: https://127.0.0.1/%D1%82%D0%B5%D1%81%D1%82
> > 
> > $ curl -I http://127.0.0.1:8080/wiki2/%D1%82%D0%B5%D1%81%D1%82
> > Location: https://127.0.0.1/тест
> > 
> > Первый и второй location отличаются между собой только тем,
> > что в первом используется неименованное выделение $1,
> > а во втором - именованное выделение $title.
> > 
> > И в то же время получаем такие разные результаты. Почему так?
> 
> Потому что подстановка $1 делается из раскодированного URI 
> запроса, и nginx знает, что данные в ней следует экранировать.  А 
> $title - произвольная переменная, и как и любая произвольная 
> переменная - подставляется в предположении, что данные в ней 
> корректно экранированы.

 Выглядит крайне непоследовательно (а если отбросить политкорректность,
 так это просто вынос мозга).

 IMHO, лучше было бы принять соглашение, что rewrite работает на уровне
 раскодированных URI и его результат подлежит кодированию.
 Для вставки уже кодированных строк понадобится функция декодирования,
 зато схема будет простой и предельно ясной.
-- 
 Eugene Berdnikov

From gmm на csdoc.com  Thu Jun 20 04:24:37 2019
From: gmm на csdoc.com (Gena Makhomed)
Date: Thu, 20 Jun 2019 07:24:37 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <20190619233317.GF5044@sie.protva.ru>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
 <20190618122652.GH1877@mdounin.ru>
 <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>
 <20190619115409.GI1877@mdounin.ru> <20190619233317.GF5044@sie.protva.ru>
Message-ID: <476f89da-1cd5-df88-bcfc-d07f3f1b73f1@csdoc.com>

On 20.06.2019 2:33, Evgeniy Berdnikov wrote:

>   IMHO, лучше было бы принять соглашение, что rewrite работает на уровне
>   раскодированных URI и его результат подлежит кодированию.
>   Для вставки уже кодированных строк понадобится функция декодирования,
>   зато схема будет простой и предельно ясной.

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

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

Например, в этом коде найдете ошибку?

============================================================

Файл conf.d/example.com.js:

function encoded_title(r) {
     return encodeURIComponent(r.variables.title);
}

Файл conf.d/example.com.conf:

js_include conf.d/example.com.js;
js_set $encoded_title encoded_title;

location ~ ^/wiki/(?<title>.*) {
     return 301 https://$host/$encoded_title$is_args$args;
}

============================================================

Ошибка в том, что /wiki/some/other/uri
превращается в /some%2Fother%2Furi

также /wiki/User:Example
превращается в /User%3AExample

Корректно работать будет только такой код:

============================================================

Файл conf.d/example.com.js:

function request_uri_without_wiki_prefix(r) {
     var request_uri = r.variables.request_uri;
     if (request_uri.startsWith('/wiki/')) {
         return request_uri.substring(5);
     } else {
         r.error('unexpected request_uri: ' + request_uri)
         return request_uri;
     }
}

Файл conf.d/example.com.conf:

js_include conf.d/example.com.js;
js_set $request_uri_without_wiki_prefix request_uri_without_wiki_prefix;

location /wiki/ {
     return 301 https://$host$request_uri_without_wiki_prefix;
}

============================================================

Или тот вариант конфигурации, который предлагает Максим:

location /wiki/ {
     rewrite ^/wiki/(.*) https://$host/$1 permanent;
}

-- 
Best regards,
  Gena


From bgx на protva.ru  Thu Jun 20 07:54:40 2019
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 20 Jun 2019 10:54:40 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <476f89da-1cd5-df88-bcfc-d07f3f1b73f1@csdoc.com>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
 <20190618122652.GH1877@mdounin.ru>
 <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>
 <20190619115409.GI1877@mdounin.ru>
 <20190619233317.GF5044@sie.protva.ru>
 <476f89da-1cd5-df88-bcfc-d07f3f1b73f1@csdoc.com>
Message-ID: <20190620075440.GG5044@sie.protva.ru>

On Thu, Jun 20, 2019 at 07:24:37AM +0300, Gena Makhomed wrote:
> Кроме того, процесс раскодирования сопровождается потерей информации,
> так что в результате потом невозможно будет корректно закодировать урл.
...
> Ошибка в том, что /wiki/some/other/uri
> превращается в /some%2Fother%2Furi

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

 Не хочется, чтобы nginx шёл по пути сендмейла. И таких "растяжек"
 с принципиально разной обработкой $1..$9 и $var тоже не хочется.
 
 Можно ведь удобный API дополнить какими-нибудь фишками до формально полного
 (например, отключив кодирование для подстроки какими-нибудь ограничителями
 вроде \N...\N, как это делается в регулярных выражениях).
 Нужда в кодировании разделителей это редкость, также как в кодировании
 разделителей строк и прочих спецсимволов, а оптимизировать интерфейс
 следует под шаблоны частого использования, IMHO.
-- 
 Eugene Berdnikov

From gmm на csdoc.com  Thu Jun 20 08:43:35 2019
From: gmm на csdoc.com (Gena Makhomed)
Date: Thu, 20 Jun 2019 11:43:35 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <20190620075440.GG5044@sie.protva.ru>
References: <9fe28723-7266-e9b0-faec-867cdf0a6c7d@csdoc.com>
 <20190618082741.GE1877@mdounin.ru>
 <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
 <20190618122652.GH1877@mdounin.ru>
 <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>
 <20190619115409.GI1877@mdounin.ru> <20190619233317.GF5044@sie.protva.ru>
 <476f89da-1cd5-df88-bcfc-d07f3f1b73f1@csdoc.com>
 <20190620075440.GG5044@sie.protva.ru>
Message-ID: <4c6e574e-cd90-1ec5-b0d5-5df1929818e7@csdoc.com>

On 20.06.2019 10:54, Evgeniy Berdnikov wrote:

>   Ну да, нужна тукенизация и способ обойти её, если в результат хочется
>   вставлять разделители тукенов (вспоминается sendmail, ага).
>   Но мне удобный и интуитивно понятный интерфейс всегда ближе формально
>   правильного и полного, но нечеловеческого, как у сендмейла.
> 
>   Не хочется, чтобы nginx шёл по пути сендмейла. И таких "растяжек"
>   с принципиально разной обработкой $1..$9 и $var тоже не хочется.

Разная обработка $1..$9 и $var уже есть. Вы сейчас предлагаете
сломать все работающие конфигурации, которые используют $1..$9 ?

http://mailman.nginx.org/pipermail/nginx-ru/2019-June/062281.html

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

>   Можно ведь удобный API дополнить какими-нибудь фишками до формально полного
>   (например, отключив кодирование для подстроки какими-нибудь ограничителями
>   вроде \N...\N, как это делается в регулярных выражениях).
>   Нужда в кодировании разделителей это редкость, также как в кодировании
>   разделителей строк и прочих спецсимволов, а оптимизировать интерфейс
>   следует под шаблоны частого использования, IMHO.

location /wiki/ {
     # сделать 301 редирект на $request_uri без префикса /wiki
}

Что именно Вы предлагаете написать в конфигурации nginx для того,
чтобы убрать префикс /wiki и сделать 301 редирект на новый урл,

при этом чтобы /wiki/some/other/uri
не превращалось в /some%2Fother%2Furi

а также /wiki/User:Example
не превращалось в /User%3AExample

?

-- 
Best regards,
  Gena


From bgx на protva.ru  Thu Jun 20 09:28:13 2019
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 20 Jun 2019 12:28:13 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uICsgcmV3cml0ZSDQuCAo0LTQtSnQutC+0LTQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC1IFVSSQ==?=
In-Reply-To: <4c6e574e-cd90-1ec5-b0d5-5df1929818e7@csdoc.com>
References: <6c2c606f-c5e6-8480-edc1-0afb3633aae6@csdoc.com>
 <20190618110957.GG1877@mdounin.ru>
 <86983ab4-4360-9d31-8657-07b99651e2c2@csdoc.com>
 <20190618122652.GH1877@mdounin.ru>
 <718cb211-3f07-809d-dd8d-1e29b3c9af33@csdoc.com>
 <20190619115409.GI1877@mdounin.ru>
 <20190619233317.GF5044@sie.protva.ru>
 <476f89da-1cd5-df88-bcfc-d07f3f1b73f1@csdoc.com>
 <20190620075440.GG5044@sie.protva.ru>
 <4c6e574e-cd90-1ec5-b0d5-5df1929818e7@csdoc.com>
Message-ID: <20190620092813.GJ5044@sie.protva.ru>

On Thu, Jun 20, 2019 at 11:43:35AM +0300, Gena Makhomed wrote:
> Что именно Вы предлагаете написать в конфигурации nginx для того,
> чтобы убрать префикс /wiki и сделать 301 редирект на новый урл,
> 
> при этом чтобы /wiki/some/other/uri
> не превращалось в /some%2Fother%2Furi

 Я же написал: нужна тукенизация. Т.е. строку следует разбивать по
 разделителям "/" и кодировать то, что оказалось между ними (тукены),
 затем возвращать назад разделители. Случай, когда нужно закодировать слеш,
 следует считать редким исключением и обрабатывать его отдельно.

> >   Не хочется, чтобы nginx шёл по пути сендмейла. И таких "растяжек"
> >   с принципиально разной обработкой $1..$9 и $var тоже не хочется.
> 
> Разная обработка $1..$9 и $var уже есть. Вы сейчас предлагаете
> сломать все работающие конфигурации, которые используют $1..$9 ?

 Есть целая наука про то, как правильно проводить изменения (процессов,
 инфраструктуры и т.п.), ничего не ломая. Пока я лишь говорю о том,
 какой хотелось бы иметь интерфейс, т.е. в каком направлении двигаться.
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Thu Jun 20 19:12:11 2019
From: nginx-forum на forum.nginx.org (darksmoke)
Date: Thu, 20 Jun 2019 15:12:11 -0400
Subject: =?UTF-8?B?TmdpbnggKyBMdWEg0LLQtdGA0L3Rg9GC0YwgSlNPTiwg0LrQsNC6Pw==?=
Message-ID: <d41f8272e4e16e104496eb7251de1e65.NginxMailingListRussian@forum.nginx.org>

Добрый день
Подскажите пожалуйста, как вернуть JSON в response?
Есть сам JSON

{"1_sign_level":"0200200","2_sign_level":"0200300"}

Пробовал ngx.say и cjson.encodeНо ничего не получается. Помогите,
пожалуйста, с кодом.

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


From nginx на mva.name  Tue Jun 25 07:32:24 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Tue, 25 Jun 2019 10:32:24 +0300
Subject: =?UTF-8?B?UmU6IE5naW54ICsgTHVhINCy0LXRgNC90YPRgtGMIEpTT04sINC60LDQuj8=?=
In-Reply-To: <d41f8272e4e16e104496eb7251de1e65.NginxMailingListRussian@forum.nginx.org>
References: <d41f8272e4e16e104496eb7251de1e65.NginxMailingListRussian@forum.nginx.org>
Message-ID: <10356690.Y0QUNCEorL@note>

как именно пробовали и что именно не получается?

From mdounin на mdounin.ru  Tue Jun 25 12:34:51 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 25 Jun 2019 15:34:51 +0300
Subject: nginx-1.17.1
Message-ID: <20190625123451.GW1877@mdounin.ru>

Изменения в nginx 1.17.1                                          25.06.2019

    *) Добавление: директива limit_req_dry_run.

    *) Добавление: при использовании директивы hash в блоке upstream пустой
       ключ хэширования теперь приводит к переключению на round-robin
       балансировку.
       Спасибо Niklas Keller.

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если использовалось кэширование и директива image_filter, а ошибки с
       кодом 415 перенаправлялись с помощь директивы error_page; ошибка
       появилась в 1.11.10.

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если использовался встроенный перл; ошибка появилась в 1.7.3.


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

From chipitsine на gmail.com  Fri Jun 28 08:27:50 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 28 Jun 2019 13:27:50 +0500
Subject: =?UTF-8?B?0L/RgNC+0LLQtdGA0LrQsCDQvdCw0LvQuNGH0LjRjyDRhNCw0LnQu9CwIHNzbF90?=
 =?UTF-8?B?cnVzdGVkX2NlcnRpZmljYXRlIC0g0L7QsdGB0YPQtNC40LwgPw==?=
Message-ID: <CAFHpkQFerdwMz_=Chq8nJ63oEKrNhKL91_Kho-E3zmwLeP3Lpw@mail.gmail.com>

привет,

допустим, я указал ssl_trusted_certificate

[root на optional ilia]# grep ssl_trusted_certificate /etc/nginx/nginx.conf
    ssl_trusted_certificate /etc/nginx/ca.pem;
[root на optional ilia]#

самого файла нет

[root на optional ilia]# ls -l /etc/nginx/ca.pem
ls: cannot access /etc/nginx/ca.pem: No such file or directory
[root на optional ilia]#

проверка синтаксиса проходит

[root на optional ilia]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root на optional ilia]#


можно сделать, чтобы "nginx -t" фейлился ?

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

From sytar.alex на gmail.com  Fri Jun 28 09:18:10 2019
From: sytar.alex на gmail.com (Aleksandr Sytar)
Date: Fri, 28 Jun 2019 12:18:10 +0300
Subject: =?UTF-8?B?UmU6INC/0YDQvtCy0LXRgNC60LAg0L3QsNC70LjRh9C40Y8g0YTQsNC50LvQsCBz?=
 =?UTF-8?B?c2xfdHJ1c3RlZF9jZXJ0aWZpY2F0ZSAtINC+0LHRgdGD0LTQuNC8ID8=?=
In-Reply-To: <CAFHpkQFerdwMz_=Chq8nJ63oEKrNhKL91_Kho-E3zmwLeP3Lpw@mail.gmail.com>
References: <CAFHpkQFerdwMz_=Chq8nJ63oEKrNhKL91_Kho-E3zmwLeP3Lpw@mail.gmail.com>
Message-ID: <CAKqRTSHV-_nrHh7sjEPctYJVnRE-D+kB9Pdg3bGETs3MVf2SjQ@mail.gmail.com>

пт, 28 июн. 2019 г. в 11:28, Илья Шипицин <chipitsine на gmail.com>:

> привет,
>
> допустим, я указал ssl_trusted_certificate
>
> [root на optional ilia]# grep ssl_trusted_certificate /etc/nginx/nginx.conf
>     ssl_trusted_certificate /etc/nginx/ca.pem;
> [root на optional ilia]#
>
> самого файла нет
>
> [root на optional ilia]# ls -l /etc/nginx/ca.pem
> ls: cannot access /etc/nginx/ca.pem: No such file or directory
> [root на optional ilia]#
>
> проверка синтаксиса проходит
>
> [root на optional ilia]# nginx -t
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successful
> [root на optional ilia]#
>
>
> можно сделать, чтобы "nginx -t" фейлился ?
>

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

From chipitsine на gmail.com  Fri Jun 28 10:03:18 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 28 Jun 2019 15:03:18 +0500
Subject: =?UTF-8?B?UmU6INC/0YDQvtCy0LXRgNC60LAg0L3QsNC70LjRh9C40Y8g0YTQsNC50LvQsCBz?=
 =?UTF-8?B?c2xfdHJ1c3RlZF9jZXJ0aWZpY2F0ZSAtINC+0LHRgdGD0LTQuNC8ID8=?=
In-Reply-To: <CAKqRTSHV-_nrHh7sjEPctYJVnRE-D+kB9Pdg3bGETs3MVf2SjQ@mail.gmail.com>
References: <CAFHpkQFerdwMz_=Chq8nJ63oEKrNhKL91_Kho-E3zmwLeP3Lpw@mail.gmail.com>
 <CAKqRTSHV-_nrHh7sjEPctYJVnRE-D+kB9Pdg3bGETs3MVf2SjQ@mail.gmail.com>
Message-ID: <CAFHpkQGynmH=tWpAgyT0aqpm8bzCaZxLt7brhEQdT_hgNZoZPw@mail.gmail.com>

пт, 28 июн. 2019 г. в 14:18, Aleksandr Sytar <sytar.alex на gmail.com>:

>
>
> пт, 28 июн. 2019 г. в 11:28, Илья Шипицин <chipitsine на gmail.com>:
>
>> привет,
>>
>> допустим, я указал ssl_trusted_certificate
>>
>> [root на optional ilia]# grep ssl_trusted_certificate /etc/nginx/nginx.conf
>>     ssl_trusted_certificate /etc/nginx/ca.pem;
>> [root на optional ilia]#
>>
>> самого файла нет
>>
>> [root на optional ilia]# ls -l /etc/nginx/ca.pem
>> ls: cannot access /etc/nginx/ca.pem: No such file or directory
>> [root на optional ilia]#
>>
>> проверка синтаксиса проходит
>>
>> [root на optional ilia]# nginx -t
>> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
>> nginx: configuration file /etc/nginx/nginx.conf test is successful
>> [root на optional ilia]#
>>
>>
>> можно сделать, чтобы "nginx -t" фейлился ?
>>
>
> Вроде раньше успешно фейлился, ты уверен что у тебя кеш дескрипторов не
> включен и ты не удалял файл после успешного запуска nginx?
>


не, такой экзотикой не балуемся.

недавно пробегал конфиг с несуществующим ssl_trusted_certificate, валидация
прошла.
сделал стенд, тоже прошла. в примере вверху минимальный стенд из
официального пакета 1.17.1
с добавленной в контекст "http" директивой на несуществующий файл


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

From nginx на mva.name  Sat Jun 29 11:39:20 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sat, 29 Jun 2019 14:39:20 +0300
Subject: =?UTF-8?B?Tmdpblgg0LrRgNC+0YjQuNGC0YHRjyDRgSBsaWJwZXJsLTUuMzA=?=
Message-ID: <2785435.FqUjOj16l6@note>

Уже в течение некоторого времени замечаю краши NgX при reload.

Сегодня дошли руки глянуть в чём дело, и обнаружил что крошится оно в перловой 
либе.

Попробовал подцепиться gdb'ом и получить трейс.

Вот что вышло:

0x00007f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () from 
/usr/lib64/libperl.so.5.30
(gdb)  bt full
#0  0x00007f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () 
from /usr/lib64/libperl.so.5.30
No symbol table info available.
#1  0x00007f59c0c46784 in ?? () from /usr/lib64/libperl.so.5.30
No symbol table info available.
#2  0x00007f59c0c567b9 in ?? () from /usr/lib64/libperl.so.5.30
No symbol table info available.
#3  0x00007f59c0c5c6a7 in ?? () from /usr/lib64/libperl.so.5.30
No symbol table info available.
#4  0x00007f59c0c610f8 in ?? () from /usr/lib64/libperl.so.5.30
No symbol table info available.
#5  0x00007f59c0c6156d in ?? () from /usr/lib64/libperl.so.5.30
No symbol table info available.
#6  0x00007f59c0c6647b in Perl_re_op_compile () from /usr/lib64/libperl.so.
5.30
No symbol table info available.
#7  0x00007f59c0bfab3c in Perl_pmruntime () from /usr/lib64/libperl.so.5.30
No symbol table info available.
#8  0x00007f59c0c37851 in Perl_yyparse () from /usr/lib64/libperl.so.5.30
No symbol table info available.
#9  0x00007f59c0ce1912 in ?? () from /usr/lib64/libperl.so.5.30
No symbol table info available.



Если честно, не хочется пересобирать перл с дебагом (чтобы открыть символы от 
#1 до #5), так что, надеюсь, этого трейса хватит. Но, если нет - скажите.

From mdounin на mdounin.ru  Sat Jun 29 11:40:35 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 29 Jun 2019 14:40:35 +0300
Subject: =?UTF-8?B?UmU6INC/0YDQvtCy0LXRgNC60LAg0L3QsNC70LjRh9C40Y8g0YTQsNC50LvQsCBz?=
 =?UTF-8?B?c2xfdHJ1c3RlZF9jZXJ0aWZpY2F0ZSAtINC+0LHRgdGD0LTQuNC8ID8=?=
In-Reply-To: <CAFHpkQFerdwMz_=Chq8nJ63oEKrNhKL91_Kho-E3zmwLeP3Lpw@mail.gmail.com>
References: <CAFHpkQFerdwMz_=Chq8nJ63oEKrNhKL91_Kho-E3zmwLeP3Lpw@mail.gmail.com>
Message-ID: <20190629114035.GB1877@mdounin.ru>

Hello!

On Fri, Jun 28, 2019 at 01:27:50PM +0500, Илья Шипицин wrote:

> привет,
> 
> допустим, я указал ssl_trusted_certificate
> 
> [root на optional ilia]# grep ssl_trusted_certificate /etc/nginx/nginx.conf
>     ssl_trusted_certificate /etc/nginx/ca.pem;
> [root на optional ilia]#
> 
> самого файла нет
> 
> [root на optional ilia]# ls -l /etc/nginx/ca.pem
> ls: cannot access /etc/nginx/ca.pem: No such file or directory
> [root на optional ilia]#
> 
> проверка синтаксиса проходит
> 
> [root на optional ilia]# nginx -t
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successful
> [root на optional ilia]#
> 
> 
> можно сделать, чтобы "nginx -t" фейлился ?

Такое может быть тогда и только тогда, когда файл из 
ssl_trusted_certificate не используется - e.g., переопределён во 
всех блоках server{}, где используется SSL, или SSL вообще не 
используется.

Заниматься проверкой ради проверки в подобных вырожденных
случаях - IMHO, особого смысла нет, в то время как кода придётся 
городить много.  А если/когда файл начнёт реально использоваться - 
будет ошибка при тестировании конфигурации.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Sat Jun 29 12:07:45 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 29 Jun 2019 15:07:45 +0300
Subject: =?UTF-8?B?UmU6IE5naW5YINC60YDQvtGI0LjRgtGB0Y8g0YEgbGlicGVybC01LjMw?=
In-Reply-To: <2785435.FqUjOj16l6@note>
References: <2785435.FqUjOj16l6@note>
Message-ID: <20190629120744.GC1877@mdounin.ru>

Hello!

On Sat, Jun 29, 2019 at 02:39:20PM +0300, Vadim A. Misbakh-Soloviov wrote:

> Уже в течение некоторого времени замечаю краши NgX при reload.
> 
> Сегодня дошли руки глянуть в чём дело, и обнаружил что крошится оно в перловой 
> либе.
> 
> Попробовал подцепиться gdb'ом и получить трейс.
> 
> Вот что вышло:
> 
> 0x00007f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () from 
> /usr/lib64/libperl.so.5.30
> (gdb)  bt full
> #0  0x00007f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () 
> from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #1  0x00007f59c0c46784 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #2  0x00007f59c0c567b9 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #3  0x00007f59c0c5c6a7 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #4  0x00007f59c0c610f8 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #5  0x00007f59c0c6156d in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #6  0x00007f59c0c6647b in Perl_re_op_compile () from /usr/lib64/libperl.so.
> 5.30
> No symbol table info available.
> #7  0x00007f59c0bfab3c in Perl_pmruntime () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #8  0x00007f59c0c37851 in Perl_yyparse () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #9  0x00007f59c0ce1912 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> 
> 
> 
> Если честно, не хочется пересобирать перл с дебагом (чтобы открыть символы от 
> #1 до #5), так что, надеюсь, этого трейса хватит. Но, если нет - скажите.

Судя по трейсу - Perl падает где-то в компиляции регулярных 
выражений.  Это, конечно, может быть и какой-то проблемой в 
nginx'е, но я бы поставил скорее на проблему в перле, которую 
триггерят используемые в коде регулярные выражения.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx на mva.name  Sat Jun 29 12:24:35 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sat, 29 Jun 2019 15:24:35 +0300
Subject: =?UTF-8?B?UmU6IE5naW5YINC60YDQvtGI0LjRgtGB0Y8g0YEgbGlicGVybC01LjMw?=
In-Reply-To: <20190629120744.GC1877@mdounin.ru>
References: <2785435.FqUjOj16l6@note> <20190629120744.GC1877@mdounin.ru>
Message-ID: <3009852.ISA1TGn0W8@note>


> Судя по трейсу - Perl падает где-то в компиляции регулярных
> выражений.  Это, конечно, может быть и какой-то проблемой в
> nginx'е, но я бы поставил скорее на проблему в перле, которую
> триггерят используемые в коде регулярные выражения.

Ну, в коде, вроде как, не используется никаких особо упоротых регулярок. В 
основном - всякие `location ~* \.php$` и в таком ключе.

Так что, по идее, не должно бы...

Ну и, я так понимаю, таки нужно пересобирать с дебагом и исходниками, чтобы 
отсделить что где? :)

From mdounin на mdounin.ru  Sat Jun 29 13:28:01 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 29 Jun 2019 16:28:01 +0300
Subject: =?UTF-8?B?UmU6IE5naW5YINC60YDQvtGI0LjRgtGB0Y8g0YEgbGlicGVybC01LjMw?=
In-Reply-To: <3009852.ISA1TGn0W8@note>
References: <2785435.FqUjOj16l6@note> <20190629120744.GC1877@mdounin.ru>
 <3009852.ISA1TGn0W8@note>
Message-ID: <20190629132800.GD1877@mdounin.ru>

Hello!

On Sat, Jun 29, 2019 at 03:24:35PM +0300, Vadim A. Misbakh-Soloviov wrote:

> > Судя по трейсу - Perl падает где-то в компиляции регулярных
> > выражений.  Это, конечно, может быть и какой-то проблемой в
> > nginx'е, но я бы поставил скорее на проблему в перле, которую
> > триггерят используемые в коде регулярные выражения.
> 
> Ну, в коде, вроде как, не используется никаких особо упоротых регулярок. В 
> основном - всякие `location ~* \.php$` и в таком ключе.

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

> Так что, по идее, не должно бы...
> 
> Ну и, я так понимаю, таки нужно пересобирать с дебагом и исходниками, чтобы 
> отсделить что где? :)

Для начала я бы попробовал получить простой способ воспроизведения 
проблемы - полный конфиг (включая perl-код) и последовательность действий, 
приводящие к падению.

Возможно - при использовании чего-нибудь простого вроде junk:true 
в malloc.conf (MALLOC_PERTURB_ на линуксе со стандартным аллокатором, 
подробности см. в mallopt(3)) оно начнёт падать сразу, и возможно 
даже без nginx'а.

А дальше - постараться вычленить, что именно вызывает проблему.  
Ну и неплохо бы проверить, не лечится ли всё банальным 
downgrade'ом на perl 5.28.x и/или upgrade'ом на 5.31.x.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx на mva.name  Sat Jun 29 16:28:19 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sat, 29 Jun 2019 19:28:19 +0300
Subject: =?UTF-8?B?UmU6IE5naW5YINC60YDQvtGI0LjRgtGB0Y8g0YEgbGlicGVybC01LjMw?=
In-Reply-To: <20190629132800.GD1877@mdounin.ru>
References: <2785435.FqUjOj16l6@note> <3009852.ISA1TGn0W8@note>
 <20190629132800.GD1877@mdounin.ru>
Message-ID: <4000386.dXMqPAoofX@note>

> Нет, регулярные выражения в конфиге nginx'а - nginx обрабатывает
> сам.  Надо смотреть именно на perl-код.  В том числе это может
> быть код в используемых perl-модулях.

Ну, в явном виде perl-модуль не используется нигде. Ни сайтов на нём нету, ни 
perl_*-директивы не используются...

> Для начала я бы попробовал получить простой способ воспроизведения
> проблемы - полный конфиг (включая perl-код) и последовательность действий,
> приводящие к падению.

Попробую выработать минимальный конфиг...

> 
> Возможно - при использовании чего-нибудь простого вроде junk:true
> в malloc.conf (MALLOC_PERTURB_ на линуксе со стандартным аллокатором,
> подробности см. в mallopt(3)) оно начнёт падать сразу, и возможно
> даже без nginx'а.

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

> А дальше - постараться вычленить, что именно вызывает проблему.
> Ну и неплохо бы проверить, не лечится ли всё банальным
> downgrade'ом на perl 5.28.x и/или upgrade'ом на 5.31.x.

Вообще, если честно, мне с дебагом пересобрать проще, чем обновить/
даунгрейднуть perl (потому что для последнего потребуется переустанавливать 
всё перлохозяйство, а это целая история с, в том числе, блокировками пакетов).

Ну и 5.31 в Gentoo пока не завезли.

А на 5.28 я (вроде (но это не точно)) не встречал этого.

Более того, на одной из машин я попробовал пересобрать с дебагом и оно 
перестало падать >_>

Сейчас вот собираю перл и NgX с дебагом на той, с которой трейс показывал...

From chipitsine на gmail.com  Sat Jun 29 16:47:45 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 29 Jun 2019 21:47:45 +0500
Subject: =?UTF-8?B?UmU6IE5naW5YINC60YDQvtGI0LjRgtGB0Y8g0YEgbGlicGVybC01LjMw?=
In-Reply-To: <2785435.FqUjOj16l6@note>
References: <2785435.FqUjOj16l6@note>
Message-ID: <CAFHpkQHKm-W0Ce3rVt0kzeWq0-xF8ppeSVzhukz+Ea5o8ajpSw@mail.gmail.com>

Какая у вас операционная система, perl из пакетов ставили? Пакет с
debuginfo можно доустановить?

On Sat, Jun 29, 2019, 4:39 PM Vadim A. Misbakh-Soloviov <nginx на mva.name>
wrote:

> Уже в течение некоторого времени замечаю краши NgX при reload.
>
> Сегодня дошли руки глянуть в чём дело, и обнаружил что крошится оно в
> перловой
> либе.
>
> Попробовал подцепиться gdb'ом и получить трейс.
>
> Вот что вышло:
>
> 0x00007f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd ()
> from
> /usr/lib64/libperl.so.5.30
> (gdb)  bt full
> #0  0x00007f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd
> ()
> from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #1  0x00007f59c0c46784 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #2  0x00007f59c0c567b9 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #3  0x00007f59c0c5c6a7 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #4  0x00007f59c0c610f8 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #5  0x00007f59c0c6156d in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #6  0x00007f59c0c6647b in Perl_re_op_compile () from /usr/lib64/libperl.so.
> 5.30
> No symbol table info available.
> #7  0x00007f59c0bfab3c in Perl_pmruntime () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #8  0x00007f59c0c37851 in Perl_yyparse () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #9  0x00007f59c0ce1912 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
>
>
>
> Если честно, не хочется пересобирать перл с дебагом (чтобы открыть символы
> от
> #1 до #5), так что, надеюсь, этого трейса хватит. Но, если нет - скажите.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190629/e527e228/attachment.html>

From nginx на mva.name  Sat Jun 29 17:00:59 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sat, 29 Jun 2019 20:00:59 +0300
Subject: =?UTF-8?B?UmU6IE5naW5YINC60YDQvtGI0LjRgtGB0Y8g0YEgbGlicGVybC01LjMw?=
In-Reply-To: <4000386.dXMqPAoofX@note>
References: <2785435.FqUjOj16l6@note> <20190629132800.GD1877@mdounin.ru>
 <4000386.dXMqPAoofX@note>
Message-ID: <3347191.DbvyDg0hYd@note>

Поправка: оно не падает в таком положении (даже на той машине) ТОЛЬКО если 
цепляться по -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
#5  0x00007ffff4e48074 in Perl__invlist_intersection_maybe_complement_2nd 
(my_perl=0x555555dd5c60, a=0x555555ba4470, b=0x555555ea8078, 
complement_b=true, i=0x7fffffff7c50) at regcomp.c:9752
#6  0x00007ffff4e71842 in S_populate_ANYOF_from_invlist 
(my_perl=0x555555dd5c60, node=0x5555558ee2c8, invlist_ptr=0x7fffffff7c50) at 
regcomp.c:14827
#7  0x00007ffff4e8a3cb in S_regclass (my_perl=0x555555dd5c60, 
pRExC_state=0x7fffffff8da0, flagp=0x7fffffff8454, depth=5, stop_at_1=false, 
allow_mutiple_chars=false, silence_non_portable=false, strict=false, 
optimizable=true, ret_invlist=0x0) at regcomp.c:19069
#8  0x00007ffff4e672b7 in S_regatom (my_perl=0x555555dd5c60, 
pRExC_state=0x7fffffff8da0, flagp=0x7fffffff8454, depth=4) at regcomp.c:13332
#9  0x00007ffff4e604a0 in S_regpiece (my_perl=0x555555dd5c60, 
pRExC_state=0x7fffffff8da0, flagp=0x7fffffff8570, depth=3) at regcomp.c:12457
#10 0x00007ffff4e5fcd8 in S_regbranch (my_perl=0x555555dd5c60, 
pRExC_state=0x7fffffff8da0, flagp=0x7fffffff8618, first=1, depth=2) at 
regcomp.c:12377
#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 
<PL_core_reg_engine>, old_re=0x0, is_bare_re=0x0, orig_rx_flags=0, 
pm_flags=1073741824) at regcomp.c:7705
#13 0x00007ffff4d43d43 in Perl_pmruntime (my_perl=0x555555dd5c60, 
o=0x555555dee948, expr=0x555555dee908, repl=0x0, flags=1, floor=0) at op.c:
7130
#14 0x00007ffff4e0e38f in Perl_yyparse (my_perl=0x555555dd5c60, gramtype=258) 
at perly.y:1234
#15 0x00007ffff50080ed in S_doeval_compile (my_perl=0x555555dd5c60, gimme=2 
'\002', outside=0x0, seq=183, hh=0x0) at pp_ctl.c:3502
#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
#18 0x00007ffff4eb6c4a in Perl_runops_debug (my_perl=0x555555dd5c60) at 
dump.c:2537
#19 0x00007ffff4d7e142 in Perl_call_sv (my_perl=0x555555dd5c60, 
sv=0x555555b9cde0, flags=13) at perl.c:3043
#20 0x00007ffff4d89318 in Perl_call_list (my_perl=0x555555dd5c60, oldscope=6, 
paramList=0x555555f9e480) at perl.c:5088
#21 0x00007ffff4d586c0 in S_process_special_blocks (my_perl=0x555555dd5c60, 
floor=171, fullname=0x555555f70cd8 "BEGIN", gv=0x555555f9e558, 
cv=0x555555b9cde0) at op.c:10471
#22 0x00007ffff4d57cac in Perl_newATTRSUB_x (my_perl=0x555555dd5c60, 
floor=171, o=0x555555ec8150, proto=0x0, attrs=0x0, block=0x555555ec8110, 
o_is_gv=false) at op.c:10397
#23 0x00007ffff4d458c2 in Perl_utilize (my_perl=0x555555dd5c60, aver=1, 
floor=171, version=0x0, idop=0x555555fac968, arg=0x5555558d5b08) at op.c:7592
#24 0x00007ffff4e0a061 in Perl_yyparse (my_perl=0x555555dd5c60, gramtype=258) 
at perly.y:335
#25 0x00007ffff50080ed in S_doeval_compile (my_perl=0x555555dd5c60, gimme=2 
'\002', outside=0x0, seq=4294967246, hh=0x0) at pp_ctl.c:3502
#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
#28 0x00007ffff4eb6c4a in Perl_runops_debug (my_perl=0x555555dd5c60) at 
dump.c:2537
#29 0x00007ffff4d7e142 in Perl_call_sv (my_perl=0x555555dd5c60, 
sv=0x555555f77f28, flags=13) at perl.c:3043
#30 0x00007ffff4d89318 in Perl_call_list (my_perl=0x555555dd5c60, oldscope=2, 
paramList=0x555555f77fa0) at perl.c:5088
#31 0x00007ffff4d586c0 in S_process_special_blocks (my_perl=0x555555dd5c60, 
floor=45, fullname=0x555555f70cd8 "BEGIN", gv=0x555555f77fb8, 
cv=0x555555f77f28) at op.c:10471
#32 0x00007ffff4d57cac in Perl_newATTRSUB_x (my_perl=0x555555dd5c60, floor=45, 
o=0x555555f73970, proto=0x0, attrs=0x0, block=0x555555f73930, o_is_gv=false) 
at op.c:10397
#33 0x00007ffff4d458c2 in Perl_utilize (my_perl=0x555555dd5c60, aver=1, 
floor=45, version=0x0, idop=0x555555f9c978, arg=0x0) at op.c:7592
#34 0x00007ffff4e0a061 in Perl_yyparse (my_perl=0x555555dd5c60, gramtype=258) 
at perly.y:335
#35 0x00007ffff4d7b4a3 in S_parse_body (my_perl=0x555555dd5c60, env=0x0, 
xsinit=0x5555556a3ab6 <ngx_http_perl_xs_init>) at perl.c:2531
#36 0x00007ffff4d791f8 in perl_parse (my_perl=0x555555dd5c60, 
xsinit=0x5555556a3ab6 <ngx_http_perl_xs_init>, argc=4, argv=0x555555acf8c8, 
env=0x0) at perl.c:1822
#37 0x00005555556a4988 in ngx_http_perl_create_interpreter (cf=0x7fffffffca70, 
pmcf=0x5555560b2c68) at src/http/modules/perl/ngx_http_perl_module.c:605
#38 0x00005555556a465c in ngx_http_perl_init_interpreter (cf=0x7fffffffca70, 
pmcf=0x5555560b2c68) at src/http/modules/perl/ngx_http_perl_module.c:524
#39 0x00005555556acc9a in ngx_http_perl_init_main_conf (cf=0x7fffffffca70, 
conf=0x5555560b2c68) at src/http/modules/perl/ngx_http_perl_module.c:819
#40 0x00005555555f7356 in ngx_http_block (cf=0x7fffffffca70, 
cmd=0x555555843380 <ngx_http_commands>, conf=0x555556431d10) at src/http/
ngx_http.c:262
#41 0x00005555555bfca7 in ngx_conf_handler (cf=0x7fffffffca70, last=1) at src/
core/ngx_conf_file.c:463
#42 0x00005555555bf7b0 in ngx_conf_parse (cf=0x7fffffffca70, 
filename=0x7fffffffc700) at src/core/ngx_conf_file.c:319
#43 0x00005555555c0b2c in ngx_conf_include (cf=0x7fffffffca70, 
cmd=0x5555558421c0 <ngx_conf_commands>, conf=0x555556431cd8) at src/core/
ngx_conf_file.c:873
#44 0x00005555555bfca7 in ngx_conf_handler (cf=0x7fffffffca70, last=0) at src/
core/ngx_conf_file.c:463
#45 0x00005555555bf7b0 in ngx_conf_parse (cf=0x7fffffffca70, 
filename=0x5555564309f0) at src/core/ngx_conf_file.c:319
#46 0x00005555555bae23 in ngx_init_cycle (old_cycle=0x5555558ca020) at src/
core/ngx_cycle.c:275
#47 0x00005555555e270f in ngx_master_process_cycle (cycle=0x5555558ca020) at 
src/os/unix/ngx_process_cycle.c:235
#48 0x0000555555599e26 in main (argc=3, argv=0x7fffffffd0d8) at src/core/
nginx.c:382
```



From nginx на mva.name  Sat Jun 29 17:04:16 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sat, 29 Jun 2019 20:04:16 +0300
Subject: =?UTF-8?B?UmU6IE5naW5YINC60YDQvtGI0LjRgtGB0Y8g0YEgbGlicGVybC01LjMw?=
In-Reply-To: <CAFHpkQHKm-W0Ce3rVt0kzeWq0-xF8ppeSVzhukz+Ea5o8ajpSw@mail.gmail.com>
References: <2785435.FqUjOj16l6@note>
 <CAFHpkQHKm-W0Ce3rVt0kzeWq0-xF8ppeSVzhukz+Ea5o8ajpSw@mail.gmail.com>
Message-ID: <2981083.NXo3YH2b4x@note>

Gentoo.

Perl из собран из дистрибутивного пакета.
Nginx — я в своём репозитории мейтейню отдельный пакет (с поддержкой сборки с 
дополнительными модулями, и работаю над выносом их в динамические).


В соседней ветке я только что опубликовал вывод с дебагом.