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