Re: Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2.

[Roman Arutyunyan]

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
> a...@nginx.com 
Patch committed:

https://hg.nginx.org/nginx/rev/d1b8568f3042


Roman Arutyunyan
a...@nginx.com




___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx

Re: Bugfix: graceful shutdown of old worker processes might be delayed when using HTTP/2.

[Sébastien Rebecchi]

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
> a...@nginx.com
>
>
> Patch committed:
>
> https://hg.nginx.org/nginx/rev/d1b8568f3042
>
> 
> Roman Arutyunyan
> a...@nginx.com
>
>
>
>
> ___
> nginx mailing list
> nginx@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx

Re: Upgrading Executable on the Fly

[Sébastien Rebecchi]

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.
>
>
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx