From vladget на gmail.com  Thu May  2 08:53:38 2019
From: vladget на gmail.com (Vladimir Getmanshchuk)
Date: Thu, 2 May 2019 11:53:38 +0300
Subject: epoll_ctl: file exists ?
In-Reply-To: <20190430143951.GW1877@mdounin.ru>
References: <CAFHpkQFLh0t-N38o6u+CJ5Y2b2fekC6kcyCEv3suKNJD5ojfew@mail.gmail.com>
 <20190430143951.GW1877@mdounin.ru>
Message-ID: <CAMxcU5JMRFR_8DV4ng_9pAg93iRjj7f9+_xknPjXvEGE4Oz=Xg@mail.gmail.com>

Максим, если найдете свободную минуту - расскажите пожалуйста почему.
Спасибо.

On Tue, Apr 30, 2019 at 5:39 PM Maxim Dounin <mdounin на mdounin.ru> wrote:

> Hello!
>
> On Tue, Apr 30, 2019 at 01:58:20PM +0500, Илья Шипицин wrote:
>
> > привет,
> >
> > насколько опасно вот такое ?
> >
> >
> > 2019/04/29 21:52:39 [alert] 1714#1714: *168061675 epoll_ctl(1, 1188)
> failed
> > (17: File exists) while proxying upgraded connection, client:
> > 82.114.112.115, server: market.kontur.ru, request: "GET /wsapi/
> HTTP/2.0",
> > upstream: "http://192.168.188.40:2339/wsapi/", host: "xxx.xxx.xxx"
>
> Судя по всему, имеет место попытка запихнуть вебсокеты в HTTP/2.
> Работать - не будет.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



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

From chipitsine на gmail.com  Thu May  2 09:04:55 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 2 May 2019 14:04:55 +0500
Subject: epoll_ctl: file exists ?
In-Reply-To: <CAMxcU5JMRFR_8DV4ng_9pAg93iRjj7f9+_xknPjXvEGE4Oz=Xg@mail.gmail.com>
References: <CAFHpkQFLh0t-N38o6u+CJ5Y2b2fekC6kcyCEv3suKNJD5ojfew@mail.gmail.com>
 <20190430143951.GW1877@mdounin.ru>
 <CAMxcU5JMRFR_8DV4ng_9pAg93iRjj7f9+_xknPjXvEGE4Oz=Xg@mail.gmail.com>
Message-ID: <CAFHpkQFj_YGH+BfZJyywNai-j0NwoRzgE5C=N+-Bz-9Y_SGm4Q@mail.gmail.com>

Ну, в общем вопрос требует изучения мат части. Изучу - расскажу.


Подобная ошибка возникает в единицах на сотню тысяч клиентов.

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

On Thu, May 2, 2019, 1:53 PM Vladimir Getmanshchuk <vladget на gmail.com>
wrote:

> Максим, если найдете свободную минуту - расскажите пожалуйста почему.
> Спасибо.
>
> On Tue, Apr 30, 2019 at 5:39 PM Maxim Dounin <mdounin на mdounin.ru> wrote:
>
>> Hello!
>>
>> On Tue, Apr 30, 2019 at 01:58:20PM +0500, Илья Шипицин wrote:
>>
>> > привет,
>> >
>> > насколько опасно вот такое ?
>> >
>> >
>> > 2019/04/29 21:52:39 [alert] 1714#1714: *168061675 epoll_ctl(1, 1188)
>> failed
>> > (17: File exists) while proxying upgraded connection, client:
>> > 82.114.112.115, server: market.kontur.ru, request: "GET /wsapi/
>> HTTP/2.0",
>> > upstream: "http://192.168.188.40:2339/wsapi/", host: "xxx.xxx.xxx"
>>
>> Судя по всему, имеет место попытка запихнуть вебсокеты в HTTP/2.
>> Работать - не будет.
>>
>> --
>> Maxim Dounin
>> http://mdounin.ru/
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --
> Yours sincerely,
> Vladimir Getmanshchuk
> _______________________________________________
> 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/20190502/d46eb177/attachment.html>

From mdounin на mdounin.ru  Fri May  3 22:07:20 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 4 May 2019 01:07:20 +0300
Subject: epoll_ctl: file exists ?
In-Reply-To: <CAMxcU5JMRFR_8DV4ng_9pAg93iRjj7f9+_xknPjXvEGE4Oz=Xg@mail.gmail.com>
References: <CAFHpkQFLh0t-N38o6u+CJ5Y2b2fekC6kcyCEv3suKNJD5ojfew@mail.gmail.com>
 <20190430143951.GW1877@mdounin.ru>
 <CAMxcU5JMRFR_8DV4ng_9pAg93iRjj7f9+_xknPjXvEGE4Oz=Xg@mail.gmail.com>
Message-ID: <20190503220720.GA1877@mdounin.ru>

Hello!

On Thu, May 02, 2019 at 11:53:38AM +0300, Vladimir Getmanshchuk wrote:

> Максим, если найдете свободную минуту - расскажите пожалуйста почему.
> Спасибо.

Потому что HTTP/2 не предусматривает возможности что-то делать с 
соединением, в частности - connection-related-заголовки явно 
запрещены стандартом[1].  А вебсокеты работают через Upgrade 
соединения в другой протокол, с помощью заголовков "Upgrade: 
websocket" и "Connection: upgrade".  То есть вебсокеты явно 
запрещены стандартом HTTP/2.  И даже примечание есть:

      Note: HTTP/2 purposefully does not support upgrade to another
      protocol.  The handshake methods described in Section 3 are
      believed sufficient to negotiate the use of alternative protocols.

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

Так что вебсокеты продолжают работать по HTTP/1.1.  Что, впрочем, 
представляется мне правильным - как протокол HTTP/2 оставляет 
желать, и это далеко не единственная его проблема.

(Делались попытки вебсокеты таки в HTTP/2 впихнуть - в частности, в 
прошлом году принят RFC 8441, "Bootstrapping WebSockets with 
HTTP/2"[2].  Через 3 года после принятия стандарта HTTP/2.  Но 
это, скажем так, выглядит как хак, при этом малосовместимый с 
существующей логикой работы через Upgrade, и имеет мало шансов 
быть поддержанным.)

[1] https://tools.ietf.org/html/rfc7540#section-8.1.2.2
[2] https://tools.ietf.org/html/rfc8441

> On Tue, Apr 30, 2019 at 5:39 PM Maxim Dounin <mdounin на mdounin.ru> wrote:
> 
> > Hello!
> >
> > On Tue, Apr 30, 2019 at 01:58:20PM +0500, Илья Шипицин wrote:
> >
> > > привет,
> > >
> > > насколько опасно вот такое ?
> > >
> > >
> > > 2019/04/29 21:52:39 [alert] 1714#1714: *168061675 epoll_ctl(1, 1188)
> > failed
> > > (17: File exists) while proxying upgraded connection, client:
> > > 82.114.112.115, server: market.kontur.ru, request: "GET /wsapi/
> > HTTP/2.0",
> > > upstream: "http://192.168.188.40:2339/wsapi/", host: "xxx.xxx.xxx"
> >
> > Судя по всему, имеет место попытка запихнуть вебсокеты в HTTP/2.
> > Работать - не будет.

[...]

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

From mdounin на mdounin.ru  Fri May  3 22:19:19 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 4 May 2019 01:19:19 +0300
Subject: epoll_ctl: file exists ?
In-Reply-To: <CAFHpkQFj_YGH+BfZJyywNai-j0NwoRzgE5C=N+-Bz-9Y_SGm4Q@mail.gmail.com>
References: <CAFHpkQFLh0t-N38o6u+CJ5Y2b2fekC6kcyCEv3suKNJD5ojfew@mail.gmail.com>
 <20190430143951.GW1877@mdounin.ru>
 <CAMxcU5JMRFR_8DV4ng_9pAg93iRjj7f9+_xknPjXvEGE4Oz=Xg@mail.gmail.com>
 <CAFHpkQFj_YGH+BfZJyywNai-j0NwoRzgE5C=N+-Bz-9Y_SGm4Q@mail.gmail.com>
Message-ID: <20190503221919.GB1877@mdounin.ru>

Hello!

On Thu, May 02, 2019 at 02:04:55PM +0500, Илья Шипицин wrote:

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

Скорее всего проблема в том, что клиент в нарушение стандарта 
HTTP/2 пытается присылать Upgrade, а у вас конфигурация такова, 
что этот заголовок для HTTP/2 не игнорируется, а передаётся на 
бэкенд - и бэкенд возвращает 101 Switching Protocols, что в свою 
очередь приводит к ошибке, когда nginx это переключение протоколов 
пытается обработать.  Лечится - игнорированием попыток клиентов 
использовать вебсокеты в рамках HTTP/2.

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

From nginx-forum на forum.nginx.org  Sat May  4 17:24:20 2019
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Sat, 04 May 2019 13:24:20 -0400
Subject: epoll_ctl: file exists ?
In-Reply-To: <20190503220720.GA1877@mdounin.ru>
References: <20190503220720.GA1877@mdounin.ru>
Message-ID: <fa38fcd7ee59ca4f7a6e1b8e5932eb76.NginxMailingListRussian@forum.nginx.org>

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

Есть реализация (клиент и сервер)
https://github.com/warmcat/libwebsockets

В Chrome тоже давно работает.
https://www.chromestatus.com/feature/6251293127475200

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


From nginx-forum на forum.nginx.org  Mon May  6 09:18:06 2019
From: nginx-forum на forum.nginx.org (grey)
Date: Mon, 06 May 2019 05:18:06 -0400
Subject: =?UTF-8?B?Tmdpbngg0L7RgtC00LDQtdGCINGB0YLQsNGC0LjQutGDINCyINGA0LXQttC40Lw=?=
 =?UTF-8?B?0LUgU1NMINCyIDItMyDRgNCw0LfQsCDQvNC10LTQu9C10L3QtdC1?=
Message-ID: <a953b9ddb53dd0777eac1055ce7ac4df.NginxMailingListRussian@forum.nginx.org>

Приветствую всех.

Есть средненький сервер (AMD Opteron 2,8ГГц Dual Core / 8 Гб). На нем
расположен не сильно незагруженый сайт с видео файлами. Все это работает под
управлением Windows Server 2008 R2. Потребовалось подключить для сайта
https. Что и было сделано. Но тут выяснилось, что скорость отдачи видео
nginx v1.15.10 падает почти в два-три раза по сравнению с http. Первое, что
я подумал - это процессор не справляется, но он загружен на 5-10%. Памяти
свободной - полно. Качаю файл по http одна скорость, качаю по https - почти
в 2-3 раза меньше. Вот конфиг отвечающий за шифрование:

		listen       443 ssl;
	ssl_certificate domain.crt;
	ssl_certificate_key domain-key.txt;
	ssl_session_timeout 1d;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;

	ssl_ciphers
'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
	ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

	ssl_prefer_server_ciphers on;

	ssl_stapling on;
	ssl_stapling_verify on;

	ssl_trusted_certificate domain.crt;
	resolver 8.8.8.8 8.8.4.4;

Сертификат на пробу взял бесплатный на Let's Encrypt. Он 4096 битный, может
дело в этом?

Подскажите, что может так сильно ограничивать скорость отдачи?

Заранее спасибо.

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


From nginx-forum на forum.nginx.org  Tue May  7 17:13:44 2019
From: nginx-forum на forum.nginx.org (rihad)
Date: Tue, 07 May 2019 13:13:44 -0400
Subject: nginx: [warn] "ssl_stapling" ignored,
 issuer certificate not found for certificate
 "/path/to/example.com/fullchain.cer"
Message-ID: <5ebcccca339f5bd2be460f2c0074e3ac.NginxMailingListRussian@forum.nginx.org>

Эти варны возникли при чтении конфига после обновления до nginx с 1.14.2 до
1.16.0 (ОС: FreeBSD 11.2). 
Даунгрейд до 1.14.2 убирает сообщения..
Используем сертфикаты Let's Encrypt и клиент acme.sh

Конфиг SSL Stapling:

ssl_stapling on;
ssl_stapling_verify on;

Типичный конфиг домена (коих много):

    ssl_certificate /home/acme/.acme.sh/example.com/fullchain.cer;
    ssl_certificate_key /home/acme/.acme.sh/example.com/example.com.key;

Внутри fullchain.cer сидят два сертификата, второй из которых всегда
одинаков для всех.

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


From mdounin на mdounin.ru  Tue May  7 18:03:25 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 7 May 2019 21:03:25 +0300
Subject: nginx: [warn] "ssl_stapling" ignored,
 issuer certificate not found for certificate
 "/path/to/example.com/fullchain.cer"
In-Reply-To: <5ebcccca339f5bd2be460f2c0074e3ac.NginxMailingListRussian@forum.nginx.org>
References: <5ebcccca339f5bd2be460f2c0074e3ac.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190507180325.GK1877@mdounin.ru>

Hello!

On Tue, May 07, 2019 at 01:13:44PM -0400, rihad wrote:

> Эти варны возникли при чтении конфига после обновления до nginx с 1.14.2 до
> 1.16.0 (ОС: FreeBSD 11.2). 
> Даунгрейд до 1.14.2 убирает сообщения..
> Используем сертфикаты Let's Encrypt и клиент acme.sh
> 
> Конфиг SSL Stapling:
> 
> ssl_stapling on;
> ssl_stapling_verify on;
> 
> Типичный конфиг домена (коих много):
> 
>     ssl_certificate /home/acme/.acme.sh/example.com/fullchain.cer;
>     ssl_certificate_key /home/acme/.acme.sh/example.com/example.com.key;
> 
> Внутри fullchain.cer сидят два сертификата, второй из которых всегда
> одинаков для всех.

Покажите пример fullchain.cer.  Кроме того, было бы неплохо 
увидеть вывод "nginx -V" для обоих версий, и пример минимального 
полного конфига, демонстрирующего проблему.

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

From nginx-forum на forum.nginx.org  Wed May  8 03:53:39 2019
From: nginx-forum на forum.nginx.org (rihad)
Date: Tue, 07 May 2019 23:53:39 -0400
Subject: nginx: [warn] "ssl_stapling" ignored,
 issuer certificate not found for certificate
 "/path/to/example.com/fullchain.cer"
In-Reply-To: <20190507180325.GK1877@mdounin.ru>
References: <20190507180325.GK1877@mdounin.ru>
Message-ID: <3f8bc727932c81f7336c00d59d3f4ce9.NginxMailingListRussian@forum.nginx.org>

-----BEGIN CERTIFICATE-----
MIIFsjCCBJqgAwIBAgISA1J3jfFIPKXDLBQ8ihTsBqlrMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA0MDkxODIyNDFaFw0x
OTA3MDgxODIyNDFaMCcxJTAjBgNVBAMTHHR1cmJvYXotMTM5NTEwNjc0LmF6c3Rh
Z2UuaW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNww06PtB5nP25
rQ2hYlhqx4POuTxCaDcHRg36t2oGeMTkFC75qBl+DjyXxJmlMsObEO5nt5zgaqcL
Jl49s0acI/yA+hSh7vQpZRZ+4/jQ11R8QLd/9oOrhUqJ9fxgzHitsFIRFeh0pNxW
eROmDqYJlSMEr5wxmmJtWEEMbLlFxIm/2/NUovXrZJOsoc5bx1sdsJnFpumdeFbU
aYG1vPxD9NN5sGgwLFHdK3QDp8RdLGqV5ylhN6kadgnQElRpIaX9QNyRANUnNeGX
jj3wuiovL9xx0gR+wcatMFc4y3JJORkcLtEk28y6qEcNQ0g5jYbqh1317Y7ByH0d
BVJLm7djAgMBAAGjggKzMIICrzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYI
KwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFHE9h0j5
aniSTd8SMYcz0E08fFe4MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyh
MG8GCCsGAQUFBwEBBGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgz
LmxldHNlbmNyeXB0Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgz
LmxldHNlbmNyeXB0Lm9yZy8wagYDVR0RBGMwYYIfcnUudHVyYm9hei0xMzk1MTA2
NzQuYXpzdGFnZS5pboIgc3NsLnR1cmJvYXotMTM5NTEwNjc0LmF6c3RhZ2UuaW6C
HHR1cmJvYXotMTM5NTEwNjc0LmF6c3RhZ2UuaW4wTAYDVR0gBEUwQzAIBgZngQwB
AgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRz
ZW5jcnlwdC5vcmcwggEDBgorBgEEAdZ5AgQCBIH0BIHxAO8AdgDiaUuuJujpQAno
hhu2O4PUPuf+dIj7pI8okwGd3fHb/gAAAWoDjW7TAAAEAwBHMEUCIQDpdUACdcIx
U0al7y8pAA6mfkDmXqKVSU8gOGc3YihxywIgE8+nQjzXKYSLCoDLA+fB27SjVwrS
mtVec9UN/cf+IvgAdQApPFGWVMg5ZbqqUPxYB9S3b79Yeily3KTDDPTlRUf0eAAA
AWoDjWzkAAAEAwBGMEQCIDxpqP3iNu0/PpXG9UDV6cKYLrhKNIs8TTvaTUMV0o4S
AiBy+XNTIij/IjcwEOcG/GVWlTVQMq2vH9N9nmSCUwviuDANBgkqhkiG9w0BAQsF
AAOCAQEACto3pd6I2VMWl5mgbw+/A9SDgFW2saw1Ju3iIcYP37uWeCzFwZZXg1pP
Lf4mgfxiE2Qyv3J9KFZNklBGJ2Ga/PaP861uib0Y1l8dOcADFPNvjuThpm3537Zy
I7hr63bE6qnDrwitleZJcb4SOW46cme81DmW9uZBtMSUrAlL2dbU5/PH+YjSeNwq
JYndjTX4NAUmLyTF/H4IpsOLsWcIprGMUX+CvmoonN/Ona8gUSvQS3UzCdfgzgHZ
KW3m6iYwz3GeAJ1gK0XKZKMK31jDV3S1rNWcXuClgRHKQq75JpCfL3Iu50soiH5p
es5SViQLNlbEjdAOSS55Jic36Nog3Q==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----

Последняя версия acme.sh сует пустую строку между первым и вторым, это никак
не влияет ни на что.

$ nginx -V
nginx version: nginx/1.14.2
built with OpenSSL 1.0.2o-freebsd  27 Mar 2018
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_v2_module
--with-http_addition_module --with-http_auth_request_module
--with-http_dav_module --with-http_flv_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module --with-pcre
--with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-http_stub_status_module --with-http_sub_module
--without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module --with-mail_ssl_module --with-stream_ssl_module
--with-stream_ssl_preread_module --with-threads --with-mail=dynamic
--with-stream=dynamic

$ nginx -V
nginx version: nginx/1.16.0
built with OpenSSL 1.0.2o-freebsd  27 Mar 2018
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_v2_module
--with-http_addition_module --with-http_auth_request_module
--with-http_dav_module --with-http_flv_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module --with-pcre
--with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-http_stub_status_module --with-http_sub_module
--without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module --with-mail_ssl_module --with-stream_ssl_module
--with-stream_ssl_preread_module --with-threads --with-mail=dynamic
--with-stream=dynamic

Конфиг nginx.conf попробую дать чуть позже.

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


From nginx-forum на forum.nginx.org  Wed May  8 04:02:39 2019
From: nginx-forum на forum.nginx.org (rihad)
Date: Wed, 08 May 2019 00:02:39 -0400
Subject: nginx: [warn] "ssl_stapling" ignored,
 issuer certificate not found for certificate
 "/path/to/example.com/fullchain.cer"
In-Reply-To: <3f8bc727932c81f7336c00d59d3f4ce9.NginxMailingListRussian@forum.nginx.org>
References: <20190507180325.GK1877@mdounin.ru>
 <3f8bc727932c81f7336c00d59d3f4ce9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e5364fb27fcb8ca6d8a8c15b1ea403ae.NginxMailingListRussian@forum.nginx.org>

Нашел причину. Дело в том, что нам нужен модуль brotli, а его в дефолтном
пакете nginx на FreeBSD нет, поэтому строим сами www/nginx из порта, и она
строится с LibreSSL. Вот с ней эти SSL stapling ворнинги бывают. Не уверен
кому адресовать )

[rihad на master /usr/local/etc/nginx]$ nginx -V
nginx version: nginx/1.16.0
built with LibreSSL 2.9.1
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--with-debug --modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_v2_module
--with-http_addition_module --with-http_auth_request_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_realip_module --with-pcre --with-http_secure_link_module
--with-http_slice_module --with-http_ssl_module
--with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include'
--without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module --with-stream_ssl_preread_module --with-threads
--add-dynamic-module=/usr/ports/www/nginx/work/ngx_brotli-8104036

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


From nginx-forum на forum.nginx.org  Wed May  8 04:10:32 2019
From: nginx-forum на forum.nginx.org (rihad)
Date: Wed, 08 May 2019 00:10:32 -0400
Subject: nginx: [warn] "ssl_stapling" ignored,
 issuer certificate not found for certificate
 "/path/to/example.com/fullchain.cer"
In-Reply-To: <e5364fb27fcb8ca6d8a8c15b1ea403ae.NginxMailingListRussian@forum.nginx.org>
References: <20190507180325.GK1877@mdounin.ru>
 <3f8bc727932c81f7336c00d59d3f4ce9.NginxMailingListRussian@forum.nginx.org>
 <e5364fb27fcb8ca6d8a8c15b1ea403ae.NginxMailingListRussian@forum.nginx.org>
Message-ID: <ae5fffc2092386c24e229d8129a36d74.NginxMailingListRussian@forum.nginx.org>

Вот эта сборка с LibreSSL проблемная. Без нее (если убрать
DEFAULT_VERSIONS+=ssl=libressl из /etc/make.conf или просто поставить пакет)
нет ворнингов.

[rihad на master /usr/local/etc/nginx]$ nginx -V
nginx version: nginx/1.16.0
built with LibreSSL 2.9.1
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--with-debug --modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_v2_module
--with-http_addition_module --with-http_auth_request_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_realip_module --with-pcre --with-http_secure_link_module
--with-http_slice_module --with-http_ssl_module
--with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include'
--without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module --with-stream_ssl_preread_module --with-threads
--add-dynamic-module=/usr/ports/www/nginx/work/ngx_brotli-8104036

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


From nginx-forum на forum.nginx.org  Wed May  8 09:30:41 2019
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 08 May 2019 05:30:41 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <a953b9ddb53dd0777eac1055ce7ac4df.NginxMailingListRussian@forum.nginx.org>
References: <a953b9ddb53dd0777eac1055ce7ac4df.NginxMailingListRussian@forum.nginx.org>
Message-ID: <ff046b00544f1b55c9f9cec5edd90235.NginxMailingListRussian@forum.nginx.org>

Неужели ни у кого нет идей?

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


From chipitsine на gmail.com  Wed May  8 10:08:11 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 8 May 2019 15:08:11 +0500
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <ff046b00544f1b55c9f9cec5edd90235.NginxMailingListRussian@forum.nginx.org>
References: <a953b9ddb53dd0777eac1055ce7ac4df.NginxMailingListRussian@forum.nginx.org>
 <ff046b00544f1b55c9f9cec5edd90235.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHrcPLubXdVs9fHkZLiFTAN=RwJ0RGY_GRnBe56yDpmYw@mail.gmail.com>

статика какого размера ? (к вопросу о том, что SSL добавляет еще один
уровень буферизации по отношению к компрессии, на маленьких объемах
буферизация может давать такие задержки)

ср, 8 мая 2019 г. в 14:30, grey <nginx-forum на forum.nginx.org>:

> Неужели ни у кого нет идей?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,284047,284091#msg-284091
>
> _______________________________________________
> 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/20190508/41fce316/attachment-0001.html>

From bgx на protva.ru  Wed May  8 10:33:38 2019
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 8 May 2019 13:33:38 +0300
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <ff046b00544f1b55c9f9cec5edd90235.NginxMailingListRussian@forum.nginx.org>
References: <a953b9ddb53dd0777eac1055ce7ac4df.NginxMailingListRussian@forum.nginx.org>
 <ff046b00544f1b55c9f9cec5edd90235.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190508103337.GC3085@protva.ru>

On Wed, May 08, 2019 at 05:30:41AM -0400, grey wrote:
> Неужели ни у кого нет идей?

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

 С какой скоростью отдаётся одиночный файл размером 300-500 мег
 на машину в том же LANе, какая при этом загрузка процессора?
-- 
 Eugene Berdnikov

From skobolo на gmail.com  Wed May  8 10:36:17 2019
From: skobolo на gmail.com (Seva Kobylin)
Date: Wed, 8 May 2019 13:36:17 +0300
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <20190508103337.GC3085@protva.ru>
References: <a953b9ddb53dd0777eac1055ce7ac4df.NginxMailingListRussian@forum.nginx.org>
 <ff046b00544f1b55c9f9cec5edd90235.NginxMailingListRussian@forum.nginx.org>
 <20190508103337.GC3085@protva.ru>
Message-ID: <A871DD6D-1F7D-41E4-885F-DCEB72101036@gmail.com>

И нужен ли на статике стаплинг кстати, неясно, тем более с нелокальным резолвером

> 8 мая 2019 г., в 13:33, Evgeniy Berdnikov <bgx на protva.ru> написал(а):
> 
> On Wed, May 08, 2019 at 05:30:41AM -0400, grey wrote:
>> Неужели ни у кого нет идей?
> 
> Расскажите, что, как и чем измеряли, с чем сравнивали,
> что ожидали увидеть и почему.
> 
> С какой скоростью отдаётся одиночный файл размером 300-500 мег
> на машину в том же LANе, какая при этом загрузка процессора?
> -- 
> Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum на forum.nginx.org  Wed May  8 11:01:40 2019
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 08 May 2019 07:01:40 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <CAFHpkQHrcPLubXdVs9fHkZLiFTAN=RwJ0RGY_GRnBe56yDpmYw@mail.gmail.com>
References: <CAFHpkQHrcPLubXdVs9fHkZLiFTAN=RwJ0RGY_GRnBe56yDpmYw@mail.gmail.com>
Message-ID: <5ce40a489834a47353e564f82f5a0800.NginxMailingListRussian@forum.nginx.org>

Статика - это видео файлы размером 100-200Мб.

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


From nginx-forum на forum.nginx.org  Wed May  8 11:16:49 2019
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 08 May 2019 07:16:49 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <20190508103337.GC3085@protva.ru>
References: <20190508103337.GC3085@protva.ru>
Message-ID: <1d9c8c43933d121cc26c3170fdf5ccd4.NginxMailingListRussian@forum.nginx.org>

Меряю скорость банально в разных браузерах, но оно и на глаз видно что плеер
буферизирует данные периодически.
Захожу по ссылки http://site.ru/video.mp4 - скорость допустим 5Мб/сек,
захожу через httpS://site.ru/video.mp4 - падает до 1,5Мб/сек.

Других компьютеров в этом же ЛАНе нет, он один подключен к инету напрямую.
Попробую что-нибудь придумать и проверить скорость.

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


From chipitsine на gmail.com  Wed May  8 11:21:04 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 8 May 2019 16:21:04 +0500
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <1d9c8c43933d121cc26c3170fdf5ccd4.NginxMailingListRussian@forum.nginx.org>
References: <20190508103337.GC3085@protva.ru>
 <1d9c8c43933d121cc26c3170fdf5ccd4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQH=COCaSSt0NcmEQH8v+1dXLwmYncH3qCiL=peSuxPRYg@mail.gmail.com>

DPI )) ?

On Wed, May 8, 2019, 4:16 PM grey <nginx-forum на forum.nginx.org> wrote:

> Меряю скорость банально в разных браузерах, но оно и на глаз видно что
> плеер
> буферизирует данные периодически.
> Захожу по ссылки http://site.ru/video.mp4 - скорость допустим 5Мб/сек,
> захожу через httpS://site.ru/video.mp4 - падает до 1,5Мб/сек.
>
> Других компьютеров в этом же ЛАНе нет, он один подключен к инету напрямую.
> Попробую что-нибудь придумать и проверить скорость.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,284047,284096#msg-284096
>
> _______________________________________________
> 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/20190508/5d9da13a/attachment.html>

From nginx-forum на forum.nginx.org  Wed May  8 11:23:25 2019
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 08 May 2019 07:23:25 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <5ce40a489834a47353e564f82f5a0800.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQHrcPLubXdVs9fHkZLiFTAN=RwJ0RGY_GRnBe56yDpmYw@mail.gmail.com>
 <5ce40a489834a47353e564f82f5a0800.NginxMailingListRussian@forum.nginx.org>
Message-ID: <9bfd4d2346822ebd4b7fa86e88ecc7fb.NginxMailingListRussian@forum.nginx.org>

Вы про ssl_buffer_size? Если да, то я поигрался с разными значениями -
становилось или еще медленее или скорость оставалась такой же.

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


From chipitsine на gmail.com  Wed May  8 11:25:43 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 8 May 2019 16:25:43 +0500
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <9bfd4d2346822ebd4b7fa86e88ecc7fb.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQHrcPLubXdVs9fHkZLiFTAN=RwJ0RGY_GRnBe56yDpmYw@mail.gmail.com>
 <5ce40a489834a47353e564f82f5a0800.NginxMailingListRussian@forum.nginx.org>
 <9bfd4d2346822ebd4b7fa86e88ecc7fb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQH0=uN__zFGiOqxDA5hxRw9gM-5rcOBpqxcMHX7F6JSJA@mail.gmail.com>

На размерах 200-300мб не будет отличий. Вложенная буферизация проявляется
на ответах размером 1-2 пакета

On Wed, May 8, 2019, 4:23 PM grey <nginx-forum на forum.nginx.org> wrote:

> Вы про ssl_buffer_size? Если да, то я поигрался с разными значениями -
> становилось или еще медленее или скорость оставалась такой же.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,284047,284098#msg-284098
>
> _______________________________________________
> 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/20190508/9d0540b3/attachment-0001.html>

From mdounin на mdounin.ru  Wed May  8 12:53:35 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 8 May 2019 15:53:35 +0300
Subject: nginx: [warn] "ssl_stapling" ignored,
 issuer certificate not found for certificate
 "/path/to/example.com/fullchain.cer"
In-Reply-To: <ae5fffc2092386c24e229d8129a36d74.NginxMailingListRussian@forum.nginx.org>
References: <20190507180325.GK1877@mdounin.ru>
 <3f8bc727932c81f7336c00d59d3f4ce9.NginxMailingListRussian@forum.nginx.org>
 <e5364fb27fcb8ca6d8a8c15b1ea403ae.NginxMailingListRussian@forum.nginx.org>
 <ae5fffc2092386c24e229d8129a36d74.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20190508125335.GL1877@mdounin.ru>

Hello!

On Wed, May 08, 2019 at 12:10:32AM -0400, rihad wrote:

> Вот эта сборка с LibreSSL проблемная. Без нее (если убрать
> DEFAULT_VERSIONS+=ssl=libressl из /etc/make.conf или просто поставить пакет)
> нет ворнингов.
> 
> [rihad на master /usr/local/etc/nginx]$ nginx -V
> nginx version: nginx/1.16.0
> built with LibreSSL 2.9.1

[...]

Судя по всему, в LibreSSL неправильно реализована функция 
SSL_CTX_get_extra_chain_certs() - ведёт себя так, как должно вести 
функция SSL_CTX_get_extra_chain_certs_only(), и не возвращает 
цепочку дополнительных сертификатов, установленную для конкретного 
сертификата, а возвращает только общую цепочку для контекста.

Если я правильно понимаю, поддержку отдельных цепочек для 
сертификатов в LibreSSL только начали пилить в 2.9.x, и пока не 
допилили до конца.  Но поскольку в LibreSSL 2.9.1 появилась функция 
SSL_CTX_set0_chain() - nginx начал её использовать, и отсутствие 
соответствующей реализации SSL_CTX_get_extra_chain_certs() 
сказывается.

Стоит ребятам сообщить, чтобы починили.

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

From vas на mpeks.tomsk.su  Sun May 12 03:55:24 2019
From: vas на mpeks.tomsk.su (Victor Sudakov)
Date: Sun, 12 May 2019 10:55:24 +0700
Subject: .htaccess
Message-ID: <20190512035524.GA78673@admin.sibptus.ru>

Коллеги,

Много развелось Web-приложений и сайтов, которые очень сильно полагаются
на код в .htaccess.  Смотришь - а там и RewriteRule, и "Header set...", и
установка каких-то переменных, и MIME types переопределяются... 

Есть какая-то общая теория и рекомендации, как всё это хозяйство
переносить под nginx, например под php-fpm ?

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49 на fidonet http://vas.tomsk.ru/

From nginx-forum на forum.nginx.org  Sun May 12 07:28:36 2019
From: nginx-forum на forum.nginx.org (rihad)
Date: Sun, 12 May 2019 03:28:36 -0400
Subject: proxy_next_upstream & HTTP 502
Message-ID: <cafd81bb7ddd84db392220d400fa2de5.NginxMailingListRussian@forum.nginx.org>

У нас стоит:
proxy_next_upstream     error timeout http_500 http_502 http_503 http_504;

Иногда в случае если один из апстримов в дауне в access.log появляются
подобные строчки:


10.10.10.10 - S387DE34EI-1557637722 [12/May/2019:05:08:42 +0000] "GET
/blah/blah HTTP/1.1" 502 12001 "-" "- example.com" "-"

nginx логирует запрос только если попробовал все апстримы, или после
каждого? Здесь больше похоже на второе. Можно ли как-то настроить чтобы
логировался только результат последнего попробованного апстрима? Он и будет
результатом запроса.

nginx version: nginx/1.14.0

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


From corochoone на gmail.com  Sun May 12 07:35:28 2019
From: corochoone на gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCS0LjRgdC70L7QsdC+0LrQvtCy?=)
Date: Sun, 12 May 2019 10:35:28 +0300
Subject: .htaccess
In-Reply-To: <20190512035524.GA78673@admin.sibptus.ru>
References: <20190512035524.GA78673@admin.sibptus.ru>
Message-ID: <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>

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

Мне кажется пора бы уже nginx'у научиться эмулировать поведение apache
и юзать его .htaccess при включении специальной директивы. Я понимаю,
что конфиг компилируется в момент запуска nginx, но всё-таки такое
поведение логично. Сейчас пользователи, которые рулят поведением
своего сайта самостоятельно, лишены возможности делать это с nginx, а
это, на мой взгляд неправильно. Да, администратор может создать
кастомные правила для конкретного сайта, но это именно что
администратор, а не простой пользователь.

В качестве полумеры, хотя бы получить средство, которое компилирует
директивы .htaccess  в директивы nginx, чтобы потом иметь возможность
подгружать это в nginx через reload конфигурации nginx (который можно
организовать клиенту через sudo и внешний скрипт, проверяющий
валидность конфига).

12.05.2019, Victor Sudakov<vas на mpeks.tomsk.su> написал(а):
> Коллеги,
>
> Много развелось Web-приложений и сайтов, которые очень сильно полагаются
> на код в .htaccess.  Смотришь - а там и RewriteRule, и "Header set...", и
> установка каких-то переменных, и MIME types переопределяются...
>
> Есть какая-то общая теория и рекомендации, как всё это хозяйство
> переносить под nginx, например под php-fpm ?
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> 2:5005/49 на fidonet http://vas.tomsk.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From identw на gmail.com  Sun May 12 15:13:44 2019
From: identw на gmail.com (Dmitry Sergeev)
Date: Sun, 12 May 2019 20:13:44 +0500
Subject: proxy_next_upstream & HTTP 502
In-Reply-To: <cafd81bb7ddd84db392220d400fa2de5.NginxMailingListRussian@forum.nginx.org>
References: <cafd81bb7ddd84db392220d400fa2de5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <a5ff388c-eac1-2ecf-ad30-533673ddb8d3@gmail.com>

Насколько

> nginx логирует запрос только если попробовал все апстримы, или после 
> каждого? Здесь больше похоже на второе. Можно ли как-то настроить 
> чтобы логировался только результат последнего попробованного апстрима? 
> Он и будет результатом запроса. 
http://nginx.org/ru/docs/http/ngx_http_upstream_module.html - здесь 
указано, что запрос передается в случае неудачи следующему серверу 
апстрима, и в случае неуспеха, будет возвращен результат последнего. А 
так как в access_log возвращается фактический код ответа клиенту, то на 
один запрос от клиента должна быть одна запись в access_log. Если бы на 
один запрос, было бы несколько записей - то это очень странное поведение.

Я  вроде эксперементировал на этот счет, в случае трех серверов в 
апстриме, в access_log попадает одна запись с фактическим кодом ответа 
клиенту, в error_log попадает три записи, о том что неудалось 
соединиться с каждым серверов из  апрстрима.

-- 
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72

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

From andrey на kopeyko.ru  Sun May 12 22:28:18 2019
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Mon, 13 May 2019 01:28:18 +0300
Subject: .htaccess
In-Reply-To: <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
Message-ID: <6b66cd53a2a5784ee05e05631b8d80a6@kopeyko.ru>

Виктор Вислобоков писал 2019-05-12 10:35:
> 
> Мне кажется пора бы уже nginx'у научиться эмулировать поведение apache
> и юзать его .htaccess при включении специальной директивы.

Где ваш патч?


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

From annulen на yandex.ru  Sun May 12 23:16:02 2019
From: annulen на yandex.ru (Konstantin Tokarev)
Date: Mon, 13 May 2019 02:16:02 +0300
Subject: .htaccess
In-Reply-To: <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
Message-ID: <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>



12.05.2019, 10:35, "Виктор Вислобоков" <corochoone на gmail.com>:
> По ответу на вопрос - насколько мне известно - нет. Всё ручками,
> ручками. Но сама тема давно уже назрела, на мой взгляд.
>
> Мне кажется пора бы уже nginx'у научиться эмулировать поведение apache
> и юзать его .htaccess при включении специальной директивы.

Зачем, если пользователь может просто установить Apache?

-- 
Regards,
Konstantin


From corochoone на gmail.com  Mon May 13 06:00:54 2019
From: corochoone на gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCS0LjRgdC70L7QsdC+0LrQvtCy?=)
Date: Mon, 13 May 2019 09:00:54 +0300
Subject: .htaccess
In-Reply-To: <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
Message-ID: <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>

>> Зачем, если пользователь может просто установить Apache?
Читайте начальный пост ТС. Он говорил при наличии php-fpm.
Связка nginx+apache увы, не даёт той производительности, которую даёт
связка nginx+php-fpm.


13.05.2019, Konstantin Tokarev<annulen на yandex.ru> написал(а):
>
>
> 12.05.2019, 10:35, "Виктор Вислобоков" <corochoone на gmail.com>:
>> По ответу на вопрос - насколько мне известно - нет. Всё ручками,
>> ручками. Но сама тема давно уже назрела, на мой взгляд.
>>
>> Мне кажется пора бы уже nginx'у научиться эмулировать поведение apache
>> и юзать его .htaccess при включении специальной директивы.
>
> Зачем, если пользователь может просто установить Apache?
>
> --
> Regards,
> Konstantin
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From bgx на protva.ru  Mon May 13 08:41:15 2019
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 13 May 2019 11:41:15 +0300
Subject: .htaccess
In-Reply-To: <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
 <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
Message-ID: <20190513084115.GA30033@protva.ru>

On Mon, May 13, 2019 at 09:00:54AM +0300, Виктор Вислобоков wrote:
> >> Зачем, если пользователь может просто установить Apache?
> Читайте начальный пост ТС. Он говорил при наличии php-fpm.
> Связка nginx+apache увы, не даёт той производительности, которую даёт
> связка nginx+php-fpm.

 Перетащите всю требуху с .htaccess в nginx, и будет он тормозить
 так же как Апач. :)
-- 
 Eugene Berdnikov

From corochoone на gmail.com  Mon May 13 09:16:52 2019
From: corochoone на gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCS0LjRgdC70L7QsdC+0LrQvtCy?=)
Date: Mon, 13 May 2019 12:16:52 +0300
Subject: .htaccess
In-Reply-To: <20190513084115.GA30033@protva.ru>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
 <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
 <20190513084115.GA30033@protva.ru>
Message-ID: <CAM6AoWb2=GmfqzUfexd-s_OEVhOajdk4VFjEHgLa5Et00SC4CQ@mail.gmail.com>

Не будет. Проверено.

13.05.2019, Evgeniy Berdnikov<bgx на protva.ru> написал(а):
> On Mon, May 13, 2019 at 09:00:54AM +0300, Виктор Вислобоков wrote:
>> >> Зачем, если пользователь может просто установить Apache?
>> Читайте начальный пост ТС. Он говорил при наличии php-fpm.
>> Связка nginx+apache увы, не даёт той производительности, которую даёт
>> связка nginx+php-fpm.
>
>  Перетащите всю требуху с .htaccess в nginx, и будет он тормозить
>  так же как Апач. :)
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From bgx на protva.ru  Mon May 13 09:19:21 2019
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 13 May 2019 12:19:21 +0300
Subject: .htaccess
In-Reply-To: <CAM6AoWb2=GmfqzUfexd-s_OEVhOajdk4VFjEHgLa5Et00SC4CQ@mail.gmail.com>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
 <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
 <20190513084115.GA30033@protva.ru>
 <CAM6AoWb2=GmfqzUfexd-s_OEVhOajdk4VFjEHgLa5Et00SC4CQ@mail.gmail.com>
Message-ID: <20190513091921.GA30518@protva.ru>

On Mon, May 13, 2019 at 12:16:52PM +0300, Виктор Вислобоков wrote:
> Не будет. Проверено.

 Чем проверено, уже написан нужный модуль для nginx?

> 13.05.2019, Evgeniy Berdnikov<bgx на protva.ru> написал(а):
> > On Mon, May 13, 2019 at 09:00:54AM +0300, Виктор Вислобоков wrote:
> >> >> Зачем, если пользователь может просто установить Apache?
> >> Читайте начальный пост ТС. Он говорил при наличии php-fpm.
> >> Связка nginx+apache увы, не даёт той производительности, которую даёт
> >> связка nginx+php-fpm.
> >
> >  Перетащите всю требуху с .htaccess в nginx, и будет он тормозить
> >  так же как Апач. :)

-- 
 Eugene Berdnikov

From kvt на kvtsoftware.com  Mon May 13 09:36:13 2019
From: kvt на kvtsoftware.com (kvt на kvtsoftware.com)
Date: Mon, 13 May 2019 12:36:13 +0300
Subject: .htaccess
In-Reply-To: <20190513091921.GA30518@protva.ru>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
 <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
 <20190513084115.GA30033@protva.ru>
 <CAM6AoWb2=GmfqzUfexd-s_OEVhOajdk4VFjEHgLa5Et00SC4CQ@mail.gmail.com>
 <20190513091921.GA30518@protva.ru>
Message-ID: <18257561557740173@myt5-0fa3e541b8b9.qloud-c.yandex.net>

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

From annulen на yandex.ru  Mon May 13 10:28:47 2019
From: annulen на yandex.ru (Konstantin Tokarev)
Date: Mon, 13 May 2019 13:28:47 +0300
Subject: .htaccess
In-Reply-To: <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
 <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
Message-ID: <11699221557743327@iva4-0814df7d67c8.qloud-c.yandex.net>



13.05.2019, 09:01, "Виктор Вислобоков" <corochoone на gmail.com>:
>>>  Зачем, если пользователь может просто установить Apache?
>
> Читайте начальный пост ТС. Он говорил при наличии php-fpm.
> Связка nginx+apache увы, не даёт той производительности, которую даёт
> связка nginx+php-fpm.

Можно сделать apache (mpm event) + php-fpm

-- 
Regards,
Konstantin


From ek на nginx.com  Mon May 13 13:37:19 2019
From: ek на nginx.com (Ekaterina Kukushkina)
Date: Mon, 13 May 2019 16:37:19 +0300
Subject: proxy_next_upstream & HTTP 502
In-Reply-To: <cafd81bb7ddd84db392220d400fa2de5.NginxMailingListRussian@forum.nginx.org>
References: <cafd81bb7ddd84db392220d400fa2de5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <19153D13-A7E3-4984-B89C-9862E3B717C4@nginx.com>

Добрый день, 

> On 12 May 2019, at 10:28, rihad <nginx-forum на forum.nginx.org> wrote:
> 
> У нас стоит:
> proxy_next_upstream     error timeout http_500 http_502 http_503 http_504;
> 
> Иногда в случае если один из апстримов в дауне в access.log появляются
> подобные строчки:
> 
> 
> 10.10.10.10 - S387DE34EI-1557637722 [12/May/2019:05:08:42 +0000] "GET
> /blah/blah HTTP/1.1" 502 12001 "-" "- example.com" "-"
> 
> nginx логирует запрос только если попробовал все апстримы, или после
> каждого? Здесь больше похоже на второе. Можно ли как-то настроить чтобы
> логировался только результат последнего попробованного апстрима? Он и будет
> результатом запроса.
> 

В большинстве случаев, в access лог логгируется один раз на клиентский
запрос независимо от того, сколько апстримов потрогано.
Несколько записей может быть, если nginx делает подзапросы (ssi, njs, etc)
и log_subrequest установлен в on. Либо при использовании нескольких
уровней проксирований на nginx. Полагаю, что это не ваш случай.

В access log имеет логгировать следующие переменные:
$status - итоговый ответ клиету (есть в дефолных форматах)
$upstream_addr - все потрогранные апстримы
$upstream_status - статусы потроганных апстримов

http://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables

--
Ekaterina Kukushkina

From thresh на nginx.com  Tue May 14 11:28:31 2019
From: thresh на nginx.com (Konstantin Pavlov)
Date: Tue, 14 May 2019 14:28:31 +0300
Subject: =?UTF-8?B?0J/QsNC60LXRgtGLINC00LvRjyBMaW51eDog0LTQvtCx0LDQstC70LXQvSBSSEVM?=
 =?UTF-8?B?IDg=?=
Message-ID: <49bf031b-9eef-fc9c-4d45-7c16c4982136@nginx.com>

Привет,

В рамках наших постоянных усилий по внедрению поддержки новых платформ и
операционных систем для nginx, бинарные пакеты от nginx.org теперь
доступны и для RHEL 8.

Прочитать о том, как настраивать репозиторий и устанавливать пакеты
можно на https://nginx.org/ru/linux_packages.html#RHEL-CentOS.

Исходные коды средств пакетирования доступны на
http://hg.nginx.org/pkg-oss/file/default/rpm/.

Хорошего дня,

-- 
Konstantin Pavlov
https://www.nginx.com/

From nginx на mva.name  Tue May 14 23:44:29 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Wed, 15 May 2019 02:44:29 +0300
Subject: .htaccess
In-Reply-To: <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
 <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
Message-ID: <2007260.A7rT2u0pJu@note>

Логичнее было бы NgX+Unit. И реализовывать обработку htaccess в юните.

// а ещё лучше - в коде приложения :)

В письме от понедельник, 13 мая 2019 г. 09:00:54 MSK пользователь Виктор 
Вислобоков написал:
> >> Зачем, если пользователь может просто установить Apache?
> 
> Читайте начальный пост ТС. Он говорил при наличии php-fpm.
> Связка nginx+apache увы, не даёт той производительности, которую даёт
> связка nginx+php-fpm.
> 
> 
> 13.05.2019, Konstantin Tokarev<annulen на yandex.ru> написал(а):
> 
> >
> >
> >
> > 12.05.2019, 10:35, "Виктор Вислобоков" <corochoone на gmail.com>:
> > 
> >> По ответу на вопрос - насколько мне известно - нет. Всё ручками,
> >> ручками. Но сама тема давно уже назрела, на мой взгляд.
> >>
> >>
> >>
> >> Мне кажется пора бы уже nginx'у научиться эмулировать поведение apache
> >> и юзать его .htaccess при включении специальной директивы.
> >
> >
> >
> > Зачем, если пользователь может просто установить Apache?
> >
> >
> >
> > --
> > Regards,
> > Konstantin
> >
> >
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From vas на mpeks.tomsk.su  Wed May 15 07:57:43 2019
From: vas на mpeks.tomsk.su (Victor Sudakov)
Date: Wed, 15 May 2019 14:57:43 +0700
Subject: .htaccess
In-Reply-To: <18257561557740173@myt5-0fa3e541b8b9.qloud-c.yandex.net>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
 <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
 <20190513084115.GA30033@protva.ru>
 <CAM6AoWb2=GmfqzUfexd-s_OEVhOajdk4VFjEHgLa5Et00SC4CQ@mail.gmail.com>
 <20190513091921.GA30518@protva.ru>
 <18257561557740173@myt5-0fa3e541b8b9.qloud-c.yandex.net>
Message-ID: <20190515075743.GA61260@admin.sibptus.ru>

kvt на kvtsoftware.com wrote:
>    Скорее всего написан, например RusOnyx использует такую штуку у себя на
>    хостинге, автоматически конвертирует htaccess в правила для nginx

Но ведь это фактически транслятор конфига apache в конфиг nginx, потому
что в htaccess могут быть почти любые директивы apache.


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49 на fidonet http://vas.tomsk.ru/

From kvt на kvtsoftware.com  Wed May 15 08:05:16 2019
From: kvt на kvtsoftware.com (kvt на kvtsoftware.com)
Date: Wed, 15 May 2019 11:05:16 +0300
Subject: .htaccess
In-Reply-To: <20190515075743.GA61260@admin.sibptus.ru>
References: <20190512035524.GA78673@admin.sibptus.ru>
 <CAM6AoWb=0hu5ANSqKD6=Hhao3wKpcoNgQ7YO6ThSYV6A3AkEog@mail.gmail.com>
 <12286591557702962@myt5-a323eb993ef7.qloud-c.yandex.net>
 <CAM6AoWbe-y+QUOAp=5v5iduqHvqk3EbR9EHLZ_JLLMNVsYiwpw@mail.gmail.com>
 <20190513084115.GA30033@protva.ru>
 <CAM6AoWb2=GmfqzUfexd-s_OEVhOajdk4VFjEHgLa5Et00SC4CQ@mail.gmail.com>
 <20190513091921.GA30518@protva.ru>
 <18257561557740173@myt5-0fa3e541b8b9.qloud-c.yandex.net>
 <20190515075743.GA61260@admin.sibptus.ru>
Message-ID: <4950381557907516@iva3-bb39b28eb4f4.qloud-c.yandex.net>

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

From nginx-forum на forum.nginx.org  Wed May 15 08:32:34 2019
From: nginx-forum на forum.nginx.org (ingtar)
Date: Wed, 15 May 2019 04:32:34 -0400
Subject: =?UTF-8?Q?Listen_=D0=B8_default_server?=
Message-ID: <71f450ed30ae529083bbaed23d3e8006.NginxMailingListRussian@forum.nginx.org>

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

server {
    listen 8000;
    server_name test1;

    location / {
        return 200 'responce from test1';
    }
}

server {
    listen 8000 default_server;
    server_name test2;

    location / {
        return 200 'responce from test2!';
    }
}

server {
    listen 8000 ;
    server_name test3;

    location / {
        return 200 'responce from test3!';
    }
}

Тут все хорошо, запросы с заголовками test1,2,3 попадают в нужные хосты, без
заголовков попадают в default
но если указать у любого listen конкретный ip, например 127.0.0.1 то все
запросы начинает обрабатывать именно он, игнорируя заголовки Host и
default_server

Чисто логически я понимаю, что у него приоритет ИП, но выглядит странно :)
Есть какие-то практики в этом случае - только ИП везде или все без ИП?

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


From raven_kg на megaline.kg  Wed May 15 08:35:11 2019
From: raven_kg на megaline.kg (raven_kg на megaline.kg)
Date: Wed, 15 May 2019 14:35:11 +0600
Subject: =?UTF-8?Q?Re=3A_Listen_=D0=B8_default_server?=
In-Reply-To: <71f450ed30ae529083bbaed23d3e8006.NginxMailingListRussian@forum.nginx.org>
References: <71f450ed30ae529083bbaed23d3e8006.NginxMailingListRussian@forum.nginx.org>
Message-ID: <9e9eee60-62c1-47fb-7991-281a97fc3669@megaline.kg>

Где нужен конкретный IP - указывать IP, где нет - использовать 0.0.0.0

15.05.2019 14:32, ingtar пишет:
> Столкнулся с такой ситуацией:
> Есть много разных виртуальных хостов, что висят на разных адресах у машины.
> Где-то указаны конкретные IP, где-то звездочка.
> При добавлении нового виртуального хоста иногда возникает ситуация, что
> запросы начинают обрабатываться другими хостами, т.е. меняется логика в
> обработке запросов.
> Пример конфига:
>
> server {
>      listen 8000;
>      server_name test1;
>
>      location / {
>          return 200 'responce from test1';
>      }
> }
>
> server {
>      listen 8000 default_server;
>      server_name test2;
>
>      location / {
>          return 200 'responce from test2!';
>      }
> }
>
> server {
>      listen 8000 ;
>      server_name test3;
>
>      location / {
>          return 200 'responce from test3!';
>      }
> }
>
> Тут все хорошо, запросы с заголовками test1,2,3 попадают в нужные хосты, без
> заголовков попадают в default
> но если указать у любого listen конкретный ip, например 127.0.0.1 то все
> запросы начинает обрабатывать именно он, игнорируя заголовки Host и
> default_server
>
> Чисто логически я понимаю, что у него приоритет ИП, но выглядит странно :)
> Есть какие-то практики в этом случае - только ИП везде или все без ИП?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284170,284170#msg-284170
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



From raven_kg на megaline.kg  Wed May 15 08:40:48 2019
From: raven_kg на megaline.kg (raven_kg на megaline.kg)
Date: Wed, 15 May 2019 14:40:48 +0600
Subject: =?UTF-8?Q?Re=3A_Listen_=D0=B8_default_server?=
In-Reply-To: <9e9eee60-62c1-47fb-7991-281a97fc3669@megaline.kg>
References: <71f450ed30ae529083bbaed23d3e8006.NginxMailingListRussian@forum.nginx.org>
 <9e9eee60-62c1-47fb-7991-281a97fc3669@megaline.kg>
Message-ID: <21a12fb7-f21f-7c81-ad1b-0eb0b823fb24@megaline.kg>

И да, 0.0.0.0:8000 и 127.0.0.1:8000 - это разные сокеты, соотв. если в 
запросе указан http://127.0.0.1:8000, то он не попадет в сокет другого 
IP, что бы там в Host не было передано. Так что тут нужно строить конфиг 
изначально с учетом этого нюансика)

15.05.2019 14:35, raven_kg на megaline.kg пишет:
> Где нужен конкретный IP - указывать IP, где нет - использовать 0.0.0.0
>
> 15.05.2019 14:32, ingtar пишет:
>> Столкнулся с такой ситуацией:
>> Есть много разных виртуальных хостов, что висят на разных адресах у 
>> машины.
>> Где-то указаны конкретные IP, где-то звездочка.
>> При добавлении нового виртуального хоста иногда возникает ситуация, что
>> запросы начинают обрабатываться другими хостами, т.е. меняется логика в
>> обработке запросов.
>> Пример конфига:
>>
>> server {
>>      listen 8000;
>>      server_name test1;
>>
>>      location / {
>>          return 200 'responce from test1';
>>      }
>> }
>>
>> server {
>>      listen 8000 default_server;
>>      server_name test2;
>>
>>      location / {
>>          return 200 'responce from test2!';
>>      }
>> }
>>
>> server {
>>      listen 8000 ;
>>      server_name test3;
>>
>>      location / {
>>          return 200 'responce from test3!';
>>      }
>> }
>>
>> Тут все хорошо, запросы с заголовками test1,2,3 попадают в нужные 
>> хосты, без
>> заголовков попадают в default
>> но если указать у любого listen конкретный ip, например 127.0.0.1 то все
>> запросы начинает обрабатывать именно он, игнорируя заголовки Host и
>> default_server
>>
>> Чисто логически я понимаю, что у него приоритет ИП, но выглядит 
>> странно :)
>> Есть какие-то практики в этом случае - только ИП везде или все без ИП?
>>
>> Posted at Nginx Forum: 
>> https://forum.nginx.org/read.php?21,284170,284170#msg-284170
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



From public-mail на alekciy.ru  Thu May 16 03:57:23 2019
From: public-mail на alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=)
Date: Thu, 16 May 2019 07:57:23 +0400
Subject: =?UTF-8?B?UmU6INCf0L7QtNC60LvRjtGH0LXQvdC40LUg0LogUmVkaXMg0YfQtdGA0LXQtyBu?=
 =?UTF-8?B?Z2lueA==?=
In-Reply-To: <1745892d3663ec5c0382093b2a7df2ac.NginxMailingListRussian@forum.nginx.org>
References: <1745892d3663ec5c0382093b2a7df2ac.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAPP2NXpM3_Sy2sFtR_Zn_m9r08y9PWYAY4mp90zxKPLF-xyZWg@mail.gmail.com>

А зачем nginx должен удерживать соединение? Что ждёт клиент от этого
соединения.

сб, 20 апр. 2019 г., 12:16 RuslanValitov <nginx-forum на forum.nginx.org>:

> Добрый день уважаемые.
>
> Имеется:
> 1. Nginx + lua
> 2. redis 5.0
> 3. Внешнее приложение с redis клиентом
>
> Задача: подключить внешнее приложение к redis.
>
> Доступ на прямую по external_ip:6001 внешнему приложения давать не хочу,
> остается открыть соединение клиента с redis через nginx c предварительной
> аутентификацией.
>
> Как я это представляю:
> 1. Клиент запрашивает соединение на site.com/connect_to_redis
> 2. nginx по средствам lua проверяет логин и пароль и если все ОК, то
> происходит внутренний редирект с локейшена /connect_to_redis на
> local_ip:6001
> 3. nginx держит (не разрывает) соединение.
>
> Поправьте меня если я не верно представляю схему работы.
> Быть может кто предложит иную схему?
>
> Пока не представляю:
> 1. Как при попытке соединения внешнего клиента redis к redis server
> (находящегося за nginx) передать предварительно nginx логин и пароль что бы
> lua скрипт их проверил для создания внутреннего редиректа?
> 2. Как заставить nginx держать коннект до отключения redis клиента от
> сервера?
>
> Заранее премного вам благодарен.
> С уважением и наилучшими пожеланиями!
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,283863,283863#msg-283863
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190516/b70d8621/attachment.html>

From raven_kg на megaline.kg  Fri May 17 11:49:09 2019
From: raven_kg на megaline.kg (raven_kg на megaline.kg)
Date: Fri, 17 May 2019 17:49:09 +0600
Subject: =?UTF-8?B?c2lnbmVyIGNlcnRpZmljYXRlIG5vdCBmb3VuZCDQv9C+0YHQu9C1INC+0LHQvdC+?=
 =?UTF-8?B?0LLQu9C10L3QuNGP?=
Message-ID: <14d7477b-6ec2-3971-27d2-3745b1a5856c@megaline.kg>

Приветствую.

Обновил Nginx c 1.14 до 1.16, посыпались ошибки в лог

2019/05/17 11:22:50 [error] 2487#2487: OCSP_basic_verify() failed (SSL: 
error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not 
found) while requesting certificate status, responder: 
ocsp.int-x3.letsencrypt.org, peer: 2.21.33.128:80, certificate: 
"/etc/pki/letsencrypt/домен/fullchain.cer"
2019/05/17 11:33:46 [error] 2487#2487: OCSP_basic_verify() failed (SSL: 
error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not 
found) while requesting certificate status, responder: 
ocsp.int-x3.letsencrypt.org, peer: 23.203.249.34:80, certificate: 
"/etc/pki/letsencrypt/домен/fullchain.cer"

Сайты (их, к слову, куда больше чем один) при этом продолжают работать. 
fullchain.cer содержит и сертификат домена и промежуточный сертификат.

Откатываюсь обратно на 1.14.2 - ошибки пропадают. С чем может быть 
связано такое изменение поведения?

Часть конфига, ответственная за SSL:

     # SSL
     ssl_certificate_key /etc/pki/letsencrypt/домен/домен.key;
     ssl_certificate /etc/pki/letsencrypt/домен/fullchain.cer;
     ssl_stapling on;
     ssl_stapling_verify on;
     ssl_trusted_certificate /etc/pki/letsencrypt/домен/fullchain.cer;


P.S. Вот на такой обновляюсь:

    nginx version: nginx/1.16.0 (Custom)
    built with LibreSSL 2.9.1
    TLS SNI support enabled
    configure arguments: --build='Custom' --prefix=/usr/share/nginx
    --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules
    --conf-path=/etc/nginx/nginx.conf
    --error-log-path=/var/log/nginx/error_log
    --http-log-path=/var/log/nginx/access_log
    --http-client-body-temp-path=/var/lib/nginx/tmp/client_body
    --http-proxy-temp-path=/var/lib/nginx/tmp/proxy
    --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi
    --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
    --http-scgi-temp-path=/var/lib/nginx/tmp/scgi
    --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx
    --user=nginx --group=nginx --with-file-aio --with-threads
    --with-http_ssl_module --with-http_v2_module
    --with-http_v2_hpack_enc --with-http_realip_module
    --with-http_addition_module --with-http_xslt_module=dynamic
    --with-http_image_filter_module=dynamic
    --with-http_geoip_module=dynamic --with-http_sub_module
    --with-http_dav_module --with-http_flv_module --with-http_mp4_module
    --with-http_gunzip_module --with-http_gzip_static_module
    --with-http_random_index_module --with-http_secure_link_module
    --with-http_degradation_module --with-http_slice_module
    --with-http_stub_status_module --with-http_perl_module=dynamic
    --with-mail=dynamic --with-mail_ssl_module --with-pcre
    --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module
    --with-google_perftools_module --with-debug
    --add-dynamic-module=headers-more-nginx-module-0.33
    --add-dynamic-module=ngx_devel_kit-0.3.1rc1
    --add-dynamic-module=lua-nginx-module-0.10.15
    --add-dynamic-module=nginx-eval-module-master
    --add-dynamic-module=ngx_brotli --with-ld-opt='-L/opt/libressl/lib
    -Wl,-rpath=/opt/libressl/lib -lrt -lcrypto -lssl -ltls -Wl,-z,relro
    -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'
    --with-cc-opt='-DNGX_LUA_ABORT_AT_PANIC -I/opt/libressl/include -O2
    -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
    -fstack-protector-strong --param=ssp-buffer-size=4
    -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
    -m64 -mtune=generic -DTCP_FASTOPEN=23'

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

From mdounin на mdounin.ru  Fri May 17 12:50:12 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 17 May 2019 15:50:12 +0300
Subject: =?UTF-8?B?UmU6IHNpZ25lciBjZXJ0aWZpY2F0ZSBub3QgZm91bmQg0L/QvtGB0LvQtSDQvtCx?=
 =?UTF-8?B?0L3QvtCy0LvQtdC90LjRjw==?=
In-Reply-To: <14d7477b-6ec2-3971-27d2-3745b1a5856c@megaline.kg>
References: <14d7477b-6ec2-3971-27d2-3745b1a5856c@megaline.kg>
Message-ID: <20190517125011.GC1877@mdounin.ru>

Hello!

On Fri, May 17, 2019 at 05:49:09PM +0600, raven_kg на megaline.kg wrote:

> Приветствую.
> 
> Обновил Nginx c 1.14 до 1.16, посыпались ошибки в лог
> 
> 2019/05/17 11:22:50 [error] 2487#2487: OCSP_basic_verify() failed (SSL: 
> error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not 
> found) while requesting certificate status, responder: 
> ocsp.int-x3.letsencrypt.org, peer: 2.21.33.128:80, certificate: 
> "/etc/pki/letsencrypt/домен/fullchain.cer"
> 2019/05/17 11:33:46 [error] 2487#2487: OCSP_basic_verify() failed (SSL: 
> error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not 
> found) while requesting certificate status, responder: 
> ocsp.int-x3.letsencrypt.org, peer: 23.203.249.34:80, certificate: 
> "/etc/pki/letsencrypt/домен/fullchain.cer"
> 
> Сайты (их, к слову, куда больше чем один) при этом продолжают работать. 
> fullchain.cer содержит и сертификат домена и промежуточный сертификат.
> 
> Откатываюсь обратно на 1.14.2 - ошибки пропадают. С чем может быть 
> связано такое изменение поведения?

С вот этим:

>     built with LibreSSL 2.9.1

Подробности тут:

http://mailman.nginx.org/pipermail/nginx-ru/2019-May/062150.html
http://mailman.nginx.org/pipermail/nginx-devel/2019-May/012212.html

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

From raven_kg на megaline.kg  Mon May 20 08:31:12 2019
From: raven_kg на megaline.kg (raven_kg на megaline.kg)
Date: Mon, 20 May 2019 14:31:12 +0600
Subject: =?UTF-8?B?UmU6IHNpZ25lciBjZXJ0aWZpY2F0ZSBub3QgZm91bmQg0L/QvtGB0LvQtSDQvtCx?=
 =?UTF-8?B?0L3QvtCy0LvQtdC90LjRjw==?=
In-Reply-To: <20190517125011.GC1877@mdounin.ru>
References: <14d7477b-6ec2-3971-27d2-3745b1a5856c@megaline.kg>
 <20190517125011.GC1877@mdounin.ru>
Message-ID: <3e9d369a-517d-c211-4bed-16797b2cadc8@megaline.kg>

Благодарю, откат libressl до 2.8.3 решил проблему.

17.05.2019 18:50, Maxim Dounin пишет:
> Hello!
>
> On Fri, May 17, 2019 at 05:49:09PM +0600, raven_kg на megaline.kg wrote:
>
>> Приветствую.
>>
>> Обновил Nginx c 1.14 до 1.16, посыпались ошибки в лог
>>
>> 2019/05/17 11:22:50 [error] 2487#2487: OCSP_basic_verify() failed (SSL:
>> error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not
>> found) while requesting certificate status, responder:
>> ocsp.int-x3.letsencrypt.org, peer: 2.21.33.128:80, certificate:
>> "/etc/pki/letsencrypt/домен/fullchain.cer"
>> 2019/05/17 11:33:46 [error] 2487#2487: OCSP_basic_verify() failed (SSL:
>> error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not
>> found) while requesting certificate status, responder:
>> ocsp.int-x3.letsencrypt.org, peer: 23.203.249.34:80, certificate:
>> "/etc/pki/letsencrypt/домен/fullchain.cer"
>>
>> Сайты (их, к слову, куда больше чем один) при этом продолжают работать.
>> fullchain.cer содержит и сертификат домена и промежуточный сертификат.
>>
>> Откатываюсь обратно на 1.14.2 - ошибки пропадают. С чем может быть
>> связано такое изменение поведения?
> С вот этим:
>
>>      built with LibreSSL 2.9.1
> Подробности тут:
>
> http://mailman.nginx.org/pipermail/nginx-ru/2019-May/062150.html
> http://mailman.nginx.org/pipermail/nginx-devel/2019-May/012212.html
>


From nginx-forum на forum.nginx.org  Tue May 21 09:20:12 2019
From: nginx-forum на forum.nginx.org (medved)
Date: Tue, 21 May 2019 05:20:12 -0400
Subject: =?UTF-8?B?0J/RgNC+0YHRgtC10LnRiNC40Lkg0L/RgNC40LzQtdGAINC/0YDQvtC60YHQuA==?=
Message-ID: <e1bfcd38459427ef50adfa0f7875b085.NginxMailingListRussian@forum.nginx.org>

Здравствуйте. Без году неделя как знаком с nginx :-) Не могу понять куда
копать, чтобы нормально сконфигурировать его как простейший прокси.

К примеру, даны два сервера, оба Ubuntu 18.04:
- front (ip 1.1.1.1)
- back (ip 2.2.2.2)
На front установлен nginx, на back установлены apache + php.

1. В конфиге apache ( /etc/apache2/ports.conf ) меняю порт на 81,
перезапускаю службу apache и по адресу http://2.2.2.2:81 открывается
стартовая страничка apache

2. В конфиге nginx ( /etc/nginx/nginx.conf ) в секцию http добавляю строку
 proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:32m
max_size=1g;

3. В файле /etc/nginx/sites-enabled/default в location добавляю
 proxy_pass http://2.2.2.2:81/;
и перезапускаю службу nginx

4. По адресу http://1.1.1.1 теперь открывается стартовая страничка apache,
которая на самом деле висит на http://2.2.2.2:81

Все хорошо, но отдается только текстовый контент, без рисунков. То есть,
логотип Ubuntu на дефолтной страничке Apache не грузится. 
Файл http://2.2.2.2:81/icons/ubuntu-logo.png открывается.
Файл http://1.1.1.1/icons/ubuntu-logo.png - 404.

То же самое, если я создам, например, файл info.php с содержимым

<?php
phpinfo();
?>

по адресу http://2.2.2.2:81/info.php он будет открываться, а по адресу
http://1.1.1.1/info.php будет 404.

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


From nginx-forum на forum.nginx.org  Tue May 21 09:58:08 2019
From: nginx-forum на forum.nginx.org (medved)
Date: Tue, 21 May 2019 05:58:08 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtGB0YLQtdC50YjQuNC5INC/0YDQuNC80LXRgCDQv9GA0L7QutGB?=
 =?UTF-8?B?0Lg=?=
In-Reply-To: <e1bfcd38459427ef50adfa0f7875b085.NginxMailingListRussian@forum.nginx.org>
References: <e1bfcd38459427ef50adfa0f7875b085.NginxMailingListRussian@forum.nginx.org>
Message-ID: <d0b764cd68ddc12bb6ff4554320fedbe.NginxMailingListRussian@forum.nginx.org>

В файле /etc/nginx/sites-enabled/default в location также добавил

                proxy_cache all;
                proxy_cache_valid any 1h;

Не помогло...

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


From raven_kg на megaline.kg  Tue May 21 10:01:16 2019
From: raven_kg на megaline.kg (raven_kg на megaline.kg)
Date: Tue, 21 May 2019 16:01:16 +0600
Subject: =?UTF-8?B?UmU6INCf0YDQvtGB0YLQtdC50YjQuNC5INC/0YDQuNC80LXRgCDQv9GA0L7QutGB?=
 =?UTF-8?B?0Lg=?=
In-Reply-To: <d0b764cd68ddc12bb6ff4554320fedbe.NginxMailingListRussian@forum.nginx.org>
References: <e1bfcd38459427ef50adfa0f7875b085.NginxMailingListRussian@forum.nginx.org>
 <d0b764cd68ddc12bb6ff4554320fedbe.NginxMailingListRussian@forum.nginx.org>
Message-ID: <6ec30da7-9867-9692-7a9f-5a061d06c089@megaline.kg>

что-то мне подсказывает, что где-то нужен try_files $uri $uri @apache; и 
сам @apache описать
21.05.2019 15:58, medved пишет:
> В файле /etc/nginx/sites-enabled/default в location также добавил
>
>                  proxy_cache all;
>                  proxy_cache_valid any 1h;
>
> Не помогло...
>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284227,284228#msg-284228
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



From nginx-forum на forum.nginx.org  Tue May 21 10:17:34 2019
From: nginx-forum на forum.nginx.org (medved)
Date: Tue, 21 May 2019 06:17:34 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtGB0YLQtdC50YjQuNC5INC/0YDQuNC80LXRgCDQv9GA0L7QutGB?=
 =?UTF-8?B?0Lg=?=
In-Reply-To: <6ec30da7-9867-9692-7a9f-5a061d06c089@megaline.kg>
References: <6ec30da7-9867-9692-7a9f-5a061d06c089@megaline.kg>
Message-ID: <ceb66fcd3b30ed98998182e31c661bc4.NginxMailingListRussian@forum.nginx.org>

Больше спасибо, как только закомментировал в
/etc/nginx/sites-enabled/default строку 
# try_files $uri $uri/ =404;
так все заработало, как ожидалось.

PS
Понятно, что так делать не надо и что надо копать в сторону try_files

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


From kpoxa на kpoxa.net  Tue May 21 13:31:46 2019
From: kpoxa на kpoxa.net (kpoxa)
Date: Tue, 21 May 2019 16:31:46 +0300
Subject: =?UTF-8?B?0J3QtdC80L3QvtCz0L4g0L/RgNC+INC70L7Qs9C40LrRgyDQutC10YjQsA==?=
Message-ID: <CABL5twAYQeXeBz0Tf4ccab5sF2LH6997O3SNtA9h=vYyL9tOHg@mail.gmail.com>

Добрый день.

Есть некоторые директивы, про которые не совсем понятно, как они работают
вместе, в частности у proxy_cache_path есть параметр inactive, который
задаёт время жизни файла в кеше, считая с последнего обращения. А еще есть
директива proxy_cache_valid, судя по описанию которой, которая тоже
отвечает за что-то подобное, обозванное временем кеширования.

И в связи с этим у меня вопрос:
как мне настроить кеш так, чтобы 302 редиректы кешировались на 15 секунд?
При настройках inactive=7d никакие варианты прописать proxy_cache_valid 302
15s не работают, в кеше куча вчерашних редиректов.
И второй вопрос - при каких условиях и как работает proxy_cache_valid ?
Пока что у меня не сходятся реальное поведение с документацией.

---
Рустам
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190521/ea1b6b5e/attachment.html>

From mdounin на mdounin.ru  Tue May 21 14:22:25 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 21 May 2019 17:22:25 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQvNC90L7Qs9C+INC/0YDQviDQu9C+0LPQuNC60YMg0LrQtdGI0LA=?=
In-Reply-To: <CABL5twAYQeXeBz0Tf4ccab5sF2LH6997O3SNtA9h=vYyL9tOHg@mail.gmail.com>
References: <CABL5twAYQeXeBz0Tf4ccab5sF2LH6997O3SNtA9h=vYyL9tOHg@mail.gmail.com>
Message-ID: <20190521142225.GL1877@mdounin.ru>

Hello!

On Tue, May 21, 2019 at 04:31:46PM +0300, kpoxa wrote:

> Есть некоторые директивы, про которые не совсем понятно, как они работают
> вместе, в частности у proxy_cache_path есть параметр inactive, который
> задаёт время жизни файла в кеше, считая с последнего обращения. А еще есть
> директива proxy_cache_valid, судя по описанию которой, которая тоже
> отвечает за что-то подобное, обозванное временем кеширования.
> 
> И в связи с этим у меня вопрос:
> как мне настроить кеш так, чтобы 302 редиректы кешировались на 15 секунд?
> При настройках inactive=7d никакие варианты прописать proxy_cache_valid 302
> 15s не работают, в кеше куча вчерашних редиректов.
> И второй вопрос - при каких условиях и как работает proxy_cache_valid ?
> Пока что у меня не сходятся реальное поведение с документацией.

Директива proxy_cache_valid - определяет, сколько времени ответ в 
кэше будет считаться валидным, то есть пригодным для возврата 
клиенту.  Используется, если клиент не вернул явного указания 
через Cache-Control/Expires/X-Accel-Expires (или они 
проигнорированы в соответствии с proxy_ignore_headers).

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

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

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

From mdounin на mdounin.ru  Tue May 21 14:39:41 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 21 May 2019 17:39:41 +0300
Subject: nginx-1.17.0
Message-ID: <20190521143941.GO1877@mdounin.ru>

Изменения в nginx 1.17.0                                          21.05.2019

    *) Добавление: директивы limit_rate и limit_rate_after поддерживают
       переменные.

    *) Добавление: директивы proxy_upload_rate и proxy_download_rate в
       модуле stream поддерживают переменные.

    *) Изменение: минимальная поддерживаемая версия OpenSSL - 0.9.8.

    *) Изменение: теперь postpone-фильтр собирается всегда.

    *) Исправление: директива include не работала в блоках if и
       limit_except.

    *) Исправление: в обработке byte ranges.


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

From nginx-forum на forum.nginx.org  Wed May 22 12:25:36 2019
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 22 May 2019 08:25:36 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDRgdGC0LDRgtC40LrRgyDQsiDRgNC10LY=?=
 =?UTF-8?B?0LjQvNC1IFNTTCDQsiAyLTMg0YDQsNC30LAg0LzQtdC00LvQtdC90LXQtQ==?=
In-Reply-To: <a953b9ddb53dd0777eac1055ce7ac4df.NginxMailingListRussian@forum.nginx.org>
References: <a953b9ddb53dd0777eac1055ce7ac4df.NginxMailingListRussian@forum.nginx.org>
Message-ID: <c2f3f47c6a6a9a8b0df96414c49793e8.NginxMailingListRussian@forum.nginx.org>

Дело похоже не в nginx. Сделал сертификат на 2048 бит - особой разницы нет.
Заменил nginx на lighthttp - в принципе тоже без изменений.

Сейчас больше склоняюсь в проблеме провайдера.

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


From kpoxa на kpoxa.net  Wed May 22 14:29:33 2019
From: kpoxa на kpoxa.net (kpoxa)
Date: Wed, 22 May 2019 17:29:33 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQvNC90L7Qs9C+INC/0YDQviDQu9C+0LPQuNC60YMg0LrQtdGI0LA=?=
In-Reply-To: <20190521142225.GL1877@mdounin.ru>
References: <CABL5twAYQeXeBz0Tf4ccab5sF2LH6997O3SNtA9h=vYyL9tOHg@mail.gmail.com>
 <20190521142225.GL1877@mdounin.ru>
Message-ID: <CABL5twDWRqX1Qx87xLR7rZ2yRG=7TAfXH_fC7LodDXp0ChqJ-A@mail.gmail.com>

Добрый день.

Что-то у меня не сходится, не понимаю:

Запрос в 22/May/2019:17:15:43
Файл элемента кеша создан  May 18 12:46
inactive=1d
ответ 302
proxy_cache_valid         301 302 404 15s;

Более подробно:


В логе запрос с попаданием в кеш

[22/May/2019:17:15:43 +0300] "/s13/27/public_pin_l/241/2352410650.jpg"
ip=15.85.172.17 status=302 size=0 upTime=- upstream_addr=-
upstream_status=- request_time=0.000 cache=HIT ref="-" http

Вычисляем файл кеша:

echo -n /s13/27/public_pin_l/241/2352410650.jpg | md5sum
044e2e2e9226a8f10d25d480a49d2000

Вот он

-rw------- 1 www-data www-data 684 May 18 12:46
044e2e2e9226a8f10d25d480a49d2000

Содержит он


cat 044e2e2e9226a8f10d25d480a49d2000
ђa]яяяяяяяяђФЯ\ТYЁK~¬
KEY: /s13/27/public_pin_l/241/2352410650.jpg
HTTP/1.1 302 Found
Server: nginx/1.15.8
Date: Sat, 18 May 2019 09:46:56 GMT
Content-Length: 0
Connection: close
Cache-Control: max-age=2592000
Expires: Mon, 17 Jun 2019 09:46:56 GMT
Location: /s107/797257fdf5bc88f5/2352410650.jpg
Pragma: no-cache
X-Powered: iconv
Content-Type: image/jpeg

Конфиг вот такой:

user  www-data;
worker_processes  auto;
worker_rlimit_nofile 160000;
thread_pool pool_1 threads=128;
thread_pool pool_2 threads=128;
error_log   /var/log/nginx/error.log warn;
events {
    worker_connections  150000;
    use epoll;
}
http {
    server_tokens off;
    include       mime.types;
    default_type  application/octet-stream;
    log_format  stat        '[$time_local] "$request_uri" ip=$remote_addr
status=$status size=$body_bytes_sent upTime=$upstream_response_time
upstream_addr=$upstream_addr upstream_status=$upstream_status'
                            ' request_time=$request_time
cache=$upstream_cache_status ref="$http_referer" $scheme $http2';
    log_not_found       off;
    sendfile       on;
    tcp_nopush     on;
    keepalive_timeout  300;
    gzip  off;
    reset_timedout_connection on;
    client_body_buffer_size 128k;
    client_max_body_size    20m;
    open_file_cache          max=10000 inactive=5m;
    open_file_cache_valid    2m;
    open_file_cache_min_uses 1;
    open_file_cache_errors   on;
    proxy_temp_path           /run/shm;
    proxy_cache_key           $uri$is_args$args;
    proxy_cache_valid         200 30d;
    proxy_cache_valid         301 302 404 15s;
    proxy_cache_lock          off;
    proxy_cache_use_stale     error timeout invalid_header http_500
http_502 http_503 http_504 http_404;
    proxy_redirect            off;
    recursive_error_pages     on;
    proxy_buffers             16 16k;
    proxy_buffer_size         64k;
    proxy_ignore_client_abort off;
    proxy_intercept_errors    on;
    proxy_next_upstream       error timeout invalid_header http_500
http_502 http_503 http_504 http_404;
    proxy_set_header          Host                $host;
    proxy_set_header          X-Real-IP           $remote_addr;
    proxy_set_header          X-Forwarded-For
$proxy_add_x_forwarded_for;
    proxy_max_temp_file_size  0;
    include upstream/upstream_cache.conf;
    include upstream/upstream_storage.conf;
    include upstream/all_in_one_storage_upstream.conf;
    include nginx.ssl.conf;
    proxy_cache_path /ssd     levels=1:2 keys_zone=ssd1:2000m
max_size=175000m inactive=1d loader_files=1000 use_temp_path=off;
    proxy_cache_path /ssd2    levels=1:2 keys_zone=ssd2:2000m
max_size=205000m inactive=1d loader_files=1000 use_temp_path=off;
    split_clients $uri$is_args$args $disk {
        56.3%     2;
        *         1;
    }

    aio threads=pool_$disk;
    proxy_cache ssd$disk;
    server {
        server_name             8.local.net;
        listen                  80  backlog=102400          default;
        listen                  443 backlog=102400 ssl http2 default;
        root /etc/nginx/html;
        access_log /var/log/nginx/access_basic.log stat;
        location / {
            try_files $uri @to_neighbor;
        }
        location = /error404.html {
            return 404 "No such file";
        }
        location @to_neighbor {
            internal;
            access_log  /var/log/nginx/access_full.log stat;
            proxy_pass  http://cache_$real_host;
            error_page 400 /error404.html;
            error_page 404 = @to_storage;
            error_page 502 = @to_storage;
            error_page 504 = @to_storage;
            error_page 503 = @to_storage;
        }
        location @to_storage {
            if ( $request_method = PURGE ) { return 200; }
            internal;
            access_log  /var/log/nginx/access_full.log stat;
            access_log  /var/log/nginx/access_stat.log stat if=$do_log;
            include logs.inc;
            proxy_pass  http://all-storages;
            error_page 400 /error404.html;
        }
    }
} # end of http




вт, 21 мая 2019 г. в 17:22, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, May 21, 2019 at 04:31:46PM +0300, kpoxa wrote:
>
> > Есть некоторые директивы, про которые не совсем понятно, как они работают
> > вместе, в частности у proxy_cache_path есть параметр inactive, который
> > задаёт время жизни файла в кеше, считая с последнего обращения. А еще
> есть
> > директива proxy_cache_valid, судя по описанию которой, которая тоже
> > отвечает за что-то подобное, обозванное временем кеширования.
> >
> > И в связи с этим у меня вопрос:
> > как мне настроить кеш так, чтобы 302 редиректы кешировались на 15 секунд?
> > При настройках inactive=7d никакие варианты прописать proxy_cache_valid
> 302
> > 15s не работают, в кеше куча вчерашних редиректов.
> > И второй вопрос - при каких условиях и как работает proxy_cache_valid ?
> > Пока что у меня не сходятся реальное поведение с документацией.
>
> Директива proxy_cache_valid - определяет, сколько времени ответ в
> кэше будет считаться валидным, то есть пригодным для возврата
> клиенту.  Используется, если клиент не вернул явного указания
> через Cache-Control/Expires/X-Accel-Expires (или они
> проигнорированы в соответствии с proxy_ignore_headers).
>
> Параметр inactive директивы proxy_cache_path - определяет, сколько
> времени ответ, возможно уже устаревший, будет хранится в кэше
> после последнего обращения.  Этот параметр - используется в первую
> очередь для управления размером кэша на диске.
>
> Когда inactive больше valid - в кэше будут храниться устаревшие
> ответы.  Такие ответы в норме не возвращаются клиентам, но могут
> быть использованы, скажем, в случае ошибок, с помощью директивы
> proxy_cache_use_stale.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190522/49ecad78/attachment-0001.html>

From mdounin на mdounin.ru  Wed May 22 15:12:37 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 22 May 2019 18:12:37 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQvNC90L7Qs9C+INC/0YDQviDQu9C+0LPQuNC60YMg0LrQtdGI0LA=?=
In-Reply-To: <CABL5twDWRqX1Qx87xLR7rZ2yRG=7TAfXH_fC7LodDXp0ChqJ-A@mail.gmail.com>
References: <CABL5twAYQeXeBz0Tf4ccab5sF2LH6997O3SNtA9h=vYyL9tOHg@mail.gmail.com>
 <20190521142225.GL1877@mdounin.ru>
 <CABL5twDWRqX1Qx87xLR7rZ2yRG=7TAfXH_fC7LodDXp0ChqJ-A@mail.gmail.com>
Message-ID: <20190522151237.GX1877@mdounin.ru>

Hello!

On Wed, May 22, 2019 at 05:29:33PM +0300, kpoxa wrote:

> Что-то у меня не сходится, не понимаю:
> 
> Запрос в 22/May/2019:17:15:43
> Файл элемента кеша создан  May 18 12:46
> inactive=1d
> ответ 302
> proxy_cache_valid         301 302 404 15s;
> 
> Более подробно:
> 
> 
> В логе запрос с попаданием в кеш
> 
> [22/May/2019:17:15:43 +0300] "/s13/27/public_pin_l/241/2352410650.jpg"
> ip=15.85.172.17 status=302 size=0 upTime=- upstream_addr=-
> upstream_status=- request_time=0.000 cache=HIT ref="-" http
> 
> Вычисляем файл кеша:
> 
> echo -n /s13/27/public_pin_l/241/2352410650.jpg | md5sum
> 044e2e2e9226a8f10d25d480a49d2000
> 
> Вот он
> 
> -rw------- 1 www-data www-data 684 May 18 12:46
> 044e2e2e9226a8f10d25d480a49d2000
> 
> Содержит он
> 
> 
> cat 044e2e2e9226a8f10d25d480a49d2000
> ђa]яяяяяяяяђФЯ\ТYЁK~¬
> KEY: /s13/27/public_pin_l/241/2352410650.jpg
> HTTP/1.1 302 Found
> Server: nginx/1.15.8
> Date: Sat, 18 May 2019 09:46:56 GMT
> Content-Length: 0
> Connection: close
> Cache-Control: max-age=2592000
> Expires: Mon, 17 Jun 2019 09:46:56 GMT
> Location: /s107/797257fdf5bc88f5/2352410650.jpg
> Pragma: no-cache
> X-Powered: iconv
> Content-Type: image/jpeg

И что именно не сходится?
Вроде никаких противоречий не просматривается.

В соответствии с заголовком Cache-Control - ответ валиден 30 дней, 
если его спрашивают хотя бы раз в сутки (inactive=1d) - эти 30 
дней он и будет лежать в кэше.

Указанное в директиве proxy_cache_valid время в данном случае не 
не используется, так как время валидности ответа явно указано в 
заголовках Cache-Control и Expires (и директивы 
proxy_ignore_headers в конфиге нет).

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

From identw на gmail.com  Thu May 23 10:10:28 2019
From: identw на gmail.com (Dmitry Sergeev)
Date: Thu, 23 May 2019 15:10:28 +0500
Subject: =?UTF-8?B?0JLQu9C40Y/QvdC40LUg0L3QsCDQv9GA0L7QuNC30LLQvtC00LjRgtC10LvRjNC9?=
 =?UTF-8?B?0L7RgdGC0Ywg0L/RgNC+0LLQtdGA0L7QuiDQvdCwINGB0YPRidC10YHRgtCy?=
 =?UTF-8?B?0L7QsNC90LjQtSDRhNCw0LnQu9CwICgtZikg0LIgcmV3cml0ZSDQvNC+0LQ=?=
 =?UTF-8?B?0YPQu9C1?=
Message-ID: <60f7de38-8d1f-8373-96c8-0b32cf7ed10f@gmail.com>

Всем привет. Не поделится ли кто-нибудь опытом, сильно ли может повлиять 
на произовдительность конструкция:

>      location / {
>          if (-f /var/www/maintenance_on.html) {
>              return 503;
>          }
>
>
>          ...
>      }
>
>
>      # Error pages.
>      error_page 503 /maintenance_on.html;
>      location = /maintenance_on.html {
>          root /var/www;
>      }
Например 7-10 location  с такими проверками на хосте 4K запросов в секунду?
На каждый запрос он будет проверять существование файла? Или как-то это 
делает по таймауту, который можно настроить?

-- 
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72

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

From mdounin на mdounin.ru  Thu May 23 12:43:53 2019
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 May 2019 15:43:53 +0300
Subject: =?UTF-8?B?UmU6INCS0LvQuNGP0L3QuNC1INC90LAg0L/RgNC+0LjQt9Cy0L7QtNC40YLQtdC7?=
 =?UTF-8?B?0YzQvdC+0YHRgtGMINC/0YDQvtCy0LXRgNC+0Log0L3QsCDRgdGD0YnQtdGB?=
 =?UTF-8?B?0YLQstC+0LDQvdC40LUg0YTQsNC50LvQsCAoLWYpINCyIHJld3JpdGUg0Lw=?=
 =?UTF-8?B?0L7QtNGD0LvQtQ==?=
In-Reply-To: <60f7de38-8d1f-8373-96c8-0b32cf7ed10f@gmail.com>
References: <60f7de38-8d1f-8373-96c8-0b32cf7ed10f@gmail.com>
Message-ID: <20190523124353.GA1877@mdounin.ru>

Hello!

On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote:

> Всем привет. Не поделится ли кто-нибудь опытом, сильно ли может повлиять 
> на произовдительность конструкция:
> 
> >      location / {
> >          if (-f /var/www/maintenance_on.html) {
> >              return 503;
> >          }
> >
> >
> >          ...
> >      }
> >
> >
> >      # Error pages.
> >      error_page 503 /maintenance_on.html;
> >      location = /maintenance_on.html {
> >          root /var/www;
> >      }
> Например 7-10 location  с такими проверками на хосте 4K запросов в секунду?
> На каждый запрос он будет проверять существование файла? Или как-то это 
> делает по таймауту, который можно настроить?

При такой конфигурации на каждый запрос[*] будет делаться 
системный вызов stat().  Скорее всего необходимые данные будут в 
кэше операционной системы, и этот системный вызов будет быстрым, 
так что на производительности это скажется минимально.

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

[*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а, 
чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache). 
Но практика показывает, что на производительность это влияет 
минимально, а вот выстрелить себе в ногу неатомарным изменением 
файлов станет легко.

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

From nginx-forum на forum.nginx.org  Fri May 24 06:38:42 2019
From: nginx-forum на forum.nginx.org (skeletor)
Date: Fri, 24 May 2019 02:38:42 -0400
Subject: =?UTF-8?Q?Re=3A_Listen_=D0=B8_default_server?=
In-Reply-To: <71f450ed30ae529083bbaed23d3e8006.NginxMailingListRussian@forum.nginx.org>
References: <71f450ed30ae529083bbaed23d3e8006.NginxMailingListRussian@forum.nginx.org>
Message-ID: <ed7fa74b4a0e44a4a6c789e646fa78ad.NginxMailingListRussian@forum.nginx.org>

Если кратко, то при указании в конфиге IP:PORT приоритет обработки будет у
этого конфига, нежели просто PORT или '*'. Если подробно то
http://nginx.org/ru/docs/http/request_processing.html

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


From vladget на gmail.com  Fri May 24 06:42:51 2019
From: vladget на gmail.com (Vladimir Getmanshchuk)
Date: Fri, 24 May 2019 09:42:51 +0300
Subject: =?UTF-8?B?UmU6INCS0LvQuNGP0L3QuNC1INC90LAg0L/RgNC+0LjQt9Cy0L7QtNC40YLQtdC7?=
 =?UTF-8?B?0YzQvdC+0YHRgtGMINC/0YDQvtCy0LXRgNC+0Log0L3QsCDRgdGD0YnQtdGB?=
 =?UTF-8?B?0YLQstC+0LDQvdC40LUg0YTQsNC50LvQsCAoLWYpINCyIHJld3JpdGUg0Lw=?=
 =?UTF-8?B?0L7QtNGD0LvQtQ==?=
In-Reply-To: <20190523124353.GA1877@mdounin.ru>
References: <60f7de38-8d1f-8373-96c8-0b32cf7ed10f@gmail.com>
 <20190523124353.GA1877@mdounin.ru>
Message-ID: <CAMxcU5+7w0WdKYO9rTUs4SjXzUVCK1rrYct=Yv5WDWNVBOVL2g@mail.gmail.com>

Кстати конструкцию можно сильно упростить через try_files
/maintenance_on.html ... ;

On Thu, May 23, 2019 at 3:44 PM Maxim Dounin <mdounin на mdounin.ru> wrote:

> Hello!
>
> On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote:
>
> > Всем привет. Не поделится ли кто-нибудь опытом, сильно ли может повлиять
> > на произовдительность конструкция:
> >
> > >      location / {
> > >          if (-f /var/www/maintenance_on.html) {
> > >              return 503;
> > >          }
> > >
> > >
> > >          ...
> > >      }
> > >
> > >
> > >      # Error pages.
> > >      error_page 503 /maintenance_on.html;
> > >      location = /maintenance_on.html {
> > >          root /var/www;
> > >      }
> > Например 7-10 location  с такими проверками на хосте 4K запросов в
> секунду?
> > На каждый запрос он будет проверять существование файла? Или как-то это
> > делает по таймауту, который можно настроить?
>
> При такой конфигурации на каждый запрос[*] будет делаться
> системный вызов stat().  Скорее всего необходимые данные будут в
> кэше операционной системы, и этот системный вызов будет быстрым,
> так что на производительности это скажется минимально.
>
> Так что если речь не идёт о борьбе за каждый процент - про
> производительность подобной конструкции можно не переживать.
> Другой вопрос, что сама по себе конструкция не очень, выкатку
> нужно уметь делать без перерывов в обслуживании.
>
> [*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а,
> чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache).
> Но практика показывает, что на производительность это влияет
> минимально, а вот выстрелить себе в ногу неатомарным изменением
> файлов станет легко.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



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

From dmitriy на lyalyuev.info  Fri May 24 07:06:12 2019
From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev)
Date: Fri, 24 May 2019 10:06:12 +0300
Subject: =?UTF-8?B?UmU6INCS0LvQuNGP0L3QuNC1INC90LAg0L/RgNC+0LjQt9Cy0L7QtNC40YLQtdC7?=
 =?UTF-8?B?0YzQvdC+0YHRgtGMINC/0YDQvtCy0LXRgNC+0Log0L3QsCDRgdGD0YnQtdGB?=
 =?UTF-8?B?0YLQstC+0LDQvdC40LUg0YTQsNC50LvQsCAoLWYpINCyIHJld3JpdGUg0Lw=?=
 =?UTF-8?B?0L7QtNGD0LvQtQ==?=
In-Reply-To: <CAMxcU5+7w0WdKYO9rTUs4SjXzUVCK1rrYct=Yv5WDWNVBOVL2g@mail.gmail.com>
References: <60f7de38-8d1f-8373-96c8-0b32cf7ed10f@gmail.com>
 <20190523124353.GA1877@mdounin.ru>
 <CAMxcU5+7w0WdKYO9rTUs4SjXzUVCK1rrYct=Yv5WDWNVBOVL2g@mail.gmail.com>
Message-ID: <29E83A1A-34E2-469D-AE96-C2DEB0C810DD@lyalyuev.info>

В этом случае код ответа будет 200, а не 503, как в условии.

> 24 мая 2019 г., в 09:42, Vladimir Getmanshchuk <vladget на gmail.com> написал(а):
> 
> Кстати конструкцию можно сильно упростить через try_files /maintenance_on.html ... ;
> 
> On Thu, May 23, 2019 at 3:44 PM Maxim Dounin <mdounin на mdounin.ru <mailto:mdounin на mdounin.ru>> wrote:
> Hello!
> 
> On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote:
> 
> > Всем привет. Не поделится ли кто-нибудь опытом, сильно ли может повлиять 
> > на произовдительность конструкция:
> > 
> > >      location / {
> > >          if (-f /var/www/maintenance_on.html) {
> > >              return 503;
> > >          }
> > >
> > >
> > >          ...
> > >      }
> > >
> > >
> > >      # Error pages.
> > >      error_page 503 /maintenance_on.html;
> > >      location = /maintenance_on.html {
> > >          root /var/www;
> > >      }
> > Например 7-10 location  с такими проверками на хосте 4K запросов в секунду?
> > На каждый запрос он будет проверять существование файла? Или как-то это 
> > делает по таймауту, который можно настроить?
> 
> При такой конфигурации на каждый запрос[*] будет делаться 
> системный вызов stat().  Скорее всего необходимые данные будут в 
> кэше операционной системы, и этот системный вызов будет быстрым, 
> так что на производительности это скажется минимально.
> 
> Так что если речь не идёт о борьбе за каждый процент - про 
> производительность подобной конструкции можно не переживать.  
> Другой вопрос, что сама по себе конструкция не очень, выкатку 
> нужно уметь делать без перерывов в обслуживании.
> 
> [*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а, 
> чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache <http://nginx.org/r/open_file_cache>). 
> Но практика показывает, что на производительность это влияет 
> минимально, а вот выстрелить себе в ногу неатомарным изменением 
> файлов станет легко.
> 
> -- 
> Maxim Dounin
> http://mdounin.ru/ <http://mdounin.ru/>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
> 
> -- 
> Yours sincerely,
> Vladimir Getmanshchuk
> _______________________________________________
> 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/20190524/7b944c3a/attachment-0001.html>
----------- следущая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: smime.p7s
Тип: application/pkcs7-signature
Размер: 3884 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190524/7b944c3a/attachment-0001.bin>

From nginx-forum на forum.nginx.org  Fri May 24 13:19:14 2019
From: nginx-forum на forum.nginx.org (kron)
Date: Fri, 24 May 2019 09:19:14 -0400
Subject: proxy_pass to variable and upstream server temporarily disabled
 variable
Message-ID: <72182da8a457b1fc61af341143b81361.NginxMailingListRussian@forum.nginx.org>

Доброго дня!

nginx: 1.15.8

Конфигурация простая (конечно она сильно шире, но в качестве бэкенда сейчас
действительно один сервер задается через переменную):

split_clients "${remote_addr}${cookie_uid}" $backend {
  * "backend1.eu-central-1.elb.amazonaws.com";
}


server {
  listen 80;

  location / {
		proxy_pass http://$backend;
  }
}

Столкнулся с интересной проблемой. В один момент у меня перестали идти
запросы на бэкенд, но быстро запросы восстановились. Поискал в логах, в
итоге нашел такие ошибки:

2019/05/24 08:40:26 [warn] 308#308: *1978088914 upstream server temporarily
disabled while reading response header from upstream, client: x.x.x.x,
server: xxxx, request: "GET / HTTP/1.1", upstream: "http://x.x.x.x:80/",
host: "xxxx"

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

Есть какая то неявная логика в такой обработке?

Благодарю!

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


From pluknet на nginx.com  Fri May 24 15:26:38 2019
From: pluknet на nginx.com (Sergey Kandaurov)
Date: Fri, 24 May 2019 18:26:38 +0300
Subject: proxy_pass to variable and upstream server temporarily disabled
 variable
In-Reply-To: <72182da8a457b1fc61af341143b81361.NginxMailingListRussian@forum.nginx.org>
References: <72182da8a457b1fc61af341143b81361.NginxMailingListRussian@forum.nginx.org>
Message-ID: <681DB322-92CF-4261-AC07-7EF14A00A617@nginx.com>


> On 24 May 2019, at 16:19, kron <nginx-forum на forum.nginx.org> wrote:
> 
> Доброго дня!
> 
> nginx: 1.15.8
> 
> Конфигурация простая (конечно она сильно шире, но в качестве бэкенда сейчас
> действительно один сервер задается через переменную):
> 
> split_clients "${remote_addr}${cookie_uid}" $backend {
>  * "backend1.eu-central-1.elb.amazonaws.com";
> }
> 
> 
> server {
>  listen 80;
> 
>  location / {
> 		proxy_pass http://$backend;
>  }
> }
> 
> Столкнулся с интересной проблемой. В один момент у меня перестали идти
> запросы на бэкенд, но быстро запросы восстановились. Поискал в логах, в
> итоге нашел такие ошибки:
> 
> 2019/05/24 08:40:26 [warn] 308#308: *1978088914 upstream server temporarily
> disabled while reading response header from upstream, client: x.x.x.x,
> server: xxxx, request: "GET / HTTP/1.1", upstream: "http://x.x.x.x:80/",
> host: "xxxx"
> 

Если апстрим с именем, в которое вычислилась переменная в proxy_pass
(как в примере выше), не описан явно или неявно, и потому используется
resolver (так это или нет - неясно из-за неполноты примера), то ошибка
возможна, если вычисленное имя порезолвилось в несколько адресов
и выбранный среди них сервер оказался неработоспособным.

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

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

-- 
Sergey Kandaurov


From identw на gmail.com  Fri May 24 17:07:31 2019
From: identw на gmail.com (Dmitry Sergeev)
Date: Fri, 24 May 2019 22:07:31 +0500
Subject: =?UTF-8?B?UmU6INCS0LvQuNGP0L3QuNC1INC90LAg0L/RgNC+0LjQt9Cy0L7QtNC40YLQtdC7?=
 =?UTF-8?B?0YzQvdC+0YHRgtGMINC/0YDQvtCy0LXRgNC+0Log0L3QsCDRgdGD0YnQtdGB?=
 =?UTF-8?B?0YLQstC+0LDQvdC40LUg0YTQsNC50LvQsCAoLWYpINCyIHJld3JpdGUg0Lw=?=
 =?UTF-8?B?0L7QtNGD0LvQtQ==?=
In-Reply-To: <20190523124353.GA1877@mdounin.ru>
References: <60f7de38-8d1f-8373-96c8-0b32cf7ed10f@gmail.com>
 <20190523124353.GA1877@mdounin.ru>
Message-ID: <67ca9d6b-de31-546b-5cf3-fc812df28f79@gmail.com>

Спасибо за ответ. К сожалению на выкатку без простоя я повлиять не могу. 
Флаг тех. работ во время деплоя всех устраивает, а вот поддержка в коде 
двух структур данных в бд (до миграции и после) не очень устраивает. 
Поэтому так живем.

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

Еще раз спасибо.

On 23/05/2019 17:43, Maxim Dounin wrote:
> Hello!
>
> On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote:
>
>
> При такой конфигурации на каждый запрос[*] будет делаться
> системный вызов stat().  Скорее всего необходимые данные будут в
> кэше операционной системы, и этот системный вызов будет быстрым,
> так что на производительности это скажется минимально.
>
> Так что если речь не идёт о борьбе за каждый процент - про
> производительность подобной конструкции можно не переживать.
> Другой вопрос, что сама по себе конструкция не очень, выкатку
> нужно уметь делать без перерывов в обслуживании.
>
> [*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а,
> чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache).
> Но практика показывает, что на производительность это влияет
> минимально, а вот выстрелить себе в ногу неатомарным изменением
> файлов станет легко.
>
-- 
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72


From nginx-forum на forum.nginx.org  Fri May 24 21:10:01 2019
From: nginx-forum на forum.nginx.org (vitcool)
Date: Fri, 24 May 2019 17:10:01 -0400
Subject: =?UTF-8?B?0JTQvtC80LXQvdGLIDMt0LPQviDRg9GA0L7QstC90Y8gLSBiZXN0IHByYWN0aWNl?=
 =?UTF-8?B?cw==?=
Message-ID: <1d7984bd633e77a2f4a8214b5ca31f48.NginxMailingListRussian@forum.nginx.org>

Добрый день.

Есть ли какие-либо примеры лучших практик на тему "как лучше организовать
обслуживание доменов 3-го уровня" при условии, что их количество будет не
более 20..30, максимум 40, включая основной www. ?

По факту все они должны вести на 1 апстрим, но в случае домена 3-го уровня,
нужно будет установить кастомный заголовок со значением равным этому домену
и подменить заголовок Host на основной. 

Доступ к коду бекенда есть, но весьма ограниченный. Эти 2 хидера бы спасли
ситуацию.

Что посоветуете? Пиковая нагрузка  порядка 50..75 RPS , ожидается рост до
100. С if-ми я так понимаю, нам не выжить.

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


From fe на hamilton.rinet.ru  Sat May 25 09:50:32 2019
From: fe на hamilton.rinet.ru (Fedor Dikarev)
Date: Sat, 25 May 2019 12:50:32 +0300
Subject: =?UTF-8?B?UmU6INCU0L7QvNC10L3RiyAzLdCz0L4g0YPRgNC+0LLQvdGPIC0gYmVzdCBwcmFj?=
 =?UTF-8?B?dGljZXM=?=
In-Reply-To: <1d7984bd633e77a2f4a8214b5ca31f48.NginxMailingListRussian@forum.nginx.org>
References: <1d7984bd633e77a2f4a8214b5ca31f48.NginxMailingListRussian@forum.nginx.org>
Message-ID: <96f42e36-28e1-2f30-b885-ef772f4222ab@hamilton.rinet.ru>

map $host $x_company_header {
	default default.example.com;
	www.example.com	"";
	sub1.example.com	sub1.example.com
	~ "^alt\d+.example.com"	$host;
}

server {
	listen 80;
	listen 443 ssl; # не забыть wildcard cert

	server_name example.com www.example.com *.example.com;

	location / {
		proxy_set_header Host "example.com";
		proxy_set_header X-Company-Header $x_company_header;
		proxy_pass http://upstream;
	}
}

вот как-то так.

25.05.2019 0:10, vitcool пишет:
> Добрый день.
> 
> Есть ли какие-либо примеры лучших практик на тему "как лучше организовать
> обслуживание доменов 3-го уровня" при условии, что их количество будет не
> более 20..30, максимум 40, включая основной www. ?
> 
> По факту все они должны вести на 1 апстрим, но в случае домена 3-го уровня,
> нужно будет установить кастомный заголовок со значением равным этому домену
> и подменить заголовок Host на основной. 
> 
> Доступ к коду бекенда есть, но весьма ограниченный. Эти 2 хидера бы спасли
> ситуацию.
> 
> Что посоветуете? Пиковая нагрузка  порядка 50..75 RPS , ожидается рост до
> 100. С if-ми я так понимаю, нам не выжить.
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284307,284307#msg-284307
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 

From nefer05 на gmail.com  Sat May 25 21:08:42 2019
From: nefer05 на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=)
Date: Sun, 26 May 2019 00:08:42 +0300
Subject: =?UTF-8?B?UmU6INCU0L7QvNC10L3RiyAzLdCz0L4g0YPRgNC+0LLQvdGPIC0gYmVzdCBwcmFj?=
 =?UTF-8?B?dGljZXM=?=
In-Reply-To: <96f42e36-28e1-2f30-b885-ef772f4222ab@hamilton.rinet.ru>
References: <1d7984bd633e77a2f4a8214b5ca31f48.NginxMailingListRussian@forum.nginx.org>
 <96f42e36-28e1-2f30-b885-ef772f4222ab@hamilton.rinet.ru>
Message-ID: <CAE-UrwhzZH2s_R_8Ry+cU9fnG7Y_0ER2J6D_asg2D7SzE=TzUQ@mail.gmail.com>

Сложно. Я бы сделал один серв с доменом второго уровня и второй серв дефолт
или *.domain. А в нем тупо установка двух заголовков. Проще, читабельней,
быстрее. ИМХО.

On Sat, May 25, 2019 at 12:50 PM Fedor Dikarev <fe на hamilton.rinet.ru> wrote:

> map $host $x_company_header {
>         default default.example.com;
>         www.example.com "";
>         sub1.example.com        sub1.example.com
>         ~ "^alt\d+.example.com" $host;
> }
>
> server {
>         listen 80;
>         listen 443 ssl; # не забыть wildcard cert
>
>         server_name example.com www.example.com *.example.com;
>
>         location / {
>                 proxy_set_header Host "example.com";
>                 proxy_set_header X-Company-Header $x_company_header;
>                 proxy_pass http://upstream;
>         }
> }
>
> вот как-то так.
>
> 25.05.2019 0:10, vitcool пишет:
> > Добрый день.
> >
> > Есть ли какие-либо примеры лучших практик на тему "как лучше организовать
> > обслуживание доменов 3-го уровня" при условии, что их количество будет не
> > более 20..30, максимум 40, включая основной www. ?
> >
> > По факту все они должны вести на 1 апстрим, но в случае домена 3-го
> уровня,
> > нужно будет установить кастомный заголовок со значением равным этому
> домену
> > и подменить заголовок Host на основной.
> >
> > Доступ к коду бекенда есть, но весьма ограниченный. Эти 2 хидера бы
> спасли
> > ситуацию.
> >
> > Что посоветуете? Пиковая нагрузка  порядка 50..75 RPS , ожидается рост до
> > 100. С if-ми я так понимаю, нам не выжить.
> >
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,284307,284307#msg-284307
> >
> > _______________________________________________
> > 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/20190526/f6d4ef03/attachment.html>

From nginx-forum на forum.nginx.org  Sat May 25 21:47:41 2019
From: nginx-forum на forum.nginx.org (vitcool)
Date: Sat, 25 May 2019 17:47:41 -0400
Subject: =?UTF-8?B?UmU6INCU0L7QvNC10L3RiyAzLdCz0L4g0YPRgNC+0LLQvdGPIC0gYmVzdCBwcmFj?=
 =?UTF-8?B?dGljZXM=?=
In-Reply-To: <96f42e36-28e1-2f30-b885-ef772f4222ab@hamilton.rinet.ru>
References: <96f42e36-28e1-2f30-b885-ef772f4222ab@hamilton.rinet.ru>
Message-ID: <7ea7a6373d7f040522cb8b71dcaec096.NginxMailingListRussian@forum.nginx.org>

А что то типа такого можно сделать? Кол-во сабдоменов не будет расти. Т.е.
есть готовый список, который готов обработать бекенд, все остальное он сам
отредиректит на www..... на специальный урл

map $host $subdomain_map {
........hostnames;
........default www;

........a000.example.com a000;
........a001.example.com a001;
........a010.example.com a010;
........a011.example.com a011;
........a100.example.com a100;
........a101.example.com a101;
........a110.example.com a110;
........a111.example.com a111;
...
    }

server {

........listen 443 ssl;  
........server_name $subdomain_map;

........location / {
................proxy_set_header Host "www.example.com";
................proxy_set_header X-Host-Subdomain $subdomain_map;
................proxy_pass http://upstream;
........}

...	
}

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


From identw на gmail.com  Sun May 26 10:13:01 2019
From: identw на gmail.com (Dmitry Sergeev)
Date: Sun, 26 May 2019 15:13:01 +0500
Subject: =?UTF-8?B?UmU6INCU0L7QvNC10L3RiyAzLdCz0L4g0YPRgNC+0LLQvdGPIC0gYmVzdCBwcmFj?=
 =?UTF-8?B?dGljZXM=?=
In-Reply-To: <7ea7a6373d7f040522cb8b71dcaec096.NginxMailingListRussian@forum.nginx.org>
References: <96f42e36-28e1-2f30-b885-ef772f4222ab@hamilton.rinet.ru>
 <7ea7a6373d7f040522cb8b71dcaec096.NginxMailingListRussian@forum.nginx.org>
Message-ID: <18411790-d51d-449f-9562-b608e31247c5@gmail.com>

Но зачем? Чем варианты предложенные раннее вас не устроили?

On 26/05/2019 02:47, vitcool wrote:
> А что то типа такого можно сделать? Кол-во сабдоменов не будет расти. Т.е.
> есть готовый список, который готов обработать бекенд, все остальное он сам
> отредиректит на www..... на специальный урл
>
> map $host $subdomain_map {
> ........hostnames;
> ........default www;
>
> ........a000.example.com a000;
> ........a001.example.com a001;
> ........a010.example.com a010;
> ........a011.example.com a011;
> ........a100.example.com a100;
> ........a101.example.com a101;
> ........a110.example.com a110;
> ........a111.example.com a111;
> ...
>      }
>
> server {
>
> ........listen 443 ssl;
> ........server_name $subdomain_map;
>
> ........location / {
> ................proxy_set_header Host "www.example.com";
> ................proxy_set_header X-Host-Subdomain $subdomain_map;
> ................proxy_pass http://upstream;
> ........}
>
> ...	
> }
>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284307,284317#msg-284317
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72


From chipitsine на gmail.com  Mon May 27 08:03:16 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 27 May 2019 13:03:16 +0500
Subject: nginx-1.17 + valgrind
Message-ID: <CAFHpkQErcxk+=xtKzXmEO0JDZvnXgpECzv8ww0u8WmdADPvNZw@mail.gmail.com>

привет!

изучаем утечки памяти. мешает вот такой шум

==5351== 2,160 bytes in 1 blocks are still reachable in loss record 1 of 2
==5351==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==5351==    by 0x157E01: ngx_strerror_init (in /usr/sbin/nginx-debug)
==5351==    by 0x1307FE: main (in /usr/sbin/nginx-debug)
==5351==
==5351== 3,030 bytes in 135 blocks are still reachable in loss record 2 of 2
==5351==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==5351==    by 0x157E66: ngx_strerror_init (in /usr/sbin/nginx-debug)
==5351==    by 0x1307FE: main (in /usr/sbin/nginx-debug)
==5351==
==5351== LEAK SUMMARY:
==5351==    definitely lost: 0 bytes in 0 blocks
==5351==    indirectly lost: 0 bytes in 0 blocks
==5351==      possibly lost: 0 bytes in 0 blocks
==5351==    still reachable: 5,190 bytes in 136 blocks
==5351==         suppressed: 0 bytes in 0 blocks
==5351==
==5351== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==5351== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[root на valgrind ~]#
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190527/df85dd12/attachment.html>

From nginx-forum на forum.nginx.org  Wed May 29 14:09:02 2019
From: nginx-forum на forum.nginx.org (Danila)
Date: Wed, 29 May 2019 10:09:02 -0400
Subject: If location
Message-ID: <3d16a27a4f9794cca2ab9d4961e0366a.NginxMailingListRussian@forum.nginx.org>

Добрый вечер!

Подскажите пожалуйста есть ли такая возможность и как ещё реализовать?
Задумка такая имеется Nginx 1.16 v расширенный 3 дополнительными модулями
nginx-auth-ldap nginx-dav-ext-module nginx-upload-module
При подключении (dav методом) пользователю предоставляется доступ к
каталогам, но нужно чтобы к определенным были права только на чтение или
вообще ни каких а для других полный доступ.

На пример  есть общий каталог ALL на который имеется полный доступ путем
dav_access user:rw group:rw all:rw;
В общем каталоге имеется подкаталоги пользователей:
Ivanov к этому каталогу имеет доступ только Ivanov ну хотя бы что бы другие
не удаляли ничего
Petrov к этом соответствено так же но для Petrov.
Если ставить условие на доступ к location ngix не принимает запись, как
можно сделать проверку?

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


From nginx-forum на forum.nginx.org  Thu May 30 07:51:38 2019
From: nginx-forum на forum.nginx.org (Danila)
Date: Thu, 30 May 2019 03:51:38 -0400
Subject: If location
In-Reply-To: <3d16a27a4f9794cca2ab9d4961e0366a.NginxMailingListRussian@forum.nginx.org>
References: <3d16a27a4f9794cca2ab9d4961e0366a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <744d5b367806bcf3f3a483b6512e920a.NginxMailingListRussian@forum.nginx.org>

Добрый вечер! 

Подскажите пожалуйста есть ли такая возможность и как ещё реализовать? 
Задумка такая имеется Nginx 1.16 v расширенный 3 дополнительными модулями
nginx-auth-ldap nginx-dav-ext-module nginx-upload-module 
При подключении (dav методом) пользователю предоставляется доступ к
каталогам, но нужно чтобы к определенным были права только на чтение или
вообще ни каких а для других полный доступ. 

На пример есть общий каталог ALL на который имеется полный доступ путем
dav_access user:rw group:rw all:rw; 
В общем каталоге имеется подкаталоги пользователей: 
Ivanov к этому каталогу имеет доступ только Ivanov ну хотя бы что бы другие
не удаляли ничего 
Petrov к этом соответствено так же но для Petrov. 
Если ставить условие на доступ к location ngix не принимает запись, как
можно сделать проверку?

Good evening!

Please tell me if there is such an opportunity and how else to implement?
This idea is available Nginx 1.16 v extended with 3 additional modules
nginx-auth-ldap nginx-dav-ext-module nginx-upload-module
When connecting (by dav method), the user is granted access to directories,
but it is necessary that certain have read-only rights or no access at all.

For example, there is a common directory ALL for which there is full access
by dav_access user: rw group: rw all: rw;
In the general directory there are subdirectories of users:
Ivanov has access to this directory only Ivanov well, at least so that
others would not delete anything
Petrov to this, respectively, as well but for Petrov.
If you set a condition for access to the location, ngix does not accept the
record, how can you make a check?

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


From vbart на nginx.com  Thu May 30 17:31:36 2019
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 30 May 2019 20:31:36 +0300
Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuOS4w?=
Message-ID: <2632802.ZtBez7UN1Q@vbart-workstation>

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

Рад сообщить о выпуске новой версии NGINX Unit.

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

Документация по новым возможностям:

- Правила сопоставления: https://unit.nginx.org/configuration/#condition-matching
- Операции в API: https://unit.nginx.org/configuration/#configuration-management

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

 - https://www.youtube.com/watch?v=5O4TjbbxTxw

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


Изменения в Unit 1.9.0                                          30.05.2019

   *) Добавление: маршрутизация запросов по аргументам, cookie и полям
      заголовка.

   *) Добавление: спецсимвол для частичного совпадения теперь можно
      использовать и в середине шаблонов сопоставления в маршрутах.

   *) Добавление: операция POST для добавления элементов в массивы в
      конфигурации.

   *) Добавление: поддержка смены пользователя и группы при помощи CAP_SETUID
      и CAP_SETGID в Linux без запуска главного процесса под привилегированным
      пользователем.

   *) Исправление: в процессе роутера могла возникать утечка памяти, если
      клиент преждевременно завершал соединение.

   *) Исправление: возможный сбой при применении конфигурации большого объема.

   *) Исправление: операции PUT и DELETE не работали на элементах массивов в
      конфигурации.

   *) Исправление: схема запроса в приложениях не отражала TLS-подключения.

   *) Исправление: восстановлена совместимость с приложениями Node.js,
      использующими функцию ServerResponse._implicitHeader(); ошибка появилась
      в версии 1.7.

   *) Исправление: различные проблемы совместимости с приложениями Node.js.


В этом выпуске также стали доступны пакеты для Ubuntu 19.04 "disco".
Полный список доступных репозиториев смотрите на нашем сайте:

 - https://unit.nginx.org/installation/

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

Работа над проксированием и отдачей статических файлов также ведется, но на
это уйдет больше времени.

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

 - https://www.nginx.com/careers/current-openings/

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

From mif на me.com  Fri May 31 10:47:20 2019
From: mif на me.com (Alexey Galygin)
Date: Fri, 31 May 2019 13:47:20 +0300
Subject: =?UTF-8?B?0JLQtdGH0L3Ri9C5IFVQREFUSU5HINC00LvRjyDRgNCw0L3QtNC+0LzQvdGL0YUg?=
 =?UTF-8?B?0YHRgtGA0LDQvdC40YYg0L/QvtGA0YLQsNC70LA=?=
In-Reply-To: <c1375914-309a-4496-a978-a30980b2694c@Spark>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
Message-ID: <db4a027e-3baa-471d-a615-78304ef1813b@Spark>

всем привет

ПРОБЛЕМА

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

см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)

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

КОНФИГУРАЦИЯ

релевантные настройки такие:

proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_lock on;
proxy_cache_lock_timeout 25s;

недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка кастомная):

nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI support enabled

при этом:

nginx -s reload # не помогает…

а помогает только явный «мягкий» перезапуск сервера (процедура похожая на обновление бинарника):

#!/usr/bin/env bash
# скрипт перезапуска или обновления бинарника:
sudo kill -s USR2 `cat /run/nginx.pid`
sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
echo 'waiting for 5 minutes required for graceful reload'
sleep 300
sudo kill -s TERM `cat /run/nginx.pid.oldbin`

ЛОГИ И ДЕМО

есть предположение, что это из-за эпозодического падения worker'ов (таких набирается несколько десятков за день, при сотнях тысяч запросов)

dmesg:

[4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
…

error.log:

2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 11 (core dumped)
…

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

наше предположение такое:

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

вот свежий пример (в заголовке x-ireland-cache-status выводим значение $upstream_cache_status):

H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:54:52 GMT
…
x-ireland-cache-status: UPDATING

… можно очень долго ждать – статус так и будет UPDATING …

H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:56:47 GMT
…
x-ireland-cache-status: UPDATING

после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён выше):

H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:57:37 GMT
…
x-ireland-cache-status: STALE

H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:57:39 GMT
…
x-ireland-cache-status: HIT

всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём следующего звоночка…

у нас нет инструмента по отслеживанию «застрявших UPDATING»,
и нет способа точечно их пнуть
(если только не отслеживать $upstream_cache_status по каждому ресурсу и переходы статусов со временем, которые в 99.99% переходят из UPDATING в правильные статусы);

приходится ждать только сигнала от недовольных пользователей…

РЕЗЮМИРУЕМ

ещё раз, сценарий, как мы видим откуда растёт проблема:

1. некоторая страница успешно кэшируется
2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)
3. никакой больше воркер это задание не получает до перезапуска nginx
4. недовольные клиенты получают устаревший контент

РЕШЕНИЕ?

перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.

какие варианты решения подобной проблемы существуют? в чём может быть возможная причина?

может есть рекомендации по дополнительным настройкам?

да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их (падения воркеров) надо учитывать в работе nginx:

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

From chipitsine на gmail.com  Fri May 31 11:48:06 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 31 May 2019 16:48:06 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
Message-ID: <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>

привет!

segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей
nginx.
 можете показать вывод "nginx -V" ?

как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
отладкой, при это не strip-нуть ее в момент инсталяции
команда "file `which nginx`" должна показыват "not stripped"

далее - в вашей операционной системе разрешаете сохранение core dump
(алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)

потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt
full", смотрите на чем именно упало.

если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))

пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <nginx-ru на nginx.org
>:

> всем привет
>
> ПРОБЛЕМА
>
> давно (уже не первый год обновление за обновлением nginx и OpenSSL)
> наблюдаем,
> что ряд страниц при обновлении кэша входят в вечный статус UPDATING
>
> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
>
> происходит это совершенно на рандомных страницах, и способа воспроизвести
> нет – только по прецедентной жалобе от пользователей, что закешированный
> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи
> всё в норму, но ждать до утра никто не хочет)
>
> КОНФИГУРАЦИЯ
>
> релевантные настройки такие:
>
> proxy_cache_use_stale error timeout invalid_header updating http_500
> http_502 http_503 http_504;
> proxy_cache_background_update on;
> proxy_cache_lock on;
> proxy_cache_lock_timeout 25s;
>
> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка
> кастомная):
>
> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI
> support enabled
>
> при этом:
>
> nginx -s reload # не помогает…
>
> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на
> обновление бинарника):
>
> #!/usr/bin/env bash
> # скрипт перезапуска или обновления бинарника:
> sudo kill -s USR2 `cat /run/nginx.pid`
> sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> echo 'waiting for 5 minutes required for graceful reload'
> sleep 300
> sudo kill -s TERM `cat /run/nginx.pid.oldbin`
>
> ЛОГИ И ДЕМО
>
> есть предположение, что это из-за эпозодического падения worker'ов (таких
> набирается несколько десятков за день, при сотнях тысяч запросов)
>
> dmesg:
>
> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp
> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> …
>
> error.log:
>
> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on
> signal 11 (core dumped)
> …
>
> подобные падения нас пресделуют много лет (их в день не много), на самых
> разных версиях nginx, в разных ДЦ, на разных серверах, при разных
> окружениях;
> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно
> падает…)
>
> наше предположение такое:
>
> воркер, который должен был обновить истёкшие данные умирает, а статус так
> и остаётся UPDATING (на вечно),
> всём клиентам отдаётся старый контент,
> а новые воркеры уже не планируют запрос обновления с бэка
>
> вот свежий пример (в заголовке x-ireland-cache-status выводим значение
> $upstream_cache_status):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:54:52 GMT
> …
> x-ireland-cache-status: UPDATING
>
> … можно очень долго ждать – статус так и будет UPDATING …
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:56:47 GMT
> …
> x-ireland-cache-status: UPDATING
>
> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был
> приведён выше):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:37 GMT
> …
> x-ireland-cache-status: STALE
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:39 GMT
> …
> x-ireland-cache-status: HIT
>
> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём
> следующего звоночка…
>
> у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> и нет способа точечно их пнуть
> (если только не отслеживать $upstream_cache_status по каждому ресурсу и
> переходы статусов со временем, которые в 99.99% переходят из UPDATING в
> правильные статусы);
>
> приходится ждать только сигнала от недовольных пользователей…
>
> РЕЗЮМИРУЕМ
>
> ещё раз, сценарий, как мы видим откуда растёт проблема:
>
> 1. некоторая страница успешно кэшируется
> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер
> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч
> запросов)
> 3. никакой больше воркер это задание не получает до перезапуска nginx
> 4. недовольные клиенты получают устаревший контент
>
> РЕШЕНИЕ?
>
> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
>
> какие варианты решения подобной проблемы существуют? в чём может быть
> возможная причина?
>
> может есть рекомендации по дополнительным настройкам?
>
> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но
> их (падения воркеров) надо учитывать в работе nginx:
>
> если это рассматривать как баг nginx – можно ли найти ему решение в
> будущих обновлениях, в виде отправки повторной задачи воркерам на
> обновление кэша, по таймауту?..
>
> _______________________________________________
> 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/20190531/1677a088/attachment.html>

From mif на me.com  Fri May 31 12:25:45 2019
From: mif на me.com (Alexey Galygin)
Date: Fri, 31 May 2019 15:25:45 +0300
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
Message-ID: <45b86231-c633-443d-ab30-6f12f59243a9@Spark>

Илья, модули все из коробки

ничего лишнего не доливаем

из экстрима, пожалуй, только perl-модуль для ряда мелких задачек

--with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug

--with-debug ещё добавил только что на время теста… и уровень отладки error_log включил debug
но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)

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


On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> привет!
>
> segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей nginx.
>  можете показать вывод "nginx -V" ?
>
> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с отладкой, при это не strip-нуть ее в момент инсталяции
> команда "file `which nginx`" должна показыват "not stripped"
>
> далее - в вашей операционной системе разрешаете сохранение core dump (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>
> потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt full", смотрите на чем именно упало.
>
> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>
> > пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <nginx-ru на nginx.org>:
> > > всем привет
> > >
> > > ПРОБЛЕМА
> > >
> > > давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,
> > > что ряд страниц при обновлении кэша входят в вечный статус UPDATING
> > >
> > > см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
> > >
> > > происходит это совершенно на рандомных страницах, и способа воспроизвести нет – только по прецедентной жалобе от пользователей, что закешированный контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи всё в норму, но ждать до утра никто не хочет)
> > >
> > > КОНФИГУРАЦИЯ
> > >
> > > релевантные настройки такие:
> > >
> > > proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
> > > proxy_cache_background_update on;
> > > proxy_cache_lock on;
> > > proxy_cache_lock_timeout 25s;
> > >
> > > недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка кастомная):
> > >
> > > nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI support enabled
> > >
> > > при этом:
> > >
> > > nginx -s reload # не помогает…
> > >
> > > а помогает только явный «мягкий» перезапуск сервера (процедура похожая на обновление бинарника):
> > >
> > > #!/usr/bin/env bash
> > > # скрипт перезапуска или обновления бинарника:
> > > sudo kill -s USR2 `cat /run/nginx.pid`
> > > sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> > > echo 'waiting for 5 minutes required for graceful reload'
> > > sleep 300
> > > sudo kill -s TERM `cat /run/nginx.pid.oldbin`
> > >
> > > ЛОГИ И ДЕМО
> > >
> > > есть предположение, что это из-за эпозодического падения worker'ов (таких набирается несколько десятков за день, при сотнях тысяч запросов)
> > >
> > > dmesg:
> > >
> > > [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> > > …
> > >
> > > error.log:
> > >
> > > 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 11 (core dumped)
> > > …
> > >
> > > подобные падения нас пресделуют много лет (их в день не много), на самых разных версиях nginx, в разных ДЦ, на разных серверах, при разных окружениях;
> > > (по хорошему, надо включить сбор корок и попытаться разобраться, где оно падает…)
> > >
> > > наше предположение такое:
> > >
> > > воркер, который должен был обновить истёкшие данные умирает, а статус так и остаётся UPDATING (на вечно),
> > > всём клиентам отдаётся старый контент,
> > > а новые воркеры уже не планируют запрос обновления с бэка
> > >
> > > вот свежий пример (в заголовке x-ireland-cache-status выводим значение $upstream_cache_status):
> > >
> > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > HTTP/2 200
> > > server: nginx
> > > date: Thu, 30 May 2019 14:54:52 GMT
> > > …
> > > x-ireland-cache-status: UPDATING
> > >
> > > … можно очень долго ждать – статус так и будет UPDATING …
> > >
> > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > HTTP/2 200
> > > server: nginx
> > > date: Thu, 30 May 2019 14:56:47 GMT
> > > …
> > > x-ireland-cache-status: UPDATING
> > >
> > > после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён выше):
> > >
> > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > HTTP/2 200
> > > server: nginx
> > > date: Thu, 30 May 2019 14:57:37 GMT
> > > …
> > > x-ireland-cache-status: STALE
> > >
> > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > HTTP/2 200
> > > server: nginx
> > > date: Thu, 30 May 2019 14:57:39 GMT
> > > …
> > > x-ireland-cache-status: HIT
> > >
> > > всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём следующего звоночка…
> > >
> > > у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> > > и нет способа точечно их пнуть
> > > (если только не отслеживать $upstream_cache_status по каждому ресурсу и переходы статусов со временем, которые в 99.99% переходят из UPDATING в правильные статусы);
> > >
> > > приходится ждать только сигнала от недовольных пользователей…
> > >
> > > РЕЗЮМИРУЕМ
> > >
> > > ещё раз, сценарий, как мы видим откуда растёт проблема:
> > >
> > > 1. некоторая страница успешно кэшируется
> > > 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)
> > > 3. никакой больше воркер это задание не получает до перезапуска nginx
> > > 4. недовольные клиенты получают устаревший контент
> > >
> > > РЕШЕНИЕ?
> > >
> > > перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
> > >
> > > какие варианты решения подобной проблемы существуют? в чём может быть возможная причина?
> > >
> > > может есть рекомендации по дополнительным настройкам?
> > >
> > > да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их (падения воркеров) надо учитывать в работе nginx:
> > >
> > > если это рассматривать как баг nginx – можно ли найти ему решение в будущих обновлениях, в виде отправки повторной задачи воркерам на обновление кэша, по таймауту?..
> > > _______________________________________________
> > > 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/20190531/42b52f1b/attachment-0001.html>

From chipitsine на gmail.com  Fri May 31 12:32:07 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 31 May 2019 17:32:07 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
Message-ID: <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>

В error_log ничего на сегфолте не может записаться, нет особого смысла его
включать в debug

По bt full больше инфы будет

On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:

> Илья, модули все из коробки
>
> ничего лишнего не доливаем
>
> из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
>
> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2'
> --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> --with-debug ещё добавил только что на время теста… и уровень отладки
> error_log включил debug
> но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
>
> корки сейчас включу и буду ловить
> но это ещё умудриться словить момент и дождаться, когда упадёт, может за
> час несколько раз свалится
>
>
> On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> привет!
>
> segfault - с очень-очень-очень большой вероятностью из-за сторонних
> модулей nginx.
>  можете показать вывод "nginx -V" ?
>
> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
> отладкой, при это не strip-нуть ее в момент инсталяции
> команда "file `which nginx`" должна показыват "not stripped"
>
> далее - в вашей операционной системе разрешаете сохранение core dump
> (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>
> потом, берете сохраненный core dump, при помощи gdb открываете, делаете
> "bt full", смотрите на чем именно упало.
>
> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>
> пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <
> nginx-ru на nginx.org>:
>
>> всем привет
>>
>> ПРОБЛЕМА
>>
>> давно (уже не первый год обновление за обновлением nginx и OpenSSL)
>> наблюдаем,
>> что ряд страниц при обновлении кэша входят в вечный статус UPDATING
>>
>> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
>>
>> происходит это совершенно на рандомных страницах, и способа воспроизвести
>> нет – только по прецедентной жалобе от пользователей, что закешированный
>> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи
>> всё в норму, но ждать до утра никто не хочет)
>>
>> КОНФИГУРАЦИЯ
>>
>> релевантные настройки такие:
>>
>> proxy_cache_use_stale error timeout invalid_header updating http_500
>> http_502 http_503 http_504;
>> proxy_cache_background_update on;
>> proxy_cache_lock on;
>> proxy_cache_lock_timeout 25s;
>>
>> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка
>> кастомная):
>>
>> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI
>> support enabled
>>
>> при этом:
>>
>> nginx -s reload # не помогает…
>>
>> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на
>> обновление бинарника):
>>
>> #!/usr/bin/env bash
>> # скрипт перезапуска или обновления бинарника:
>> sudo kill -s USR2 `cat /run/nginx.pid`
>> sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
>> echo 'waiting for 5 minutes required for graceful reload'
>> sleep 300
>> sudo kill -s TERM `cat /run/nginx.pid.oldbin`
>>
>> ЛОГИ И ДЕМО
>>
>> есть предположение, что это из-за эпозодического падения worker'ов (таких
>> набирается несколько десятков за день, при сотнях тысяч запросов)
>>
>> dmesg:
>>
>> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp
>> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
>> …
>>
>> error.log:
>>
>> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on
>> signal 11 (core dumped)
>> …
>>
>> подобные падения нас пресделуют много лет (их в день не много), на самых
>> разных версиях nginx, в разных ДЦ, на разных серверах, при разных
>> окружениях;
>> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно
>> падает…)
>>
>> наше предположение такое:
>>
>> воркер, который должен был обновить истёкшие данные умирает, а статус так
>> и остаётся UPDATING (на вечно),
>> всём клиентам отдаётся старый контент,
>> а новые воркеры уже не планируют запрос обновления с бэка
>>
>> вот свежий пример (в заголовке x-ireland-cache-status выводим значение
>> $upstream_cache_status):
>>
>> H27: ~ $ curl -I https://www.hse.ru/our/
>> HTTP/2 200
>> server: nginx
>> date: Thu, 30 May 2019 14:54:52 GMT
>> …
>> x-ireland-cache-status: UPDATING
>>
>> … можно очень долго ждать – статус так и будет UPDATING …
>>
>> H27: ~ $ curl -I https://www.hse.ru/our/
>> HTTP/2 200
>> server: nginx
>> date: Thu, 30 May 2019 14:56:47 GMT
>> …
>> x-ireland-cache-status: UPDATING
>>
>> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был
>> приведён выше):
>>
>> H27: ~ $ curl -I https://www.hse.ru/our/
>> HTTP/2 200
>> server: nginx
>> date: Thu, 30 May 2019 14:57:37 GMT
>> …
>> x-ireland-cache-status: STALE
>>
>> H27: ~ $ curl -I https://www.hse.ru/our/
>> HTTP/2 200
>> server: nginx
>> date: Thu, 30 May 2019 14:57:39 GMT
>> …
>> x-ireland-cache-status: HIT
>>
>> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём
>> следующего звоночка…
>>
>> у нас нет инструмента по отслеживанию «застрявших UPDATING»,
>> и нет способа точечно их пнуть
>> (если только не отслеживать $upstream_cache_status по каждому ресурсу и
>> переходы статусов со временем, которые в 99.99% переходят из UPDATING в
>> правильные статусы);
>>
>> приходится ждать только сигнала от недовольных пользователей…
>>
>> РЕЗЮМИРУЕМ
>>
>> ещё раз, сценарий, как мы видим откуда растёт проблема:
>>
>> 1. некоторая страница успешно кэшируется
>> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер
>> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч
>> запросов)
>> 3. никакой больше воркер это задание не получает до перезапуска nginx
>> 4. недовольные клиенты получают устаревший контент
>>
>> РЕШЕНИЕ?
>>
>> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
>>
>> какие варианты решения подобной проблемы существуют? в чём может быть
>> возможная причина?
>>
>> может есть рекомендации по дополнительным настройкам?
>>
>> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но
>> их (падения воркеров) надо учитывать в работе nginx:
>>
>> если это рассматривать как баг nginx – можно ли найти ему решение в
>> будущих обновлениях, в виде отправки повторной задачи воркерам на
>> обновление кэша, по таймауту?..
>>
>> _______________________________________________
>> 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/20190531/3cf32e39/attachment-0001.html>

From swood на fotofor.biz  Fri May 31 15:51:15 2019
From: swood на fotofor.biz (Anton Kiryushkin)
Date: Fri, 31 May 2019 16:51:15 +0100
Subject: Unitd + client_addr
Message-ID: <CAM_jxg2ebcKT6tJ7U1OkB2n5yFhbY3Em8eQ08+o3wmLp6n1h5A@mail.gmail.com>

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

Не подскажете, какова судьба вот этого тикета:
https://github.com/nginx/unit/issues/132

А так же, возможно, есть прямой способ, как получить в php, запускаемом
через unit клиентский айпишник? Сейчас там 127.0.0.1, что очень и очень
плохо и ставит использование unit под жирный вопрос.

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

From mif на me.com  Fri May 31 19:01:34 2019
From: mif на me.com (Alexey Galygin)
Date: Fri, 31 May 2019 22:01:34 +0300
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
Message-ID: <b389da77-6af7-4ebb-9027-5302035909d6@Spark>

получил плоды ожидания корок

$ file /usr/sbin/nginx
/usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped

$ nm -g /usr/sbin/nginx | grep main
U __libc_start_main@@GLIBC_2.2.5
000000000045a4c0 T main
000000000048fdb0 T ngx_ssl_get_client_v_remain
00000000005c9cf0 T rand_pool_bytes_remaining



нападало две группы корок (то есть, осыпается сразу аж группами):

-rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
… всего порядка 20 штук за раз
-rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635

и через пол часа:

-rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
… ешё 30 штук за раз
-rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302


падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес 0x0…0)
но gdb символов в точке падения не видит:

# gdb core.nginx.11620
GNU gdb (GDB) …
Missing separate debuginfo for the main executable file
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой штуки нет)
Core was generated by `nginx: worker pr'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f8512e2ea1e in ?? ()
"/tmp/core.nginx.11620" is a core file.
Please specify an executable to debug.
(gdb) bt full
#0 0x00007f8512e2ea1e in ?? ()
No symbol table info available.
#1 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)


куда копать?

On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> В error_log ничего на сегфолте не может записаться, нет особого смысла его включать в debug
>
> По bt full больше инфы будет
>
> > On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
> > > Илья, модули все из коробки
> > >
> > > ничего лишнего не доливаем
> > >
> > > из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
> > >
> > > --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug
> > >
> > > --with-debug ещё добавил только что на время теста… и уровень отладки error_log включил debug
> > > но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
> > >
> > > корки сейчас включу и буду ловить
> > > но это ещё умудриться словить момент и дождаться, когда упадёт, может за час несколько раз свалится
> > >
> > >
> > > On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> > > > привет!
> > > >
> > > > segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей nginx.
> > > >  можете показать вывод "nginx -V" ?
> > > >
> > > > как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с отладкой, при это не strip-нуть ее в момент инсталяции
> > > > команда "file `which nginx`" должна показыват "not stripped"
> > > >
> > > > далее - в вашей операционной системе разрешаете сохранение core dump (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
> > > >
> > > > потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt full", смотрите на чем именно упало.
> > > >
> > > > если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
> > > >
> > > > > пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <nginx-ru на nginx.org>:
> > > > > > всем привет
> > > > > >
> > > > > > ПРОБЛЕМА
> > > > > >
> > > > > > давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,
> > > > > > что ряд страниц при обновлении кэша входят в вечный статус UPDATING
> > > > > >
> > > > > > см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
> > > > > >
> > > > > > происходит это совершенно на рандомных страницах, и способа воспроизвести нет – только по прецедентной жалобе от пользователей, что закешированный контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи всё в норму, но ждать до утра никто не хочет)
> > > > > >
> > > > > > КОНФИГУРАЦИЯ
> > > > > >
> > > > > > релевантные настройки такие:
> > > > > >
> > > > > > proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
> > > > > > proxy_cache_background_update on;
> > > > > > proxy_cache_lock on;
> > > > > > proxy_cache_lock_timeout 25s;
> > > > > >
> > > > > > недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка кастомная):
> > > > > >
> > > > > > nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI support enabled
> > > > > >
> > > > > > при этом:
> > > > > >
> > > > > > nginx -s reload # не помогает…
> > > > > >
> > > > > > а помогает только явный «мягкий» перезапуск сервера (процедура похожая на обновление бинарника):
> > > > > >
> > > > > > #!/usr/bin/env bash
> > > > > > # скрипт перезапуска или обновления бинарника:
> > > > > > sudo kill -s USR2 `cat /run/nginx.pid`
> > > > > > sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> > > > > > echo 'waiting for 5 minutes required for graceful reload'
> > > > > > sleep 300
> > > > > > sudo kill -s TERM `cat /run/nginx.pid.oldbin`
> > > > > >
> > > > > > ЛОГИ И ДЕМО
> > > > > >
> > > > > > есть предположение, что это из-за эпозодического падения worker'ов (таких набирается несколько десятков за день, при сотнях тысяч запросов)
> > > > > >
> > > > > > dmesg:
> > > > > >
> > > > > > [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> > > > > > …
> > > > > >
> > > > > > error.log:
> > > > > >
> > > > > > 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 11 (core dumped)
> > > > > > …
> > > > > >
> > > > > > подобные падения нас пресделуют много лет (их в день не много), на самых разных версиях nginx, в разных ДЦ, на разных серверах, при разных окружениях;
> > > > > > (по хорошему, надо включить сбор корок и попытаться разобраться, где оно падает…)
> > > > > >
> > > > > > наше предположение такое:
> > > > > >
> > > > > > воркер, который должен был обновить истёкшие данные умирает, а статус так и остаётся UPDATING (на вечно),
> > > > > > всём клиентам отдаётся старый контент,
> > > > > > а новые воркеры уже не планируют запрос обновления с бэка
> > > > > >
> > > > > > вот свежий пример (в заголовке x-ireland-cache-status выводим значение $upstream_cache_status):
> > > > > >
> > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > HTTP/2 200
> > > > > > server: nginx
> > > > > > date: Thu, 30 May 2019 14:54:52 GMT
> > > > > > …
> > > > > > x-ireland-cache-status: UPDATING
> > > > > >
> > > > > > … можно очень долго ждать – статус так и будет UPDATING …
> > > > > >
> > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > HTTP/2 200
> > > > > > server: nginx
> > > > > > date: Thu, 30 May 2019 14:56:47 GMT
> > > > > > …
> > > > > > x-ireland-cache-status: UPDATING
> > > > > >
> > > > > > после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён выше):
> > > > > >
> > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > HTTP/2 200
> > > > > > server: nginx
> > > > > > date: Thu, 30 May 2019 14:57:37 GMT
> > > > > > …
> > > > > > x-ireland-cache-status: STALE
> > > > > >
> > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > HTTP/2 200
> > > > > > server: nginx
> > > > > > date: Thu, 30 May 2019 14:57:39 GMT
> > > > > > …
> > > > > > x-ireland-cache-status: HIT
> > > > > >
> > > > > > всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём следующего звоночка…
> > > > > >
> > > > > > у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> > > > > > и нет способа точечно их пнуть
> > > > > > (если только не отслеживать $upstream_cache_status по каждому ресурсу и переходы статусов со временем, которые в 99.99% переходят из UPDATING в правильные статусы);
> > > > > >
> > > > > > приходится ждать только сигнала от недовольных пользователей…
> > > > > >
> > > > > > РЕЗЮМИРУЕМ
> > > > > >
> > > > > > ещё раз, сценарий, как мы видим откуда растёт проблема:
> > > > > >
> > > > > > 1. некоторая страница успешно кэшируется
> > > > > > 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)
> > > > > > 3. никакой больше воркер это задание не получает до перезапуска nginx
> > > > > > 4. недовольные клиенты получают устаревший контент
> > > > > >
> > > > > > РЕШЕНИЕ?
> > > > > >
> > > > > > перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
> > > > > >
> > > > > > какие варианты решения подобной проблемы существуют? в чём может быть возможная причина?
> > > > > >
> > > > > > может есть рекомендации по дополнительным настройкам?
> > > > > >
> > > > > > да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их (падения воркеров) надо учитывать в работе nginx:
> > > > > >
> > > > > > если это рассматривать как баг nginx – можно ли найти ему решение в будущих обновлениях, в виде отправки повторной задачи воркерам на обновление кэша, по таймауту?..
> > > > > > _______________________________________________
> > > > > > 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/20190531/4849b2b0/attachment-0001.html>

From chipitsine на gmail.com  Fri May 31 19:08:25 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 1 Jun 2019 00:08:25 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
Message-ID: <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>

покажите вывод

file `which nginx`

?

и такой момент. как можно с минимальным риском подменить бинарник
а) смотрим "nginx -V"
б) берем исходники, компилируем их с всем, что есть в пункте "a)" и
добавляем --with-debug
в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем
руками этот бинарник вместо nginx, который в путях (ни в коем случае не
"make install")

сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif на me.com>:

> получил плоды ожидания корок
>
> $ file /usr/sbin/nginx
> /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>
> $ nm -g /usr/sbin/nginx | grep main
> U __libc_start_main@@GLIBC_2.2.5
> 000000000045a4c0 T main
> 000000000048fdb0 T ngx_ssl_get_client_v_remain
> 00000000005c9cf0 T rand_pool_bytes_remaining
>
>
>
> нападало две группы корок (то есть, осыпается сразу аж группами):
>
> -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
> … всего порядка 20 штук за раз
> -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
>
> и через пол часа:
>
> -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
> … ешё 30 штук за раз
> -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
>
>
> падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес
> 0x0…0)
> но gdb символов в точке падения не видит:
>
> # gdb core.nginx.11620
> GNU gdb (GDB) …
> Missing separate debuginfo for the main executable file
> Try: yum --enablerepo='*debug*' install
> /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой
> штуки нет)
> Core was generated by `nginx: worker pr'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007f8512e2ea1e in ?? ()
> "/tmp/core.nginx.11620" is a core file.
> Please specify an executable to debug.
> (gdb) bt full
> #0 0x00007f8512e2ea1e in ?? ()
> No symbol table info available.
> #1 0x0000000000000000 in ?? ()
> No symbol table info available.
> (gdb)
>
>
> куда копать?
>
> On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> В error_log ничего на сегфолте не может записаться, нет особого смысла его
> включать в debug
>
> По bt full больше инфы будет
>
> On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
>
> Илья, модули все из коробки
>
> ничего лишнего не доливаем
>
> из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
>
> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2'
> --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> --with-debug ещё добавил только что на время теста… и уровень отладки
> error_log включил debug
> но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
>
> корки сейчас включу и буду ловить
> но это ещё умудриться словить момент и дождаться, когда упадёт, может за
> час несколько раз свалится
>
>
> On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> привет!
>
> segfault - с очень-очень-очень большой вероятностью из-за сторонних
> модулей nginx.
>  можете показать вывод "nginx -V" ?
>
> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
> отладкой, при это не strip-нуть ее в момент инсталяции
> команда "file `which nginx`" должна показыват "not stripped"
>
> далее - в вашей операционной системе разрешаете сохранение core dump
> (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>
> потом, берете сохраненный core dump, при помощи gdb открываете, делаете
> "bt full", смотрите на чем именно упало.
>
> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>
> пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <
> nginx-ru на nginx.org>:
>
> всем привет
>
> ПРОБЛЕМА
>
> давно (уже не первый год обновление за обновлением nginx и OpenSSL)
> наблюдаем,
> что ряд страниц при обновлении кэша входят в вечный статус UPDATING
>
> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
>
> происходит это совершенно на рандомных страницах, и способа воспроизвести
> нет – только по прецедентной жалобе от пользователей, что закешированный
> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи
> всё в норму, но ждать до утра никто не хочет)
>
> КОНФИГУРАЦИЯ
>
> релевантные настройки такие:
>
> proxy_cache_use_stale error timeout invalid_header updating http_500
> http_502 http_503 http_504;
> proxy_cache_background_update on;
> proxy_cache_lock on;
> proxy_cache_lock_timeout 25s;
>
> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка
> кастомная):
>
> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI
> support enabled
>
> при этом:
>
> nginx -s reload # не помогает…
>
> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на
> обновление бинарника):
>
> #!/usr/bin/env bash
> # скрипт перезапуска или обновления бинарника:
> sudo kill -s USR2 `cat /run/nginx.pid`
> sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> echo 'waiting for 5 minutes required for graceful reload'
> sleep 300
> sudo kill -s TERM `cat /run/nginx.pid.oldbin`
>
> ЛОГИ И ДЕМО
>
> есть предположение, что это из-за эпозодического падения worker'ов (таких
> набирается несколько десятков за день, при сотнях тысяч запросов)
>
> dmesg:
>
> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp
> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> …
>
> error.log:
>
> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on
> signal 11 (core dumped)
> …
>
> подобные падения нас пресделуют много лет (их в день не много), на самых
> разных версиях nginx, в разных ДЦ, на разных серверах, при разных
> окружениях;
> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно
> падает…)
>
> наше предположение такое:
>
> воркер, который должен был обновить истёкшие данные умирает, а статус так
> и остаётся UPDATING (на вечно),
> всём клиентам отдаётся старый контент,
> а новые воркеры уже не планируют запрос обновления с бэка
>
> вот свежий пример (в заголовке x-ireland-cache-status выводим значение
> $upstream_cache_status):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:54:52 GMT
> …
> x-ireland-cache-status: UPDATING
>
> … можно очень долго ждать – статус так и будет UPDATING …
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:56:47 GMT
> …
> x-ireland-cache-status: UPDATING
>
> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был
> приведён выше):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:37 GMT
> …
> x-ireland-cache-status: STALE
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:39 GMT
> …
> x-ireland-cache-status: HIT
>
> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём
> следующего звоночка…
>
> у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> и нет способа точечно их пнуть
> (если только не отслеживать $upstream_cache_status по каждому ресурсу и
> переходы статусов со временем, которые в 99.99% переходят из UPDATING в
> правильные статусы);
>
> приходится ждать только сигнала от недовольных пользователей…
>
> РЕЗЮМИРУЕМ
>
> ещё раз, сценарий, как мы видим откуда растёт проблема:
>
> 1. некоторая страница успешно кэшируется
> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер
> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч
> запросов)
> 3. никакой больше воркер это задание не получает до перезапуска nginx
> 4. недовольные клиенты получают устаревший контент
>
> РЕШЕНИЕ?
>
> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
>
> какие варианты решения подобной проблемы существуют? в чём может быть
> возможная причина?
>
> может есть рекомендации по дополнительным настройкам?
>
> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но
> их (падения воркеров) надо учитывать в работе nginx:
>
> если это рассматривать как баг nginx – можно ли найти ему решение в
> будущих обновлениях, в виде отправки повторной задачи воркерам на
> обновление кэша, по таймауту?..
>
> _______________________________________________
> 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/9d9eb2b8/attachment-0001.html>

From chipitsine на gmail.com  Fri May 31 19:15:25 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 1 Jun 2019 00:15:25 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
Message-ID: <CAFHpkQHPR00Ot7iHffNajm6J1eTP8S2AdcGEKp7RfyqGBgjBUg@mail.gmail.com>

прошу прощения, не заметил "not stripped" в вашем выводе.
попробуйте добавить в configure вот такую опцию --with-cc-opt="-g"

сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif на me.com>:

> получил плоды ожидания корок
>
> $ file /usr/sbin/nginx
> /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>
> $ nm -g /usr/sbin/nginx | grep main
> U __libc_start_main@@GLIBC_2.2.5
> 000000000045a4c0 T main
> 000000000048fdb0 T ngx_ssl_get_client_v_remain
> 00000000005c9cf0 T rand_pool_bytes_remaining
>
>
>
> нападало две группы корок (то есть, осыпается сразу аж группами):
>
> -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
> … всего порядка 20 штук за раз
> -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
>
> и через пол часа:
>
> -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
> … ешё 30 штук за раз
> -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
>
>
> падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес
> 0x0…0)
> но gdb символов в точке падения не видит:
>
> # gdb core.nginx.11620
> GNU gdb (GDB) …
> Missing separate debuginfo for the main executable file
> Try: yum --enablerepo='*debug*' install
> /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой
> штуки нет)
> Core was generated by `nginx: worker pr'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007f8512e2ea1e in ?? ()
> "/tmp/core.nginx.11620" is a core file.
> Please specify an executable to debug.
> (gdb) bt full
> #0 0x00007f8512e2ea1e in ?? ()
> No symbol table info available.
> #1 0x0000000000000000 in ?? ()
> No symbol table info available.
> (gdb)
>
>
> куда копать?
>
> On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> В error_log ничего на сегфолте не может записаться, нет особого смысла его
> включать в debug
>
> По bt full больше инфы будет
>
> On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
>
> Илья, модули все из коробки
>
> ничего лишнего не доливаем
>
> из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
>
> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2'
> --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> --with-debug ещё добавил только что на время теста… и уровень отладки
> error_log включил debug
> но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
>
> корки сейчас включу и буду ловить
> но это ещё умудриться словить момент и дождаться, когда упадёт, может за
> час несколько раз свалится
>
>
> On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> привет!
>
> segfault - с очень-очень-очень большой вероятностью из-за сторонних
> модулей nginx.
>  можете показать вывод "nginx -V" ?
>
> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
> отладкой, при это не strip-нуть ее в момент инсталяции
> команда "file `which nginx`" должна показыват "not stripped"
>
> далее - в вашей операционной системе разрешаете сохранение core dump
> (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>
> потом, берете сохраненный core dump, при помощи gdb открываете, делаете
> "bt full", смотрите на чем именно упало.
>
> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>
> пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <
> nginx-ru на nginx.org>:
>
> всем привет
>
> ПРОБЛЕМА
>
> давно (уже не первый год обновление за обновлением nginx и OpenSSL)
> наблюдаем,
> что ряд страниц при обновлении кэша входят в вечный статус UPDATING
>
> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
>
> происходит это совершенно на рандомных страницах, и способа воспроизвести
> нет – только по прецедентной жалобе от пользователей, что закешированный
> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи
> всё в норму, но ждать до утра никто не хочет)
>
> КОНФИГУРАЦИЯ
>
> релевантные настройки такие:
>
> proxy_cache_use_stale error timeout invalid_header updating http_500
> http_502 http_503 http_504;
> proxy_cache_background_update on;
> proxy_cache_lock on;
> proxy_cache_lock_timeout 25s;
>
> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка
> кастомная):
>
> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI
> support enabled
>
> при этом:
>
> nginx -s reload # не помогает…
>
> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на
> обновление бинарника):
>
> #!/usr/bin/env bash
> # скрипт перезапуска или обновления бинарника:
> sudo kill -s USR2 `cat /run/nginx.pid`
> sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> echo 'waiting for 5 minutes required for graceful reload'
> sleep 300
> sudo kill -s TERM `cat /run/nginx.pid.oldbin`
>
> ЛОГИ И ДЕМО
>
> есть предположение, что это из-за эпозодического падения worker'ов (таких
> набирается несколько десятков за день, при сотнях тысяч запросов)
>
> dmesg:
>
> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp
> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> …
>
> error.log:
>
> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on
> signal 11 (core dumped)
> …
>
> подобные падения нас пресделуют много лет (их в день не много), на самых
> разных версиях nginx, в разных ДЦ, на разных серверах, при разных
> окружениях;
> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно
> падает…)
>
> наше предположение такое:
>
> воркер, который должен был обновить истёкшие данные умирает, а статус так
> и остаётся UPDATING (на вечно),
> всём клиентам отдаётся старый контент,
> а новые воркеры уже не планируют запрос обновления с бэка
>
> вот свежий пример (в заголовке x-ireland-cache-status выводим значение
> $upstream_cache_status):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:54:52 GMT
> …
> x-ireland-cache-status: UPDATING
>
> … можно очень долго ждать – статус так и будет UPDATING …
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:56:47 GMT
> …
> x-ireland-cache-status: UPDATING
>
> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был
> приведён выше):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:37 GMT
> …
> x-ireland-cache-status: STALE
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:39 GMT
> …
> x-ireland-cache-status: HIT
>
> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём
> следующего звоночка…
>
> у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> и нет способа точечно их пнуть
> (если только не отслеживать $upstream_cache_status по каждому ресурсу и
> переходы статусов со временем, которые в 99.99% переходят из UPDATING в
> правильные статусы);
>
> приходится ждать только сигнала от недовольных пользователей…
>
> РЕЗЮМИРУЕМ
>
> ещё раз, сценарий, как мы видим откуда растёт проблема:
>
> 1. некоторая страница успешно кэшируется
> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер
> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч
> запросов)
> 3. никакой больше воркер это задание не получает до перезапуска nginx
> 4. недовольные клиенты получают устаревший контент
>
> РЕШЕНИЕ?
>
> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
>
> какие варианты решения подобной проблемы существуют? в чём может быть
> возможная причина?
>
> может есть рекомендации по дополнительным настройкам?
>
> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но
> их (падения воркеров) надо учитывать в работе nginx:
>
> если это рассматривать как баг nginx – можно ли найти ему решение в
> будущих обновлениях, в виде отправки повторной задачи воркерам на
> обновление кэша, по таймауту?..
>
> _______________________________________________
> 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/64a7b29b/attachment-0001.html>

From mif на me.com  Fri May 31 19:16:10 2019
From: mif на me.com (Alexey Galygin)
Date: Fri, 31 May 2019 22:16:10 +0300
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
 <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>
Message-ID: <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>

на CentOS /sbin – симлинк на /usr/sbin
which nginx даёт /sbin/nginx

но файл тот же

$ file `which nginx`
/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped

а)

nginx version: nginx/1.16.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
built with OpenSSL 1.1.1b 26 Feb 2019
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug

б)

уже днём так и сделал

в)

make install вполне себе сделал дело
файл тот же

~/work/nginx-1.16.0/objs # sha1sum nginx
29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx

~/work/nginx-1.16.0/objs # ls -la nginx
-rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx

~/work/nginx-1.16.0/objs # ls -la /sbin/nginx
-rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx

~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx
29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx

On 31 May 2019, 22:08 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> покажите вывод
>
> file `which nginx`
>
> ?
>
> и такой момент. как можно с минимальным риском подменить бинарник
> а) смотрим "nginx -V"
> б) берем исходники, компилируем их с всем, что есть в пункте "a)" и добавляем --with-debug
> в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем руками этот бинарник вместо nginx, который в путях (ни в коем случае не "make install")
>
> > сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif на me.com>:
> > > получил плоды ожидания корок
> > >
> > > $ file /usr/sbin/nginx
> > > /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
> > >
> > > $ nm -g /usr/sbin/nginx | grep main
> > > U __libc_start_main@@GLIBC_2.2.5
> > > 000000000045a4c0 T main
> > > 000000000048fdb0 T ngx_ssl_get_client_v_remain
> > > 00000000005c9cf0 T rand_pool_bytes_remaining
> > >
> > >
> > >
> > > нападало две группы корок (то есть, осыпается сразу аж группами):
> > >
> > > -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
> > > … всего порядка 20 штук за раз
> > > -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
> > >
> > > и через пол часа:
> > >
> > > -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
> > > … ешё 30 штук за раз
> > > -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
> > >
> > >
> > > падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес 0x0…0)
> > > но gdb символов в точке падения не видит:
> > >
> > > # gdb core.nginx.11620
> > > GNU gdb (GDB) …
> > > Missing separate debuginfo for the main executable file
> > > Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой штуки нет)
> > > Core was generated by `nginx: worker pr'.
> > > Program terminated with signal 11, Segmentation fault.
> > > #0 0x00007f8512e2ea1e in ?? ()
> > > "/tmp/core.nginx.11620" is a core file.
> > > Please specify an executable to debug.
> > > (gdb) bt full
> > > #0 0x00007f8512e2ea1e in ?? ()
> > > No symbol table info available.
> > > #1 0x0000000000000000 in ?? ()
> > > No symbol table info available.
> > > (gdb)
> > >
> > >
> > > куда копать?
> > >
> > > On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> > > > В error_log ничего на сегфолте не может записаться, нет особого смысла его включать в debug
> > > >
> > > > По bt full больше инфы будет
> > > >
> > > > > On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
> > > > > > Илья, модули все из коробки
> > > > > >
> > > > > > ничего лишнего не доливаем
> > > > > >
> > > > > > из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
> > > > > >
> > > > > > --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug
> > > > > >
> > > > > > --with-debug ещё добавил только что на время теста… и уровень отладки error_log включил debug
> > > > > > но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
> > > > > >
> > > > > > корки сейчас включу и буду ловить
> > > > > > но это ещё умудриться словить момент и дождаться, когда упадёт, может за час несколько раз свалится
> > > > > >
> > > > > >
> > > > > > On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> > > > > > > привет!
> > > > > > >
> > > > > > > segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей nginx.
> > > > > > >  можете показать вывод "nginx -V" ?
> > > > > > >
> > > > > > > как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с отладкой, при это не strip-нуть ее в момент инсталяции
> > > > > > > команда "file `which nginx`" должна показыват "not stripped"
> > > > > > >
> > > > > > > далее - в вашей операционной системе разрешаете сохранение core dump (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
> > > > > > >
> > > > > > > потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt full", смотрите на чем именно упало.
> > > > > > >
> > > > > > > если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
> > > > > > >
> > > > > > > > пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <nginx-ru на nginx.org>:
> > > > > > > > > всем привет
> > > > > > > > >
> > > > > > > > > ПРОБЛЕМА
> > > > > > > > >
> > > > > > > > > давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,
> > > > > > > > > что ряд страниц при обновлении кэша входят в вечный статус UPDATING
> > > > > > > > >
> > > > > > > > > см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
> > > > > > > > >
> > > > > > > > > происходит это совершенно на рандомных страницах, и способа воспроизвести нет – только по прецедентной жалобе от пользователей, что закешированный контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи всё в норму, но ждать до утра никто не хочет)
> > > > > > > > >
> > > > > > > > > КОНФИГУРАЦИЯ
> > > > > > > > >
> > > > > > > > > релевантные настройки такие:
> > > > > > > > >
> > > > > > > > > proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
> > > > > > > > > proxy_cache_background_update on;
> > > > > > > > > proxy_cache_lock on;
> > > > > > > > > proxy_cache_lock_timeout 25s;
> > > > > > > > >
> > > > > > > > > недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка кастомная):
> > > > > > > > >
> > > > > > > > > nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI support enabled
> > > > > > > > >
> > > > > > > > > при этом:
> > > > > > > > >
> > > > > > > > > nginx -s reload # не помогает…
> > > > > > > > >
> > > > > > > > > а помогает только явный «мягкий» перезапуск сервера (процедура похожая на обновление бинарника):
> > > > > > > > >
> > > > > > > > > #!/usr/bin/env bash
> > > > > > > > > # скрипт перезапуска или обновления бинарника:
> > > > > > > > > sudo kill -s USR2 `cat /run/nginx.pid`
> > > > > > > > > sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> > > > > > > > > echo 'waiting for 5 minutes required for graceful reload'
> > > > > > > > > sleep 300
> > > > > > > > > sudo kill -s TERM `cat /run/nginx.pid.oldbin`
> > > > > > > > >
> > > > > > > > > ЛОГИ И ДЕМО
> > > > > > > > >
> > > > > > > > > есть предположение, что это из-за эпозодического падения worker'ов (таких набирается несколько десятков за день, при сотнях тысяч запросов)
> > > > > > > > >
> > > > > > > > > dmesg:
> > > > > > > > >
> > > > > > > > > [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> > > > > > > > > …
> > > > > > > > >
> > > > > > > > > error.log:
> > > > > > > > >
> > > > > > > > > 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 11 (core dumped)
> > > > > > > > > …
> > > > > > > > >
> > > > > > > > > подобные падения нас пресделуют много лет (их в день не много), на самых разных версиях nginx, в разных ДЦ, на разных серверах, при разных окружениях;
> > > > > > > > > (по хорошему, надо включить сбор корок и попытаться разобраться, где оно падает…)
> > > > > > > > >
> > > > > > > > > наше предположение такое:
> > > > > > > > >
> > > > > > > > > воркер, который должен был обновить истёкшие данные умирает, а статус так и остаётся UPDATING (на вечно),
> > > > > > > > > всём клиентам отдаётся старый контент,
> > > > > > > > > а новые воркеры уже не планируют запрос обновления с бэка
> > > > > > > > >
> > > > > > > > > вот свежий пример (в заголовке x-ireland-cache-status выводим значение $upstream_cache_status):
> > > > > > > > >
> > > > > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > > > > HTTP/2 200
> > > > > > > > > server: nginx
> > > > > > > > > date: Thu, 30 May 2019 14:54:52 GMT
> > > > > > > > > …
> > > > > > > > > x-ireland-cache-status: UPDATING
> > > > > > > > >
> > > > > > > > > … можно очень долго ждать – статус так и будет UPDATING …
> > > > > > > > >
> > > > > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > > > > HTTP/2 200
> > > > > > > > > server: nginx
> > > > > > > > > date: Thu, 30 May 2019 14:56:47 GMT
> > > > > > > > > …
> > > > > > > > > x-ireland-cache-status: UPDATING
> > > > > > > > >
> > > > > > > > > после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён выше):
> > > > > > > > >
> > > > > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > > > > HTTP/2 200
> > > > > > > > > server: nginx
> > > > > > > > > date: Thu, 30 May 2019 14:57:37 GMT
> > > > > > > > > …
> > > > > > > > > x-ireland-cache-status: STALE
> > > > > > > > >
> > > > > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > > > > HTTP/2 200
> > > > > > > > > server: nginx
> > > > > > > > > date: Thu, 30 May 2019 14:57:39 GMT
> > > > > > > > > …
> > > > > > > > > x-ireland-cache-status: HIT
> > > > > > > > >
> > > > > > > > > всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём следующего звоночка…
> > > > > > > > >
> > > > > > > > > у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> > > > > > > > > и нет способа точечно их пнуть
> > > > > > > > > (если только не отслеживать $upstream_cache_status по каждому ресурсу и переходы статусов со временем, которые в 99.99% переходят из UPDATING в правильные статусы);
> > > > > > > > >
> > > > > > > > > приходится ждать только сигнала от недовольных пользователей…
> > > > > > > > >
> > > > > > > > > РЕЗЮМИРУЕМ
> > > > > > > > >
> > > > > > > > > ещё раз, сценарий, как мы видим откуда растёт проблема:
> > > > > > > > >
> > > > > > > > > 1. некоторая страница успешно кэшируется
> > > > > > > > > 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)
> > > > > > > > > 3. никакой больше воркер это задание не получает до перезапуска nginx
> > > > > > > > > 4. недовольные клиенты получают устаревший контент
> > > > > > > > >
> > > > > > > > > РЕШЕНИЕ?
> > > > > > > > >
> > > > > > > > > перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
> > > > > > > > >
> > > > > > > > > какие варианты решения подобной проблемы существуют? в чём может быть возможная причина?
> > > > > > > > >
> > > > > > > > > может есть рекомендации по дополнительным настройкам?
> > > > > > > > >
> > > > > > > > > да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их (падения воркеров) надо учитывать в работе nginx:
> > > > > > > > >
> > > > > > > > > если это рассматривать как баг nginx – можно ли найти ему решение в будущих обновлениях, в виде отправки повторной задачи воркерам на обновление кэша, по таймауту?..
> > > > > > > > > _______________________________________________
> > > > > > > > > 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/20190531/57321d4a/attachment-0001.html>

From chipitsine на gmail.com  Fri May 31 19:18:36 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 1 Jun 2019 00:18:36 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
 <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>
 <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>
Message-ID: <CAFHpkQFZVcpuxay2tdS33UqNNVAecv=-nLVf9dhTzoS8Qv_=AA@mail.gmail.com>

теряюсь в догадках. "-g" у вас уже есть.
попробовать поменять "-g" на "-ggdb" ?

сб, 1 июн. 2019 г. в 00:16, Alexey Galygin <mif на me.com>:

> на CentOS /sbin – симлинк на /usr/sbin
> which nginx даёт /sbin/nginx
>
> но файл тот же
>
> $ file `which nginx`
> /sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>
> а)
>
> nginx version: nginx/1.16.0
> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
> built with OpenSSL 1.1.1b 26 Feb 2019
> TLS SNI support enabled
> configure arguments: --with-cc-opt='-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> б)
>
> уже днём так и сделал
>
> в)
>
> make install вполне себе сделал дело
> файл тот же
>
> ~/work/nginx-1.16.0/objs # sha1sum nginx
> 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx
>
> ~/work/nginx-1.16.0/objs # ls -la nginx
> -rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx
>
> ~/work/nginx-1.16.0/objs # ls -la /sbin/nginx
> -rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx
>
> ~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx
> 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx
>
> On 31 May 2019, 22:08 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> покажите вывод
>
> file `which nginx`
>
> ?
>
> и такой момент. как можно с минимальным риском подменить бинарник
> а) смотрим "nginx -V"
> б) берем исходники, компилируем их с всем, что есть в пункте "a)" и
> добавляем --with-debug
> в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем
> руками этот бинарник вместо nginx, который в путях (ни в коем случае не
> "make install")
>
> сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif на me.com>:
>
> получил плоды ожидания корок
>
> $ file /usr/sbin/nginx
> /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>
> $ nm -g /usr/sbin/nginx | grep main
> U __libc_start_main@@GLIBC_2.2.5
> 000000000045a4c0 T main
> 000000000048fdb0 T ngx_ssl_get_client_v_remain
> 00000000005c9cf0 T rand_pool_bytes_remaining
>
>
>
> нападало две группы корок (то есть, осыпается сразу аж группами):
>
> -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
> … всего порядка 20 штук за раз
> -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
>
> и через пол часа:
>
> -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
> … ешё 30 штук за раз
> -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
>
>
> падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес
> 0x0…0)
> но gdb символов в точке падения не видит:
>
> # gdb core.nginx.11620
> GNU gdb (GDB) …
> Missing separate debuginfo for the main executable file
> Try: yum --enablerepo='*debug*' install
> /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой
> штуки нет)
> Core was generated by `nginx: worker pr'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007f8512e2ea1e in ?? ()
> "/tmp/core.nginx.11620" is a core file.
> Please specify an executable to debug.
> (gdb) bt full
> #0 0x00007f8512e2ea1e in ?? ()
> No symbol table info available.
> #1 0x0000000000000000 in ?? ()
> No symbol table info available.
> (gdb)
>
>
> куда копать?
>
> On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> В error_log ничего на сегфолте не может записаться, нет особого смысла его
> включать в debug
>
> По bt full больше инфы будет
>
> On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
>
> Илья, модули все из коробки
>
> ничего лишнего не доливаем
>
> из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
>
> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2'
> --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> --with-debug ещё добавил только что на время теста… и уровень отладки
> error_log включил debug
> но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
>
> корки сейчас включу и буду ловить
> но это ещё умудриться словить момент и дождаться, когда упадёт, может за
> час несколько раз свалится
>
>
> On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> привет!
>
> segfault - с очень-очень-очень большой вероятностью из-за сторонних
> модулей nginx.
>  можете показать вывод "nginx -V" ?
>
> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
> отладкой, при это не strip-нуть ее в момент инсталяции
> команда "file `which nginx`" должна показыват "not stripped"
>
> далее - в вашей операционной системе разрешаете сохранение core dump
> (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>
> потом, берете сохраненный core dump, при помощи gdb открываете, делаете
> "bt full", смотрите на чем именно упало.
>
> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>
> пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <
> nginx-ru на nginx.org>:
>
> всем привет
>
> ПРОБЛЕМА
>
> давно (уже не первый год обновление за обновлением nginx и OpenSSL)
> наблюдаем,
> что ряд страниц при обновлении кэша входят в вечный статус UPDATING
>
> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
>
> происходит это совершенно на рандомных страницах, и способа воспроизвести
> нет – только по прецедентной жалобе от пользователей, что закешированный
> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи
> всё в норму, но ждать до утра никто не хочет)
>
> КОНФИГУРАЦИЯ
>
> релевантные настройки такие:
>
> proxy_cache_use_stale error timeout invalid_header updating http_500
> http_502 http_503 http_504;
> proxy_cache_background_update on;
> proxy_cache_lock on;
> proxy_cache_lock_timeout 25s;
>
> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка
> кастомная):
>
> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI
> support enabled
>
> при этом:
>
> nginx -s reload # не помогает…
>
> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на
> обновление бинарника):
>
> #!/usr/bin/env bash
> # скрипт перезапуска или обновления бинарника:
> sudo kill -s USR2 `cat /run/nginx.pid`
> sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> echo 'waiting for 5 minutes required for graceful reload'
> sleep 300
> sudo kill -s TERM `cat /run/nginx.pid.oldbin`
>
> ЛОГИ И ДЕМО
>
> есть предположение, что это из-за эпозодического падения worker'ов (таких
> набирается несколько десятков за день, при сотнях тысяч запросов)
>
> dmesg:
>
> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp
> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> …
>
> error.log:
>
> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on
> signal 11 (core dumped)
> …
>
> подобные падения нас пресделуют много лет (их в день не много), на самых
> разных версиях nginx, в разных ДЦ, на разных серверах, при разных
> окружениях;
> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно
> падает…)
>
> наше предположение такое:
>
> воркер, который должен был обновить истёкшие данные умирает, а статус так
> и остаётся UPDATING (на вечно),
> всём клиентам отдаётся старый контент,
> а новые воркеры уже не планируют запрос обновления с бэка
>
> вот свежий пример (в заголовке x-ireland-cache-status выводим значение
> $upstream_cache_status):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:54:52 GMT
> …
> x-ireland-cache-status: UPDATING
>
> … можно очень долго ждать – статус так и будет UPDATING …
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:56:47 GMT
> …
> x-ireland-cache-status: UPDATING
>
> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был
> приведён выше):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:37 GMT
> …
> x-ireland-cache-status: STALE
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:39 GMT
> …
> x-ireland-cache-status: HIT
>
> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём
> следующего звоночка…
>
> у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> и нет способа точечно их пнуть
> (если только не отслеживать $upstream_cache_status по каждому ресурсу и
> переходы статусов со временем, которые в 99.99% переходят из UPDATING в
> правильные статусы);
>
> приходится ждать только сигнала от недовольных пользователей…
>
> РЕЗЮМИРУЕМ
>
> ещё раз, сценарий, как мы видим откуда растёт проблема:
>
> 1. некоторая страница успешно кэшируется
> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер
> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч
> запросов)
> 3. никакой больше воркер это задание не получает до перезапуска nginx
> 4. недовольные клиенты получают устаревший контент
>
> РЕШЕНИЕ?
>
> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
>
> какие варианты решения подобной проблемы существуют? в чём может быть
> возможная причина?
>
> может есть рекомендации по дополнительным настройкам?
>
> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но
> их (падения воркеров) надо учитывать в работе nginx:
>
> если это рассматривать как баг nginx – можно ли найти ему решение в
> будущих обновлениях, в виде отправки повторной задачи воркерам на
> обновление кэша, по таймауту?..
>
> _______________________________________________
> 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/1ebdaa00/attachment-0001.html>

From chipitsine на gmail.com  Fri May 31 19:21:37 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 1 Jun 2019 00:21:37 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
 <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>
 <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>
Message-ID: <CAFHpkQEScirKkxPu1r6hEG2pZ5_A0_8juvrVUL7Ea2TgTHhpew@mail.gmail.com>

у программы, собранной с отладочными символами должно быть вот так (with
debug_info, not stripped)

[ilia на localhost ~]$ gcc -g 1.c
[ilia на localhost ~]$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=a767b5ee04499077d7685c5d353759d331846666, with debug_info,
not stripped
[ilia на localhost ~]$

сб, 1 июн. 2019 г. в 00:16, Alexey Galygin <mif на me.com>:

> на CentOS /sbin – симлинк на /usr/sbin
> which nginx даёт /sbin/nginx
>
> но файл тот же
>
> $ file `which nginx`
> /sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>
> а)
>
> nginx version: nginx/1.16.0
> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
> built with OpenSSL 1.1.1b 26 Feb 2019
> TLS SNI support enabled
> configure arguments: --with-cc-opt='-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> б)
>
> уже днём так и сделал
>
> в)
>
> make install вполне себе сделал дело
> файл тот же
>
> ~/work/nginx-1.16.0/objs # sha1sum nginx
> 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx
>
> ~/work/nginx-1.16.0/objs # ls -la nginx
> -rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx
>
> ~/work/nginx-1.16.0/objs # ls -la /sbin/nginx
> -rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx
>
> ~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx
> 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx
>
> On 31 May 2019, 22:08 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> покажите вывод
>
> file `which nginx`
>
> ?
>
> и такой момент. как можно с минимальным риском подменить бинарник
> а) смотрим "nginx -V"
> б) берем исходники, компилируем их с всем, что есть в пункте "a)" и
> добавляем --with-debug
> в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем
> руками этот бинарник вместо nginx, который в путях (ни в коем случае не
> "make install")
>
> сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif на me.com>:
>
> получил плоды ожидания корок
>
> $ file /usr/sbin/nginx
> /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>
> $ nm -g /usr/sbin/nginx | grep main
> U __libc_start_main@@GLIBC_2.2.5
> 000000000045a4c0 T main
> 000000000048fdb0 T ngx_ssl_get_client_v_remain
> 00000000005c9cf0 T rand_pool_bytes_remaining
>
>
>
> нападало две группы корок (то есть, осыпается сразу аж группами):
>
> -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
> … всего порядка 20 штук за раз
> -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
>
> и через пол часа:
>
> -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
> … ешё 30 штук за раз
> -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
>
>
> падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес
> 0x0…0)
> но gdb символов в точке падения не видит:
>
> # gdb core.nginx.11620
> GNU gdb (GDB) …
> Missing separate debuginfo for the main executable file
> Try: yum --enablerepo='*debug*' install
> /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой
> штуки нет)
> Core was generated by `nginx: worker pr'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007f8512e2ea1e in ?? ()
> "/tmp/core.nginx.11620" is a core file.
> Please specify an executable to debug.
> (gdb) bt full
> #0 0x00007f8512e2ea1e in ?? ()
> No symbol table info available.
> #1 0x0000000000000000 in ?? ()
> No symbol table info available.
> (gdb)
>
>
> куда копать?
>
> On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> В error_log ничего на сегфолте не может записаться, нет особого смысла его
> включать в debug
>
> По bt full больше инфы будет
>
> On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
>
> Илья, модули все из коробки
>
> ничего лишнего не доливаем
>
> из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
>
> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2'
> --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> --with-debug ещё добавил только что на время теста… и уровень отладки
> error_log включил debug
> но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
>
> корки сейчас включу и буду ловить
> но это ещё умудриться словить момент и дождаться, когда упадёт, может за
> час несколько раз свалится
>
>
> On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> привет!
>
> segfault - с очень-очень-очень большой вероятностью из-за сторонних
> модулей nginx.
>  можете показать вывод "nginx -V" ?
>
> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
> отладкой, при это не strip-нуть ее в момент инсталяции
> команда "file `which nginx`" должна показыват "not stripped"
>
> далее - в вашей операционной системе разрешаете сохранение core dump
> (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>
> потом, берете сохраненный core dump, при помощи gdb открываете, делаете
> "bt full", смотрите на чем именно упало.
>
> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>
> пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <
> nginx-ru на nginx.org>:
>
> всем привет
>
> ПРОБЛЕМА
>
> давно (уже не первый год обновление за обновлением nginx и OpenSSL)
> наблюдаем,
> что ряд страниц при обновлении кэша входят в вечный статус UPDATING
>
> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
>
> происходит это совершенно на рандомных страницах, и способа воспроизвести
> нет – только по прецедентной жалобе от пользователей, что закешированный
> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи
> всё в норму, но ждать до утра никто не хочет)
>
> КОНФИГУРАЦИЯ
>
> релевантные настройки такие:
>
> proxy_cache_use_stale error timeout invalid_header updating http_500
> http_502 http_503 http_504;
> proxy_cache_background_update on;
> proxy_cache_lock on;
> proxy_cache_lock_timeout 25s;
>
> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка
> кастомная):
>
> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI
> support enabled
>
> при этом:
>
> nginx -s reload # не помогает…
>
> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на
> обновление бинарника):
>
> #!/usr/bin/env bash
> # скрипт перезапуска или обновления бинарника:
> sudo kill -s USR2 `cat /run/nginx.pid`
> sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> echo 'waiting for 5 minutes required for graceful reload'
> sleep 300
> sudo kill -s TERM `cat /run/nginx.pid.oldbin`
>
> ЛОГИ И ДЕМО
>
> есть предположение, что это из-за эпозодического падения worker'ов (таких
> набирается несколько десятков за день, при сотнях тысяч запросов)
>
> dmesg:
>
> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp
> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> …
>
> error.log:
>
> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on
> signal 11 (core dumped)
> …
>
> подобные падения нас пресделуют много лет (их в день не много), на самых
> разных версиях nginx, в разных ДЦ, на разных серверах, при разных
> окружениях;
> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно
> падает…)
>
> наше предположение такое:
>
> воркер, который должен был обновить истёкшие данные умирает, а статус так
> и остаётся UPDATING (на вечно),
> всём клиентам отдаётся старый контент,
> а новые воркеры уже не планируют запрос обновления с бэка
>
> вот свежий пример (в заголовке x-ireland-cache-status выводим значение
> $upstream_cache_status):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:54:52 GMT
> …
> x-ireland-cache-status: UPDATING
>
> … можно очень долго ждать – статус так и будет UPDATING …
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:56:47 GMT
> …
> x-ireland-cache-status: UPDATING
>
> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был
> приведён выше):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:37 GMT
> …
> x-ireland-cache-status: STALE
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:39 GMT
> …
> x-ireland-cache-status: HIT
>
> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём
> следующего звоночка…
>
> у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> и нет способа точечно их пнуть
> (если только не отслеживать $upstream_cache_status по каждому ресурсу и
> переходы статусов со временем, которые в 99.99% переходят из UPDATING в
> правильные статусы);
>
> приходится ждать только сигнала от недовольных пользователей…
>
> РЕЗЮМИРУЕМ
>
> ещё раз, сценарий, как мы видим откуда растёт проблема:
>
> 1. некоторая страница успешно кэшируется
> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер
> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч
> запросов)
> 3. никакой больше воркер это задание не получает до перезапуска nginx
> 4. недовольные клиенты получают устаревший контент
>
> РЕШЕНИЕ?
>
> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
>
> какие варианты решения подобной проблемы существуют? в чём может быть
> возможная причина?
>
> может есть рекомендации по дополнительным настройкам?
>
> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но
> их (падения воркеров) надо учитывать в работе nginx:
>
> если это рассматривать как баг nginx – можно ли найти ему решение в
> будущих обновлениях, в виде отправки повторной задачи воркерам на
> обновление кэша, по таймауту?..
>
> _______________________________________________
> 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/c146ac1a/attachment-0001.html>

From chipitsine на gmail.com  Fri May 31 19:25:47 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 1 Jun 2019 00:25:47 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <CAFHpkQEScirKkxPu1r6hEG2pZ5_A0_8juvrVUL7Ea2TgTHhpew@mail.gmail.com>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
 <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>
 <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>
 <CAFHpkQEScirKkxPu1r6hEG2pZ5_A0_8juvrVUL7Ea2TgTHhpew@mail.gmail.com>
Message-ID: <CAFHpkQFr2SbptYsEkyHqdti=t0cTx2vT6HYZHus8MzotMMRNmw@mail.gmail.com>

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

http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l116

придумаю, что у вас - расскажу)) нет идей

сб, 1 июн. 2019 г. в 00:21, Илья Шипицин <chipitsine на gmail.com>:

> у программы, собранной с отладочными символами должно быть вот так (with
> debug_info, not stripped)
>
> [ilia на localhost ~]$ gcc -g 1.c
> [ilia на localhost ~]$ file a.out
> a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
> BuildID[sha1]=a767b5ee04499077d7685c5d353759d331846666, with debug_info,
> not stripped
> [ilia на localhost ~]$
>
> сб, 1 июн. 2019 г. в 00:16, Alexey Galygin <mif на me.com>:
>
>> на CentOS /sbin – симлинк на /usr/sbin
>> which nginx даёт /sbin/nginx
>>
>> но файл тот же
>>
>> $ file `which nginx`
>> /sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
>> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
>> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>>
>> а)
>>
>> nginx version: nginx/1.16.0
>> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
>> built with OpenSSL 1.1.1b 26 Feb 2019
>> TLS SNI support enabled
>> configure arguments: --with-cc-opt='-g -O2 -fstack-protector
>> --param=ssp-buffer-size=4 -Wformat -Werror=format-security
>> -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
>> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
>> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
>> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
>> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
>> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
>> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
>> --with-http_flv_module --with-http_mp4_module
>> --with-http_stub_status_module --with-file-aio --with-threads
>> --with-http_v2_module --with-http_geoip_module
>> --with-http_image_filter_module --with-http_perl_module
>> --without-http_fastcgi_module --without-http_uwsgi_module
>> --without-http_scgi_module --without-http_memcached_module
>> --with-openssl=../openssl-1.1.1b --with-debug
>>
>> б)
>>
>> уже днём так и сделал
>>
>> в)
>>
>> make install вполне себе сделал дело
>> файл тот же
>>
>> ~/work/nginx-1.16.0/objs # sha1sum nginx
>> 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx
>>
>> ~/work/nginx-1.16.0/objs # ls -la nginx
>> -rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx
>>
>> ~/work/nginx-1.16.0/objs # ls -la /sbin/nginx
>> -rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx
>>
>> ~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx
>> 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx
>>
>> On 31 May 2019, 22:08 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>>
>> покажите вывод
>>
>> file `which nginx`
>>
>> ?
>>
>> и такой момент. как можно с минимальным риском подменить бинарник
>> а) смотрим "nginx -V"
>> б) берем исходники, компилируем их с всем, что есть в пункте "a)" и
>> добавляем --with-debug
>> в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем
>> руками этот бинарник вместо nginx, который в путях (ни в коем случае не
>> "make install")
>>
>> сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif на me.com>:
>>
>> получил плоды ожидания корок
>>
>> $ file /usr/sbin/nginx
>> /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
>> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
>> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>>
>> $ nm -g /usr/sbin/nginx | grep main
>> U __libc_start_main@@GLIBC_2.2.5
>> 000000000045a4c0 T main
>> 000000000048fdb0 T ngx_ssl_get_client_v_remain
>> 00000000005c9cf0 T rand_pool_bytes_remaining
>>
>>
>>
>> нападало две группы корок (то есть, осыпается сразу аж группами):
>>
>> -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
>> … всего порядка 20 штук за раз
>> -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
>>
>> и через пол часа:
>>
>> -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
>> … ешё 30 штук за раз
>> -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
>>
>>
>> падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес
>> 0x0…0)
>> но gdb символов в точке падения не видит:
>>
>> # gdb core.nginx.11620
>> GNU gdb (GDB) …
>> Missing separate debuginfo for the main executable file
>> Try: yum --enablerepo='*debug*' install
>> /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой
>> штуки нет)
>> Core was generated by `nginx: worker pr'.
>> Program terminated with signal 11, Segmentation fault.
>> #0 0x00007f8512e2ea1e in ?? ()
>> "/tmp/core.nginx.11620" is a core file.
>> Please specify an executable to debug.
>> (gdb) bt full
>> #0 0x00007f8512e2ea1e in ?? ()
>> No symbol table info available.
>> #1 0x0000000000000000 in ?? ()
>> No symbol table info available.
>> (gdb)
>>
>>
>> куда копать?
>>
>> On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>>
>> В error_log ничего на сегфолте не может записаться, нет особого смысла
>> его включать в debug
>>
>> По bt full больше инфы будет
>>
>> On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
>>
>> Илья, модули все из коробки
>>
>> ничего лишнего не доливаем
>>
>> из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
>>
>> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4
>> -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2'
>> --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
>> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
>> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
>> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
>> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
>> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
>> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
>> --with-http_flv_module --with-http_mp4_module
>> --with-http_stub_status_module --with-file-aio --with-threads
>> --with-http_v2_module --with-http_geoip_module
>> --with-http_image_filter_module --with-http_perl_module
>> --without-http_fastcgi_module --without-http_uwsgi_module
>> --without-http_scgi_module --without-http_memcached_module
>> --with-openssl=../openssl-1.1.1b --with-debug
>>
>> --with-debug ещё добавил только что на время теста… и уровень отладки
>> error_log включил debug
>> но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
>>
>> корки сейчас включу и буду ловить
>> но это ещё умудриться словить момент и дождаться, когда упадёт, может за
>> час несколько раз свалится
>>
>>
>> On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>>
>> привет!
>>
>> segfault - с очень-очень-очень большой вероятностью из-за сторонних
>> модулей nginx.
>>  можете показать вывод "nginx -V" ?
>>
>> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
>> отладкой, при это не strip-нуть ее в момент инсталяции
>> команда "file `which nginx`" должна показыват "not stripped"
>>
>> далее - в вашей операционной системе разрешаете сохранение core dump
>> (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>>
>> потом, берете сохраненный core dump, при помощи gdb открываете, делаете
>> "bt full", смотрите на чем именно упало.
>>
>> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>>
>> пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <
>> nginx-ru на nginx.org>:
>>
>> всем привет
>>
>> ПРОБЛЕМА
>>
>> давно (уже не первый год обновление за обновлением nginx и OpenSSL)
>> наблюдаем,
>> что ряд страниц при обновлении кэша входят в вечный статус UPDATING
>>
>> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
>>
>> происходит это совершенно на рандомных страницах, и способа воспроизвести
>> нет – только по прецедентной жалобе от пользователей, что закешированный
>> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи
>> всё в норму, но ждать до утра никто не хочет)
>>
>> КОНФИГУРАЦИЯ
>>
>> релевантные настройки такие:
>>
>> proxy_cache_use_stale error timeout invalid_header updating http_500
>> http_502 http_503 http_504;
>> proxy_cache_background_update on;
>> proxy_cache_lock on;
>> proxy_cache_lock_timeout 25s;
>>
>> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка
>> кастомная):
>>
>> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI
>> support enabled
>>
>> при этом:
>>
>> nginx -s reload # не помогает…
>>
>> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на
>> обновление бинарника):
>>
>> #!/usr/bin/env bash
>> # скрипт перезапуска или обновления бинарника:
>> sudo kill -s USR2 `cat /run/nginx.pid`
>> sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
>> echo 'waiting for 5 minutes required for graceful reload'
>> sleep 300
>> sudo kill -s TERM `cat /run/nginx.pid.oldbin`
>>
>> ЛОГИ И ДЕМО
>>
>> есть предположение, что это из-за эпозодического падения worker'ов (таких
>> набирается несколько десятков за день, при сотнях тысяч запросов)
>>
>> dmesg:
>>
>> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp
>> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
>> …
>>
>> error.log:
>>
>> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on
>> signal 11 (core dumped)
>> …
>>
>> подобные падения нас пресделуют много лет (их в день не много), на самых
>> разных версиях nginx, в разных ДЦ, на разных серверах, при разных
>> окружениях;
>> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно
>> падает…)
>>
>> наше предположение такое:
>>
>> воркер, который должен был обновить истёкшие данные умирает, а статус так
>> и остаётся UPDATING (на вечно),
>> всём клиентам отдаётся старый контент,
>> а новые воркеры уже не планируют запрос обновления с бэка
>>
>> вот свежий пример (в заголовке x-ireland-cache-status выводим значение
>> $upstream_cache_status):
>>
>> H27: ~ $ curl -I https://www.hse.ru/our/
>> HTTP/2 200
>> server: nginx
>> date: Thu, 30 May 2019 14:54:52 GMT
>> …
>> x-ireland-cache-status: UPDATING
>>
>> … можно очень долго ждать – статус так и будет UPDATING …
>>
>> H27: ~ $ curl -I https://www.hse.ru/our/
>> HTTP/2 200
>> server: nginx
>> date: Thu, 30 May 2019 14:56:47 GMT
>> …
>> x-ireland-cache-status: UPDATING
>>
>> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был
>> приведён выше):
>>
>> H27: ~ $ curl -I https://www.hse.ru/our/
>> HTTP/2 200
>> server: nginx
>> date: Thu, 30 May 2019 14:57:37 GMT
>> …
>> x-ireland-cache-status: STALE
>>
>> H27: ~ $ curl -I https://www.hse.ru/our/
>> HTTP/2 200
>> server: nginx
>> date: Thu, 30 May 2019 14:57:39 GMT
>> …
>> x-ireland-cache-status: HIT
>>
>> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём
>> следующего звоночка…
>>
>> у нас нет инструмента по отслеживанию «застрявших UPDATING»,
>> и нет способа точечно их пнуть
>> (если только не отслеживать $upstream_cache_status по каждому ресурсу и
>> переходы статусов со временем, которые в 99.99% переходят из UPDATING в
>> правильные статусы);
>>
>> приходится ждать только сигнала от недовольных пользователей…
>>
>> РЕЗЮМИРУЕМ
>>
>> ещё раз, сценарий, как мы видим откуда растёт проблема:
>>
>> 1. некоторая страница успешно кэшируется
>> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер
>> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч
>> запросов)
>> 3. никакой больше воркер это задание не получает до перезапуска nginx
>> 4. недовольные клиенты получают устаревший контент
>>
>> РЕШЕНИЕ?
>>
>> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
>>
>> какие варианты решения подобной проблемы существуют? в чём может быть
>> возможная причина?
>>
>> может есть рекомендации по дополнительным настройкам?
>>
>> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но
>> их (падения воркеров) надо учитывать в работе nginx:
>>
>> если это рассматривать как баг nginx – можно ли найти ему решение в
>> будущих обновлениях, в виде отправки повторной задачи воркерам на
>> обновление кэша, по таймауту?..
>>
>> _______________________________________________
>> 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/22ca4bd5/attachment-0001.html>

From mif на me.com  Fri May 31 19:34:38 2019
From: mif на me.com (Alexey Galygin)
Date: Fri, 31 May 2019 22:34:38 +0300
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <CAFHpkQFr2SbptYsEkyHqdti=t0cTx2vT6HYZHus8MzotMMRNmw@mail.gmail.com>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
 <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>
 <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>
 <CAFHpkQEScirKkxPu1r6hEG2pZ5_A0_8juvrVUL7Ea2TgTHhpew@mail.gmail.com>
 <CAFHpkQFr2SbptYsEkyHqdti=t0cTx2vT6HYZHus8MzotMMRNmw@mail.gmail.com>
Message-ID: <df135ef5-0a4d-4128-8649-4e7ba8c43f75@Spark>

пересобрал с -ggdb

NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # ./nginx -V
nginx version: nginx/1.16.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
built with OpenSSL 1.1.1b 26 Feb 2019
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -ggdb -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug

NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # file nginx
nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=f8e9db46a969468c67841dec62402c989797d188, not stripped

но про debug ничего действительно

у меня тестовый падающий пример собранный с -g:

int main()
{
int * a = 0x11122;
*a = 42;
}

тоже выдаёт

# file demo
demo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=a363cfe37d2fd364fb092ff07e8333fc26e2f9a5, not stripped

генерирует корку

(gdb) bt full
#0 0x00000000004004dd in ?? ()
No symbol table info available.
#1 0x0000000000000000 in ?? ()
No symbol table info available.

хотя днём удавалось его заставить писать хотя бы main() …

может дело в LXD-контейнере, ядро Ubuntu 16, гость CentOS 7 …
On 31 May 2019, 22:26 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> судя по официальному сборщику (и мы похожим образом делали), отладочные символы добавляются через --with-debug
>
> http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l116
>
> придумаю, что у вас - расскажу)) нет идей
>
> > сб, 1 июн. 2019 г. в 00:21, Илья Шипицин <chipitsine на gmail.com>:
> > > у программы, собранной с отладочными символами должно быть вот так (with debug_info, not stripped)
> > >
> > > [ilia на localhost ~]$ gcc -g 1.c
> > > [ilia на localhost ~]$ file a.out
> > > a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a767b5ee04499077d7685c5d353759d331846666, with debug_info, not stripped
> > > [ilia на localhost ~]$
> > >
> > > > сб, 1 июн. 2019 г. в 00:16, Alexey Galygin <mif на me.com>:
> > > > > на CentOS /sbin – симлинк на /usr/sbin
> > > > > which nginx даёт /sbin/nginx
> > > > >
> > > > > но файл тот же
> > > > >
> > > > > $ file `which nginx`
> > > > > /sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
> > > > >
> > > > > а)
> > > > >
> > > > > nginx version: nginx/1.16.0
> > > > > built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
> > > > > built with OpenSSL 1.1.1b 26 Feb 2019
> > > > > TLS SNI support enabled
> > > > > configure arguments: --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug
> > > > >
> > > > > б)
> > > > >
> > > > > уже днём так и сделал
> > > > >
> > > > > в)
> > > > >
> > > > > make install вполне себе сделал дело
> > > > > файл тот же
> > > > >
> > > > > ~/work/nginx-1.16.0/objs # sha1sum nginx
> > > > > 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx
> > > > >
> > > > > ~/work/nginx-1.16.0/objs # ls -la nginx
> > > > > -rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx
> > > > >
> > > > > ~/work/nginx-1.16.0/objs # ls -la /sbin/nginx
> > > > > -rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx
> > > > >
> > > > > ~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx
> > > > > 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx
> > > > >
> > > > > On 31 May 2019, 22:08 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> > > > > > покажите вывод
> > > > > >
> > > > > > file `which nginx`
> > > > > >
> > > > > > ?
> > > > > >
> > > > > > и такой момент. как можно с минимальным риском подменить бинарник
> > > > > > а) смотрим "nginx -V"
> > > > > > б) берем исходники, компилируем их с всем, что есть в пункте "a)" и добавляем --with-debug
> > > > > > в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем руками этот бинарник вместо nginx, который в путях (ни в коем случае не "make install")
> > > > > >
> > > > > > > сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif на me.com>:
> > > > > > > > получил плоды ожидания корок
> > > > > > > >
> > > > > > > > $ file /usr/sbin/nginx
> > > > > > > > /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
> > > > > > > >
> > > > > > > > $ nm -g /usr/sbin/nginx | grep main
> > > > > > > > U __libc_start_main@@GLIBC_2.2.5
> > > > > > > > 000000000045a4c0 T main
> > > > > > > > 000000000048fdb0 T ngx_ssl_get_client_v_remain
> > > > > > > > 00000000005c9cf0 T rand_pool_bytes_remaining
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > нападало две группы корок (то есть, осыпается сразу аж группами):
> > > > > > > >
> > > > > > > > -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
> > > > > > > > … всего порядка 20 штук за раз
> > > > > > > > -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
> > > > > > > >
> > > > > > > > и через пол часа:
> > > > > > > >
> > > > > > > > -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
> > > > > > > > … ешё 30 штук за раз
> > > > > > > > -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
> > > > > > > >
> > > > > > > >
> > > > > > > > падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес 0x0…0)
> > > > > > > > но gdb символов в точке падения не видит:
> > > > > > > >
> > > > > > > > # gdb core.nginx.11620
> > > > > > > > GNU gdb (GDB) …
> > > > > > > > Missing separate debuginfo for the main executable file
> > > > > > > > Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой штуки нет)
> > > > > > > > Core was generated by `nginx: worker pr'.
> > > > > > > > Program terminated with signal 11, Segmentation fault.
> > > > > > > > #0 0x00007f8512e2ea1e in ?? ()
> > > > > > > > "/tmp/core.nginx.11620" is a core file.
> > > > > > > > Please specify an executable to debug.
> > > > > > > > (gdb) bt full
> > > > > > > > #0 0x00007f8512e2ea1e in ?? ()
> > > > > > > > No symbol table info available.
> > > > > > > > #1 0x0000000000000000 in ?? ()
> > > > > > > > No symbol table info available.
> > > > > > > > (gdb)
> > > > > > > >
> > > > > > > >
> > > > > > > > куда копать?
> > > > > > > >
> > > > > > > > On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> > > > > > > > > В error_log ничего на сегфолте не может записаться, нет особого смысла его включать в debug
> > > > > > > > >
> > > > > > > > > По bt full больше инфы будет
> > > > > > > > >
> > > > > > > > > > On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
> > > > > > > > > > > Илья, модули все из коробки
> > > > > > > > > > >
> > > > > > > > > > > ничего лишнего не доливаем
> > > > > > > > > > >
> > > > > > > > > > > из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
> > > > > > > > > > >
> > > > > > > > > > > --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug
> > > > > > > > > > >
> > > > > > > > > > > --with-debug ещё добавил только что на время теста… и уровень отладки error_log включил debug
> > > > > > > > > > > но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
> > > > > > > > > > >
> > > > > > > > > > > корки сейчас включу и буду ловить
> > > > > > > > > > > но это ещё умудриться словить момент и дождаться, когда упадёт, может за час несколько раз свалится
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> > > > > > > > > > > > привет!
> > > > > > > > > > > >
> > > > > > > > > > > > segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей nginx.
> > > > > > > > > > > >  можете показать вывод "nginx -V" ?
> > > > > > > > > > > >
> > > > > > > > > > > > как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с отладкой, при это не strip-нуть ее в момент инсталяции
> > > > > > > > > > > > команда "file `which nginx`" должна показыват "not stripped"
> > > > > > > > > > > >
> > > > > > > > > > > > далее - в вашей операционной системе разрешаете сохранение core dump (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
> > > > > > > > > > > >
> > > > > > > > > > > > потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt full", смотрите на чем именно упало.
> > > > > > > > > > > >
> > > > > > > > > > > > если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
> > > > > > > > > > > >
> > > > > > > > > > > > > пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <nginx-ru на nginx.org>:
> > > > > > > > > > > > > > всем привет
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ПРОБЛЕМА
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,
> > > > > > > > > > > > > > что ряд страниц при обновлении кэша входят в вечный статус UPDATING
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > происходит это совершенно на рандомных страницах, и способа воспроизвести нет – только по прецедентной жалобе от пользователей, что закешированный контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи всё в норму, но ждать до утра никто не хочет)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > КОНФИГУРАЦИЯ
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > релевантные настройки такие:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
> > > > > > > > > > > > > > proxy_cache_background_update on;
> > > > > > > > > > > > > > proxy_cache_lock on;
> > > > > > > > > > > > > > proxy_cache_lock_timeout 25s;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка кастомная):
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI support enabled
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > при этом:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > nginx -s reload # не помогает…
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > а помогает только явный «мягкий» перезапуск сервера (процедура похожая на обновление бинарника):
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > #!/usr/bin/env bash
> > > > > > > > > > > > > > # скрипт перезапуска или обновления бинарника:
> > > > > > > > > > > > > > sudo kill -s USR2 `cat /run/nginx.pid`
> > > > > > > > > > > > > > sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> > > > > > > > > > > > > > echo 'waiting for 5 minutes required for graceful reload'
> > > > > > > > > > > > > > sleep 300
> > > > > > > > > > > > > > sudo kill -s TERM `cat /run/nginx.pid.oldbin`
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ЛОГИ И ДЕМО
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > есть предположение, что это из-за эпозодического падения worker'ов (таких набирается несколько десятков за день, при сотнях тысяч запросов)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > dmesg:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> > > > > > > > > > > > > > …
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > error.log:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 11 (core dumped)
> > > > > > > > > > > > > > …
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > подобные падения нас пресделуют много лет (их в день не много), на самых разных версиях nginx, в разных ДЦ, на разных серверах, при разных окружениях;
> > > > > > > > > > > > > > (по хорошему, надо включить сбор корок и попытаться разобраться, где оно падает…)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > наше предположение такое:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > воркер, который должен был обновить истёкшие данные умирает, а статус так и остаётся UPDATING (на вечно),
> > > > > > > > > > > > > > всём клиентам отдаётся старый контент,
> > > > > > > > > > > > > > а новые воркеры уже не планируют запрос обновления с бэка
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > вот свежий пример (в заголовке x-ireland-cache-status выводим значение $upstream_cache_status):
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > > > > > > > > > HTTP/2 200
> > > > > > > > > > > > > > server: nginx
> > > > > > > > > > > > > > date: Thu, 30 May 2019 14:54:52 GMT
> > > > > > > > > > > > > > …
> > > > > > > > > > > > > > x-ireland-cache-status: UPDATING
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > … можно очень долго ждать – статус так и будет UPDATING …
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > > > > > > > > > HTTP/2 200
> > > > > > > > > > > > > > server: nginx
> > > > > > > > > > > > > > date: Thu, 30 May 2019 14:56:47 GMT
> > > > > > > > > > > > > > …
> > > > > > > > > > > > > > x-ireland-cache-status: UPDATING
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён выше):
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > > > > > > > > > HTTP/2 200
> > > > > > > > > > > > > > server: nginx
> > > > > > > > > > > > > > date: Thu, 30 May 2019 14:57:37 GMT
> > > > > > > > > > > > > > …
> > > > > > > > > > > > > > x-ireland-cache-status: STALE
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > H27: ~ $ curl -I https://www.hse.ru/our/
> > > > > > > > > > > > > > HTTP/2 200
> > > > > > > > > > > > > > server: nginx
> > > > > > > > > > > > > > date: Thu, 30 May 2019 14:57:39 GMT
> > > > > > > > > > > > > > …
> > > > > > > > > > > > > > x-ireland-cache-status: HIT
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём следующего звоночка…
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> > > > > > > > > > > > > > и нет способа точечно их пнуть
> > > > > > > > > > > > > > (если только не отслеживать $upstream_cache_status по каждому ресурсу и переходы статусов со временем, которые в 99.99% переходят из UPDATING в правильные статусы);
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > приходится ждать только сигнала от недовольных пользователей…
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > РЕЗЮМИРУЕМ
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ещё раз, сценарий, как мы видим откуда растёт проблема:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. некоторая страница успешно кэшируется
> > > > > > > > > > > > > > 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)
> > > > > > > > > > > > > > 3. никакой больше воркер это задание не получает до перезапуска nginx
> > > > > > > > > > > > > > 4. недовольные клиенты получают устаревший контент
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > РЕШЕНИЕ?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > какие варианты решения подобной проблемы существуют? в чём может быть возможная причина?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > может есть рекомендации по дополнительным настройкам?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их (падения воркеров) надо учитывать в работе nginx:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > если это рассматривать как баг nginx – можно ли найти ему решение в будущих обновлениях, в виде отправки повторной задачи воркерам на обновление кэша, по таймауту?..
> > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > 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/20190531/2b6df576/attachment-0001.html>

From chipitsine на gmail.com  Fri May 31 19:45:20 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 1 Jun 2019 00:45:20 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <df135ef5-0a4d-4128-8649-4e7ba8c43f75@Spark>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
 <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>
 <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>
 <CAFHpkQEScirKkxPu1r6hEG2pZ5_A0_8juvrVUL7Ea2TgTHhpew@mail.gmail.com>
 <CAFHpkQFr2SbptYsEkyHqdti=t0cTx2vT6HYZHus8MzotMMRNmw@mail.gmail.com>
 <df135ef5-0a4d-4128-8649-4e7ba8c43f75@Spark>
Message-ID: <CAFHpkQGSKQABqWfeNMSnsZmDAxRCX4nLtLg1jpzS2ZqOJEk+JQ@mail.gmail.com>

сб, 1 июн. 2019 г. в 00:34, Alexey Galygin <mif на me.com>:

> пересобрал с -ggdb
>
> NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # ./nginx -V
> nginx version: nginx/1.16.0
> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
> built with OpenSSL 1.1.1b 26 Feb 2019
> TLS SNI support enabled
> configure arguments: --with-cc-opt='-g -ggdb -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # file nginx
> nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=f8e9db46a969468c67841dec62402c989797d188, not stripped
>
> но про debug ничего действительно
>
> у меня тестовый падающий пример собранный с -g:
>
> int main()
> {
> int * a = 0x11122;
> *a = 42;
> }
>
> тоже выдаёт
>
> # file demo
> demo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=a363cfe37d2fd364fb092ff07e8333fc26e2f9a5, not stripped
>
> генерирует корку
>
> (gdb) bt full
> #0 0x00000000004004dd in ?? ()
> No symbol table info available.
> #1 0x0000000000000000 in ?? ()
> No symbol table info available.
>
> хотя днём удавалось его заставить писать хотя бы main() …
>
> может дело в LXD-контейнере, ядро Ubuntu 16, гость CentOS 7 …
>

если пальцем в небо, можно попробовать в вашей конфигурации прогнать тесты
https://github.com/nginx/nginx-tests, возможно это покажет
на какую-то проблему в контейнере

(хотя, если честно, самое интересное, это конечно, получить бектрейс)



> On 31 May 2019, 22:26 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> судя по официальному сборщику (и мы похожим образом делали), отладочные
> символы добавляются через --with-debug
>
> http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l116
>
> придумаю, что у вас - расскажу)) нет идей
>
> сб, 1 июн. 2019 г. в 00:21, Илья Шипицин <chipitsine на gmail.com>:
>
> у программы, собранной с отладочными символами должно быть вот так (with
> debug_info, not stripped)
>
> [ilia на localhost ~]$ gcc -g 1.c
> [ilia на localhost ~]$ file a.out
> a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
> BuildID[sha1]=a767b5ee04499077d7685c5d353759d331846666, with debug_info,
> not stripped
> [ilia на localhost ~]$
>
> сб, 1 июн. 2019 г. в 00:16, Alexey Galygin <mif на me.com>:
>
> на CentOS /sbin – симлинк на /usr/sbin
> which nginx даёт /sbin/nginx
>
> но файл тот же
>
> $ file `which nginx`
> /sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>
> а)
>
> nginx version: nginx/1.16.0
> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
> built with OpenSSL 1.1.1b 26 Feb 2019
> TLS SNI support enabled
> configure arguments: --with-cc-opt='-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> б)
>
> уже днём так и сделал
>
> в)
>
> make install вполне себе сделал дело
> файл тот же
>
> ~/work/nginx-1.16.0/objs # sha1sum nginx
> 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx
>
> ~/work/nginx-1.16.0/objs # ls -la nginx
> -rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx
>
> ~/work/nginx-1.16.0/objs # ls -la /sbin/nginx
> -rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx
>
> ~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx
> 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx
>
> On 31 May 2019, 22:08 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> покажите вывод
>
> file `which nginx`
>
> ?
>
> и такой момент. как можно с минимальным риском подменить бинарник
> а) смотрим "nginx -V"
> б) берем исходники, компилируем их с всем, что есть в пункте "a)" и
> добавляем --with-debug
> в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем
> руками этот бинарник вместо nginx, который в путях (ни в коем случае не
> "make install")
>
> сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif на me.com>:
>
> получил плоды ожидания корок
>
> $ file /usr/sbin/nginx
> /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
> BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
>
> $ nm -g /usr/sbin/nginx | grep main
> U __libc_start_main@@GLIBC_2.2.5
> 000000000045a4c0 T main
> 000000000048fdb0 T ngx_ssl_get_client_v_remain
> 00000000005c9cf0 T rand_pool_bytes_remaining
>
>
>
> нападало две группы корок (то есть, осыпается сразу аж группами):
>
> -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
> … всего порядка 20 штук за раз
> -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
>
> и через пол часа:
>
> -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
> … ешё 30 штук за раз
> -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
>
>
> падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес
> 0x0…0)
> но gdb символов в точке падения не видит:
>
> # gdb core.nginx.11620
> GNU gdb (GDB) …
> Missing separate debuginfo for the main executable file
> Try: yum --enablerepo='*debug*' install
> /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой
> штуки нет)
> Core was generated by `nginx: worker pr'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007f8512e2ea1e in ?? ()
> "/tmp/core.nginx.11620" is a core file.
> Please specify an executable to debug.
> (gdb) bt full
> #0 0x00007f8512e2ea1e in ?? ()
> No symbol table info available.
> #1 0x0000000000000000 in ?? ()
> No symbol table info available.
> (gdb)
>
>
> куда копать?
>
> On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> В error_log ничего на сегфолте не может записаться, нет особого смысла его
> включать в debug
>
> По bt full больше инфы будет
>
> On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif на me.com> wrote:
>
> Илья, модули все из коробки
>
> ничего лишнего не доливаем
>
> из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
>
> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2'
> --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
> --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
> --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
> --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot
> --with-http_ssl_module --with-http_realip_module --with-http_sub_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_stub_status_module --with-file-aio --with-threads
> --with-http_v2_module --with-http_geoip_module
> --with-http_image_filter_module --with-http_perl_module
> --without-http_fastcgi_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --with-openssl=../openssl-1.1.1b --with-debug
>
> --with-debug ещё добавил только что на время теста… и уровень отладки
> error_log включил debug
> но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
>
> корки сейчас включу и буду ловить
> но это ещё умудриться словить момент и дождаться, когда упадёт, может за
> час несколько раз свалится
>
>
> On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
>
> привет!
>
> segfault - с очень-очень-очень большой вероятностью из-за сторонних
> модулей nginx.
>  можете показать вывод "nginx -V" ?
>
> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
> отладкой, при это не strip-нуть ее в момент инсталяции
> команда "file `which nginx`" должна показыват "not stripped"
>
> далее - в вашей операционной системе разрешаете сохранение core dump
> (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>
> потом, берете сохраненный core dump, при помощи gdb открываете, делаете
> "bt full", смотрите на чем именно упало.
>
> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>
> пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <
> nginx-ru на nginx.org>:
>
> всем привет
>
> ПРОБЛЕМА
>
> давно (уже не первый год обновление за обновлением nginx и OpenSSL)
> наблюдаем,
> что ряд страниц при обновлении кэша входят в вечный статус UPDATING
>
> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
>
> происходит это совершенно на рандомных страницах, и способа воспроизвести
> нет – только по прецедентной жалобе от пользователей, что закешированный
> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи
> всё в норму, но ждать до утра никто не хочет)
>
> КОНФИГУРАЦИЯ
>
> релевантные настройки такие:
>
> proxy_cache_use_stale error timeout invalid_header updating http_500
> http_502 http_503 http_504;
> proxy_cache_background_update on;
> proxy_cache_lock on;
> proxy_cache_lock_timeout 25s;
>
> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка
> кастомная):
>
> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI
> support enabled
>
> при этом:
>
> nginx -s reload # не помогает…
>
> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на
> обновление бинарника):
>
> #!/usr/bin/env bash
> # скрипт перезапуска или обновления бинарника:
> sudo kill -s USR2 `cat /run/nginx.pid`
> sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> echo 'waiting for 5 minutes required for graceful reload'
> sleep 300
> sudo kill -s TERM `cat /run/nginx.pid.oldbin`
>
> ЛОГИ И ДЕМО
>
> есть предположение, что это из-за эпозодического падения worker'ов (таких
> набирается несколько десятков за день, при сотнях тысяч запросов)
>
> dmesg:
>
> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp
> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> …
>
> error.log:
>
> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on
> signal 11 (core dumped)
> …
>
> подобные падения нас пресделуют много лет (их в день не много), на самых
> разных версиях nginx, в разных ДЦ, на разных серверах, при разных
> окружениях;
> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно
> падает…)
>
> наше предположение такое:
>
> воркер, который должен был обновить истёкшие данные умирает, а статус так
> и остаётся UPDATING (на вечно),
> всём клиентам отдаётся старый контент,
> а новые воркеры уже не планируют запрос обновления с бэка
>
> вот свежий пример (в заголовке x-ireland-cache-status выводим значение
> $upstream_cache_status):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:54:52 GMT
> …
> x-ireland-cache-status: UPDATING
>
> … можно очень долго ждать – статус так и будет UPDATING …
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:56:47 GMT
> …
> x-ireland-cache-status: UPDATING
>
> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был
> приведён выше):
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:37 GMT
> …
> x-ireland-cache-status: STALE
>
> H27: ~ $ curl -I https://www.hse.ru/our/
> HTTP/2 200
> server: nginx
> date: Thu, 30 May 2019 14:57:39 GMT
> …
> x-ireland-cache-status: HIT
>
> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём
> следующего звоночка…
>
> у нас нет инструмента по отслеживанию «застрявших UPDATING»,
> и нет способа точечно их пнуть
> (если только не отслеживать $upstream_cache_status по каждому ресурсу и
> переходы статусов со временем, которые в 99.99% переходят из UPDATING в
> правильные статусы);
>
> приходится ждать только сигнала от недовольных пользователей…
>
> РЕЗЮМИРУЕМ
>
> ещё раз, сценарий, как мы видим откуда растёт проблема:
>
> 1. некоторая страница успешно кэшируется
> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер
> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч
> запросов)
> 3. никакой больше воркер это задание не получает до перезапуска nginx
> 4. недовольные клиенты получают устаревший контент
>
> РЕШЕНИЕ?
>
> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
>
> какие варианты решения подобной проблемы существуют? в чём может быть
> возможная причина?
>
> может есть рекомендации по дополнительным настройкам?
>
> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но
> их (падения воркеров) надо учитывать в работе nginx:
>
> если это рассматривать как баг nginx – можно ли найти ему решение в
> будущих обновлениях, в виде отправки повторной задачи воркерам на
> обновление кэша, по таймауту?..
>
> _______________________________________________
> 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/44e5e951/attachment-0001.html>

From mif на me.com  Fri May 31 20:32:04 2019
From: mif на me.com (Alexey Galygin)
Date: Fri, 31 May 2019 23:32:04 +0300
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <CAFHpkQGSKQABqWfeNMSnsZmDAxRCX4nLtLg1jpzS2ZqOJEk+JQ@mail.gmail.com>
References: <99f0dea2-ae35-4ff0-87f0-ed1e346cba3d@Spark>
 <6d532b4d-4db2-4571-8661-65e9869e805b@Spark>
 <c1375914-309a-4496-a978-a30980b2694c@Spark>
 <db4a027e-3baa-471d-a615-78304ef1813b@Spark>
 <CAFHpkQFCc0Q6vFZK5DA4GJJ-5Pjybcg58a_9ARrOaC=_9AOQPg@mail.gmail.com>
 <45b86231-c633-443d-ab30-6f12f59243a9@Spark>
 <CAFHpkQE1=XDQx-g4n0=FgybPFjiqt1MQiYbzyzwYW2y_iXQFxg@mail.gmail.com>
 <b389da77-6af7-4ebb-9027-5302035909d6@Spark>
 <CAFHpkQG6Eq6eVReZ0+NOui5feJqVdmzZzV-35i_NHfNWtsMfcg@mail.gmail.com>
 <8c9d9f61-4ef6-40da-a55d-bc6204306a67@Spark>
 <CAFHpkQEScirKkxPu1r6hEG2pZ5_A0_8juvrVUL7Ea2TgTHhpew@mail.gmail.com>
 <CAFHpkQFr2SbptYsEkyHqdti=t0cTx2vT6HYZHus8MzotMMRNmw@mail.gmail.com>
 <df135ef5-0a4d-4128-8649-4e7ba8c43f75@Spark>
 <CAFHpkQGSKQABqWfeNMSnsZmDAxRCX4nLtLg1jpzS2ZqOJEk+JQ@mail.gmail.com>
Message-ID: <4629586a-6a30-4b84-a701-ac32ad230483@Spark>

с тестами попробовал на (тавтология) тестовой среде
худо бедно шло, в целом даже хорошо, но на одном это всё подвисло…

удалось разобрать корки всё же (доставить символы и правильно всё скормить gdb)

как я и предполагал – падает в наших кастомных Perl модулях на уровне nginx при отправке данных файлов:


#0 ngx_http_perl_output (r=r на entry=0x19b9960, b=b на entry=0x19bb520) at nginx.xs:76
out = {buf = 0x0, next = 0x19b9960}
cl = <optimized out>
ctx = 0x0

#1 0x00007f8512e2fc91 in XS_nginx_sendfile (my_perl=0xc7b700, cv=<optimized out>) at nginx.xs:751
bytes = 1397297
clcf = 0x13d5378
r = 0x19b9960
filename = <optimized out>
offset = 0
path = {len = 122, …


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

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


> >
> > если пальцем в небо, можно попробовать в вашей конфигурации прогнать тесты https://github.com/nginx/nginx-tests, возможно это покажет
> > на какую-то проблему в контейнере
> >
> > (хотя, если честно, самое интересное, это конечно, получить бектрейс)
> >
> >
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190531/d17f4ab1/attachment.html>

From nginx-forum на forum.nginx.org  Fri May 31 20:50:28 2019
From: nginx-forum на forum.nginx.org (ngnx8810773a83)
Date: Fri, 31 May 2019 16:50:28 -0400
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <4629586a-6a30-4b84-a701-ac32ad230483@Spark>
References: <4629586a-6a30-4b84-a701-ac32ad230483@Spark>
Message-ID: <8a61154607f5f49bcfb184d9e3118078.NginxMailingListRussian@forum.nginx.org>

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

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

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


From mif на me.com  Fri May 31 20:57:56 2019
From: mif на me.com (Alexey Galygin)
Date: Fri, 31 May 2019 23:57:56 +0300
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <8a61154607f5f49bcfb184d9e3118078.NginxMailingListRussian@forum.nginx.org>
References: <4629586a-6a30-4b84-a701-ac32ad230483@Spark>
 <8a61154607f5f49bcfb184d9e3118078.NginxMailingListRussian@forum.nginx.org>
Message-ID: <9c1fae5f-8755-4a65-ab5d-d7390622b4cc@Spark>

понятно, спасибо
подумаем над отдельным инстансом

на всякий случай я тикет завёл

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

From nginx-forum на forum.nginx.org  Fri May 31 21:07:18 2019
From: nginx-forum на forum.nginx.org (valet)
Date: Fri, 31 May 2019 17:07:18 -0400
Subject: =?UTF-8?B?c2VydmVyIG5hbWUg0YEg0LzQsNGB0LrQsNC80Lgg0LIg0YDQsNC30L3Ri9C1INC6?=
 =?UTF-8?B?0L7QvdGE0LjQs9C4?=
Message-ID: <e7bad74624e04af3d7c094ecc59d7fa6.NginxMailingListRussian@forum.nginx.org>

Есть 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.*

Но это работает неправильно. Подскажите пожалуйста как правильно?

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


From nginx на mva.name  Fri May 31 22:11:52 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sat, 01 Jun 2019 01:11:52 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?=
In-Reply-To: <2632802.ZtBez7UN1Q@vbart-workstation>
References: <2632802.ZtBez7UN1Q@vbart-workstation>
Message-ID: <46149569.rYzD3Nl9ea@note>

Вот бы ещё дождаться per-applicaton access и error-логов (с возможностью 
указания путей)... :D

From nginx на mva.name  Fri May 31 22:13:27 2019
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Sat, 01 Jun 2019 01:13:27 +0300
Subject: Unitd + client_addr
In-Reply-To: <CAM_jxg2ebcKT6tJ7U1OkB2n5yFhbY3Em8eQ08+o3wmLp6n1h5A@mail.gmail.com>
References: <CAM_jxg2ebcKT6tJ7U1OkB2n5yFhbY3Em8eQ08+o3wmLp6n1h5A@mail.gmail.com>
Message-ID: <2385316.CC1pGO3oQu@note>

Если проксируется сквозь NginX, то, вроде как, вообще никаких проблем положить 
IP в какой-нибудь X-заголовок и брать оттуда...

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


From chipitsine на gmail.com  Fri May 31 22:19:44 2019
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 1 Jun 2019 03:19:44 +0500
Subject: =?UTF-8?B?UmU6INCS0LXRh9C90YvQuSBVUERBVElORyDQtNC70Y8g0YDQsNC90LTQvtC80L0=?=
 =?UTF-8?B?0YvRhSDRgdGC0YDQsNC90LjRhiDQv9C+0YDRgtCw0LvQsA==?=
In-Reply-To: <9c1fae5f-8755-4a65-ab5d-d7390622b4cc@Spark>
References: <4629586a-6a30-4b84-a701-ac32ad230483@Spark>
 <8a61154607f5f49bcfb184d9e3118078.NginxMailingListRussian@forum.nginx.org>
 <9c1fae5f-8755-4a65-ab5d-d7390622b4cc@Spark>
Message-ID: <CAFHpkQE79aTtDAsy7d=X-LB9CxREf5MgmGPk2E+1X2Dp1jzbFw@mail.gmail.com>

а попробуйте вот так

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/679e743f/attachment.html>

From swood на fotofor.biz  Fri May 31 22:21:10 2019
From: swood на fotofor.biz (Anton Kiryushkin)
Date: Fri, 31 May 2019 23:21:10 +0100
Subject: Unitd + client_addr
In-Reply-To: <2385316.CC1pGO3oQu@note>
References: <CAM_jxg2ebcKT6tJ7U1OkB2n5yFhbY3Em8eQ08+o3wmLp6n1h5A@mail.gmail.com>
 <2385316.CC1pGO3oQu@note>
Message-ID: <CAM_jxg3Zs+tQYNuGZSHjJ8CrXtFvi3tX+L47bG-0uefXYQd3MQ@mail.gmail.com>

Конечно, нет никаких проблем положить в X-Real-IP.
Однако, мой вопрос был про REMOTE_ADDR.

пт, 31 мая 2019 г. в 23:13, Vadim A. Misbakh-Soloviov <nginx на mva.name>:

> Если проксируется сквозь NginX, то, вроде как, вообще никаких проблем
> положить
> IP в какой-нибудь X-заголовок и брать оттуда...
>
> В письме от пятница, 31 мая 2019 г. 18:51:15 MSK пользователь Anton
> Kiryushkin
> написал:
> > Здравствуйте.
> >
> > Не подскажете, какова судьба вот этого тикета:
> > https://github.com/nginx/unit/issues/132
> >
> > А так же, возможно, есть прямой способ, как получить в php, запускаемом
> > через unit клиентский айпишник? Сейчас там 127.0.0.1, что очень и очень
> > плохо и ставит использование unit под жирный вопрос.
> >
> > --
> > Best regards,
> > Anton Kiryushkin
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



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