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 <srebecchi at kameleoon.com>
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: <http://mailman.nginx.org/pipermail/nginx/attachments/20240718/275445c1/attachment-0001.htm>