From earthquake_90 at mail.ru Sun Jul 7 13:39:17 2024 From: earthquake_90 at mail.ru (Ivan Strelnikov) Date: Sun, 7 Jul 2024 16:39:17 +0300 Subject: nginx pgp key nginx_signing.key Message-ID: Hello! Many years ago i started use `nginx_signing.key` from this url: `https://nginx.org/packages/keys/nginx_signing.key` but now i find out that it is expired and outdated. Fresh key is here: `https://nginx.org/keys/nginx_signing.key` and i think maybe there is a mistake that old key file is exist or outdated? Maybe we should update it or please explain me if i wrong. P.S. Sorry, if this is wrong place for this kind of questions, i can't find more proper one. -- Ivan From srebecchi at kameleoon.com Tue Jul 9 13:52:11 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Tue, 9 Jul 2024 15:52:11 +0200 Subject: Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2. Message-ID: Hi! We are using nginx a lot in our company for high HTTP/2 workloads. I saw freenginx has applied a bugfix in their last mainline release 1.27.1, see https://freenginx.org/en/CHANGES *) Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2. Thanks to Kasei Wang. I wanted to know if there was a plan to apply that fix also in nginx, cause I see that worker processes are in practise very long to shut down (12 worker processes, when reload signal is sent then it takes more than 3 minutes until the last worker is down), which is a problem in our case. Thank you Sébastien -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at maltris.org Wed Jul 10 17:09:42 2024 From: m at maltris.org (Malte Schmidt) Date: Wed, 10 Jul 2024 19:09:42 +0200 Subject: =?utf-8?q?proxy=5Fbind/splitting?= with nginx mail module for IMAP Message-ID: <52-668ec080-3-19db7940@223528520> I am currently working on a setup using nginx mail module with several backends. Due to port exhaustion, I would like to do splitting of outgoing connections across several IPs. For http this is well documented, but for the mail module I could not find anything. Simply trying "proxy_bind" in the mail{}-config does not yield any success, because it is forbidden in this context. How would you tackle port exhaustion with many long-running IMAP connections? Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From osa at freebsd.org.ru Wed Jul 10 17:20:08 2024 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Wed, 10 Jul 2024 20:20:08 +0300 Subject: proxy_bind/splitting with nginx mail module for IMAP In-Reply-To: <52-668ec080-3-19db7940@223528520> References: <52-668ec080-3-19db7940@223528520> Message-ID: Hi Malte, hope you're doing well. On Wed, Jul 10, 2024 at 07:09:42PM +0200, Malte Schmidt via nginx wrote: > > I am currently working on a setup using nginx mail module with several > backends. Due to port exhaustion, I would like to do splitting of outgoing > connections across several IPs. For http this is well documented, but for > the mail module I could not find anything. Simply trying "proxy_bind" in > the mail{}-config does not yield any success, because it is forbidden in > this context. > > How would you tackle port exhaustion with many long-running IMAP connections? A quick look into the source code shows there's no such functionality available for the mail module. That's probably possible to create a solution based on the stream module, where such functionality exists. Thank you. -- Sergey A. Osokin From arut at nginx.com Thu Jul 11 09:12:03 2024 From: arut at nginx.com (Roman Arutyunyan) Date: Thu, 11 Jul 2024 13:12:03 +0400 Subject: Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2. In-Reply-To: References: Message-ID: Hi Sébastien, > On 9 Jul 2024, at 5:52 PM, Sébastien Rebecchi wrote: > > Hi! > > We are using nginx a lot in our company for high HTTP/2 workloads. > > I saw freenginx has applied a bugfix in their last mainline release 1.27.1, see https://freenginx.org/en/CHANGES > *) Bugfix: graceful shutdown of old worker processes might be delayed > when using HTTP/2. > Thanks to Kasei Wang. > I wanted to know if there was a plan to apply that fix also in nginx, cause I see that worker processes are in practise very long to shut down (12 worker processes, when reload signal is sent then it takes more than 3 minutes until the last worker is down), which is a problem in our case. Yes, this works started in April and was suspended due to switching to other important tasks. We will finish it shortly. Thanks for bringing this up. ---- Roman Arutyunyan arut at nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From arut at nginx.com Thu Jul 11 09:12:03 2024 From: arut at nginx.com (Roman Arutyunyan) Date: Thu, 11 Jul 2024 13:12:03 +0400 Subject: Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2. In-Reply-To: References: Message-ID: Hi Sébastien, > On 9 Jul 2024, at 5:52 PM, Sébastien Rebecchi wrote: > > Hi! > > We are using nginx a lot in our company for high HTTP/2 workloads. > > I saw freenginx has applied a bugfix in their last mainline release 1.27.1, see https://freenginx.org/en/CHANGES > *) Bugfix: graceful shutdown of old worker processes might be delayed > when using HTTP/2. > Thanks to Kasei Wang. > I wanted to know if there was a plan to apply that fix also in nginx, cause I see that worker processes are in practise very long to shut down (12 worker processes, when reload signal is sent then it takes more than 3 minutes until the last worker is down), which is a problem in our case. Yes, this works started in April and was suspended due to switching to other important tasks. We will finish it shortly. Thanks for bringing this up. ---- Roman Arutyunyan arut at nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From srebecchi at kameleoon.com Thu Jul 11 09:51:22 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Thu, 11 Jul 2024 11:51:22 +0200 Subject: Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2. In-Reply-To: References: Message-ID: Thanks Roman, I am expecting that :) Le jeu. 11 juil. 2024 à 11:12, Roman Arutyunyan a écrit : > Hi Sébastien, > > On 9 Jul 2024, at 5:52 PM, Sébastien Rebecchi > wrote: > > Hi! > > We are using nginx a lot in our company for high HTTP/2 workloads. > > I saw freenginx has applied a bugfix in their last mainline release > 1.27.1, see https://freenginx.org/en/CHANGES > > *) Bugfix: graceful shutdown of old worker processes might be delayed > when using HTTP/2. > Thanks to Kasei Wang. > > I wanted to know if there was a plan to apply that fix also in nginx, cause I see that worker processes are in practise very long to shut down (12 worker processes, when reload signal is sent then it takes more than 3 minutes until the last worker is down), which is a problem in our case. > > Yes, this works started in April and was suspended due to switching to > other important tasks. > > We will finish it shortly. > > Thanks for bringing this up. > > ---- > Roman Arutyunyan > arut at nginx.com > > > > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thresh at nginx.com Thu Jul 11 20:41:13 2024 From: thresh at nginx.com (Konstantin Pavlov) Date: Thu, 11 Jul 2024 13:41:13 -0700 Subject: nginx pgp key nginx_signing.key In-Reply-To: References: Message-ID: Hi Ivan! On 07/07/2024 6:39 AM, Ivan Strelnikov via nginx wrote: > Hello! > > Many years ago i started use `nginx_signing.key` from this url: > `https://nginx.org/packages/keys/nginx_signing.key` but now i find out > that it is expired and outdated. > > Fresh key is here: `https://nginx.org/keys/nginx_signing.key` and i > think maybe there is a mistake that old key file is exist or outdated? > > Maybe we should update it or please explain me if i wrong. > P.S. Sorry, if this is wrong place for this kind of questions, i can't > find more proper one. Thanks for using our packages! This location was not updated when we moved to the new set of keys...  I've fixed that now. In any case I'd suggest moving to the paths we have documented on https://nginx.org/en/linux_packages.html if it's possible. Have a good one, From srebecchi at kameleoon.com Tue Jul 16 15:08:10 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Tue, 16 Jul 2024 17:08:10 +0200 Subject: Upgrading Executable on the Fly Message-ID: Hello Reading this doc seems unclear to me https://nginx.org/en/docs/control.html#upgrade According to it, we should do kill -USR2 $nginxPid kill -WINCH $nginxPid kill -QUIT $nginxPid with $nginxPid the pid of the old nginx. But doing that seems not good cause we have a strange behaviour that old nginx worker processes are shutting down but no new master and workers are spawned If I add a sleep time before sending the QUIT signal then all is good, for ex sleep 20; between the WINCH and QUIT. How to explain that? It seems nginx receiving QUIT before processing the USR2 ignored messages received before and just ignores it? Or what is the explanation? And how to solve that properly cause sleeping seems not a clean workaround. I need an automatic procedure, not to have to manually look at what happens on all my servers during upgrade. Best regards, Sébastien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arut at nginx.com Thu Jul 18 13:53:37 2024 From: arut at nginx.com (Roman Arutyunyan) Date: Thu, 18 Jul 2024 17:53:37 +0400 Subject: Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2. In-Reply-To: References: Message-ID: <2018B257-5B63-45A5-ABD7-CC298BD5B56A@nginx.com> Hello, > On 11 Jul 2024, at 1:12 PM, Roman Arutyunyan wrote: > > Hi Sébastien, > >> On 9 Jul 2024, at 5:52 PM, Sébastien Rebecchi wrote: >> >> Hi! >> >> We are using nginx a lot in our company for high HTTP/2 workloads. >> >> I saw freenginx has applied a bugfix in their last mainline release 1.27.1, see https://freenginx.org/en/CHANGES >> *) Bugfix: graceful shutdown of old worker processes might be delayed >> when using HTTP/2. >> Thanks to Kasei Wang. >> I wanted to know if there was a plan to apply that fix also in nginx, cause I see that worker processes are in practise very long to shut down (12 worker processes, when reload signal is sent then it takes more than 3 minutes until the last worker is down), which is a problem in our case. > Yes, this works started in April and was suspended due to switching to other important tasks. > > We will finish it shortly. > > Thanks for bringing this up. > > ---- > Roman Arutyunyan > arut at nginx.com Patch committed: https://hg.nginx.org/nginx/rev/d1b8568f3042 ---- Roman Arutyunyan arut at nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From srebecchi at kameleoon.com Thu Jul 18 14:11:10 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Thu, 18 Jul 2024 16:11:10 +0200 Subject: Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2. In-Reply-To: <2018B257-5B63-45A5-ABD7-CC298BD5B56A@nginx.com> References: <2018B257-5B63-45A5-ABD7-CC298BD5B56A@nginx.com> Message-ID: Thanks Roman! Le jeu. 18 juil. 2024 à 15:53, Roman Arutyunyan a écrit : > Hello, > > On 11 Jul 2024, at 1:12 PM, Roman Arutyunyan wrote: > > Hi Sébastien, > > On 9 Jul 2024, at 5:52 PM, Sébastien Rebecchi > wrote: > > Hi! > > We are using nginx a lot in our company for high HTTP/2 workloads. > > I saw freenginx has applied a bugfix in their last mainline release > 1.27.1, see https://freenginx.org/en/CHANGES > > *) Bugfix: graceful shutdown of old worker processes might be delayed > when using HTTP/2. > Thanks to Kasei Wang. > > I wanted to know if there was a plan to apply that fix also in nginx, cause I see that worker processes are in practise very long to shut down (12 worker processes, when reload signal is sent then it takes more than 3 minutes until the last worker is down), which is a problem in our case. > > Yes, this works started in April and was suspended due to switching to > other important tasks. > > We will finish it shortly. > > Thanks for bringing this up. > > ---- > Roman Arutyunyan > arut at nginx.com > > > Patch committed: > > https://hg.nginx.org/nginx/rev/d1b8568f3042 > > ---- > Roman Arutyunyan > arut at nginx.com > > > > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srebecchi at kameleoon.com Thu Jul 18 14:25:43 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Thu, 18 Jul 2024 16:25:43 +0200 Subject: Upgrading Executable on the Fly In-Reply-To: References: Message-ID: Hello I understand that sending signals is async so there is no guarantee that QUIT is not processed before USR2 so nginx receiving QUIT will ignore USR2 if received after QUIT. I think of a faster solution still being safe kill -USR2 $nginxPid *ADDED: wait until nginx pid file has a content different than $nginxPid* kill -WINCH $nginxPid kill -QUIT $nginxPid so that if nginx pid file content has changed it means a new master was spawned. I have a question then: does nginx master writes its pid to the file only after having spawned workers, or could it be a small amount of time where a pid file will exist with a new content while only master is alive and workers are not spawned yet? In that case it would mean i still need to wait a bit, probably by ensuring there is at least 1 worker process alive with ppid the pid of the new master. best regards, Sébastien Le mar. 16 juil. 2024 à 17:08, Sébastien Rebecchi a écrit : > Hello > > Reading this doc seems unclear to me > https://nginx.org/en/docs/control.html#upgrade > > According to it, we should do > > kill -USR2 $nginxPid > kill -WINCH $nginxPid > kill -QUIT $nginxPid > > with $nginxPid the pid of the old nginx. > > But doing that seems not good cause we have a strange behaviour that old > nginx worker processes are shutting down but no new master and workers are > spawned > > If I add a sleep time before sending the QUIT signal then all is good, for > ex sleep 20; between the WINCH and QUIT. > > How to explain that? It seems nginx receiving QUIT before processing > the USR2 ignored messages received before and just ignores it? Or what is > the explanation? And how to solve that properly cause sleeping seems not a > clean workaround. I need an automatic procedure, not to have to manually > look at what happens on all my servers during upgrade. > > Best regards, > > Sébastien. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangjiahao at openresty.com Mon Jul 22 07:45:44 2024 From: wangjiahao at openresty.com (Jiahao Wang) Date: Mon, 22 Jul 2024 15:45:44 +0800 Subject: [ANN] OpenResty 1.25.3.2 released Message-ID: Hi folks, I am happy to announce the new formal release, 1.25.3.2, of our OpenResty web platform based on NGINX and LuaJIT. OpenResty 1.25.3.2 is a security update addressing a performance issue in our OpenResty branch of LuaJIT related to hash computation optimization. This update disables a specific optimization in our LuaJIT fork that could potentially lead to performance degradation under certain circumstances (CVE-2024-39702). It's important to note that this issue is specific to our OpenResty branch of LuaJIT and does not affect the upstream mainline LuaJIT. We would like to express our gratitude to Zhongwei Yao from Kong INC. for reporting this issue. The full announcement, download links, and change logs can be found below: http://openresty.org/en/ann-1025003002.html You can download the software packages here: https://openresty.org/en/download.html OpenResty is a high performance and dynamic web platform based on our enhanced version of Nginx core, our enhanced version of LuaJIT, and many powerful Nginx modules and Lua libraries. See OpenResty's homepage for details: https://openresty.org/en/ We strongly recommend all users to upgrade to this version to ensure optimal performance and security. OpenResty Inc. provides commercial support and private module development for the open-source OpenResty. For more information, please visit https://openresty.com. Enjoy! Best regards, Jiahao -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas at lucasrolff.com Mon Jul 22 08:04:42 2024 From: lucas at lucasrolff.com (Lucas Rolff) Date: Mon, 22 Jul 2024 08:04:42 +0000 Subject: [ANN] OpenResty 1.25.3.2 released In-Reply-To: References: Message-ID: Is there any ETA for new docker builds of openresty for this as well? Sent from Outlook for iOS ________________________________ From: nginx on behalf of Jiahao Wang via nginx Sent: Monday, July 22, 2024 9:45:44 AM To: nginx at nginx.org Cc: Jiahao Wang Subject: [ANN] OpenResty 1.25.3.2 released Hi folks, I am happy to announce the new formal release, 1.25.3.2, of our OpenResty web platform based on NGINX and LuaJIT. OpenResty 1.25.3.2 is a security update addressing a performance issue in our OpenResty branch of LuaJIT related to hash computation optimization. This update disables a specific optimization in our LuaJIT fork that could potentially lead to performance degradation under certain circumstances (CVE-2024-39702). It's important to note that this issue is specific to our OpenResty branch of LuaJIT and does not affect the upstream mainline LuaJIT. We would like to express our gratitude to Zhongwei Yao from Kong INC. for reporting this issue. The full announcement, download links, and change logs can be found below: http://openresty.org/en/ann-1025003002.html You can download the software packages here: https://openresty.org/en/download.html OpenResty is a high performance and dynamic web platform based on our enhanced version of Nginx core, our enhanced version of LuaJIT, and many powerful Nginx modules and Lua libraries. See OpenResty's homepage for details: https://openresty.org/en/ We strongly recommend all users to upgrade to this version to ensure optimal performance and security. OpenResty Inc. provides commercial support and private module development for the open-source OpenResty. For more information, please visit https://openresty.com. Enjoy! Best regards, Jiahao -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at mheard.com Mon Jul 22 08:09:40 2024 From: me at mheard.com (Mathew Heard) Date: Mon, 22 Jul 2024 18:09:40 +1000 Subject: [ANN] OpenResty 1.25.3.2 released In-Reply-To: References: Message-ID: Now that there is a patch out could you please share more information on those "specific circumstances"? It looks to me that luajit2 does not support SSE4.2 whereas agentzh's fork does. And this is what has been disabled in this release. Is this an interim release while the cause is investigated or is it fully understood? On Mon, 22 Jul 2024 at 17:46, Jiahao Wang via nginx wrote: > > Hi folks, > > I am happy to announce the new formal release, 1.25.3.2, of our OpenResty web platform based on NGINX and LuaJIT. > > OpenResty 1.25.3.2 is a security update addressing a performance issue in our OpenResty branch of LuaJIT related to hash computation optimization. This update disables a specific optimization in our LuaJIT fork that could potentially lead to performance degradation under certain circumstances (CVE-2024-39702). > > It's important to note that this issue is specific to our OpenResty branch of LuaJIT and does not affect the upstream mainline LuaJIT. > > We would like to express our gratitude to Zhongwei Yao from Kong INC. for reporting this issue. > > The full announcement, download links, and change logs can be found below: > > http://openresty.org/en/ann-1025003002.html > > You can download the software packages here: > > https://openresty.org/en/download.html > > OpenResty is a high performance and dynamic web platform based on our enhanced version of Nginx core, our enhanced version of LuaJIT, and many powerful Nginx modules and Lua libraries. See OpenResty's homepage for details: > > https://openresty.org/en/ > > We strongly recommend all users to upgrade to this version to ensure optimal performance and security. > > OpenResty Inc. provides commercial support and private module development for the open-source OpenResty. For more information, please visit https://openresty.com. > > Enjoy! > > Best regards, > Jiahao > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx From wangjiahao at openresty.com Mon Jul 22 08:45:22 2024 From: wangjiahao at openresty.com (Jiahao Wang) Date: Mon, 22 Jul 2024 16:45:22 +0800 Subject: [ANN] OpenResty 1.25.3.2 released In-Reply-To: References: Message-ID: We have fully understood the cause of the problem. The reason for disabling rather than reverting the entire commit is because we want to continue to use SSE to speed things up in the future. On Mon, Jul 22, 2024 at 4:10 PM Mathew Heard wrote: > Now that there is a patch out could you please share more information > on those "specific circumstances"? > > It looks to me that luajit2 does not support SSE4.2 whereas agentzh's > fork does. And this is what has been disabled in this release. Is this > an interim release while the cause is investigated or is it fully > understood? > > On Mon, 22 Jul 2024 at 17:46, Jiahao Wang via nginx > wrote: > > > > Hi folks, > > > > I am happy to announce the new formal release, 1.25.3.2, of our > OpenResty web platform based on NGINX and LuaJIT. > > > > OpenResty 1.25.3.2 is a security update addressing a performance issue > in our OpenResty branch of LuaJIT related to hash computation optimization. > This update disables a specific optimization in our LuaJIT fork that could > potentially lead to performance degradation under certain circumstances > (CVE-2024-39702). > > > > It's important to note that this issue is specific to our OpenResty > branch of LuaJIT and does not affect the upstream mainline LuaJIT. > > > > We would like to express our gratitude to Zhongwei Yao from Kong INC. > for reporting this issue. > > > > The full announcement, download links, and change logs can be found > below: > > > > http://openresty.org/en/ann-1025003002.html > > > > You can download the software packages here: > > > > https://openresty.org/en/download.html > > > > OpenResty is a high performance and dynamic web platform based on our > enhanced version of Nginx core, our enhanced version of LuaJIT, and many > powerful Nginx modules and Lua libraries. See OpenResty's homepage for > details: > > > > https://openresty.org/en/ > > > > We strongly recommend all users to upgrade to this version to ensure > optimal performance and security. > > > > OpenResty Inc. provides commercial support and private module > development for the open-source OpenResty. For more information, please > visit https://openresty.com. > > > > Enjoy! > > > > Best regards, > > Jiahao > > _______________________________________________ > > nginx mailing list > > nginx at nginx.org > > https://mailman.nginx.org/mailman/listinfo/nginx > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: