<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">... and you would end up with connections serving different content (as per different configuration) on the long run, leading potentially to an increased number of problems.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">How would you shut them down, if not gracefully?<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">If you want to keep long-lived connections open, do not make changes server-side, such as asking it to reopen configuration (and thus to apply it to every worker).<br></div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Fri, May 19, 2017 at 11:40 PM, Alex Samad <span dir="ltr"><<a href="mailto:alex@samad.com.au" target="_blank">alex@samad.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes this exactly, I ended up been schooled by support :)<div><br></div><div>Seems like my understanding of graceful shutdown / reload ..</div><div><br></div><div>for the list and the archives</div><div><br></div><div>No keep alive for http1.0, has to be http1.1</div><div><br></div><div><br></div><div>client -> nginx keep alive session - these are shutdown once the current request is completed </div><div>nginx -> backend server keep alive session - these are shutdown once the current request is completed</div><div><br></div><div>client -> nginx - websockets ... these are kept alive until the client closes it</div><div>nginx -> backend - websocket ... these are kept alive until the client closes it</div><div><br></div><div><br></div><div>client -> nginx -> backend ... ssl passthrough ? I presume these are kept alive until either the client or the backend closes it.</div><div><br></div><div><br></div><div>it would be nice to allow a reload/refresh but keep keep-alive session open until the client closes it</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Alex</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 19 May 2017 at 23:10, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span><br>
On Fri, May 19, 2017 at 11:28:05AM +1000, Alex Samad wrote:<br>
<br>
> Hi<br>
><br>
> so I have lots of clients on long lived tcp connections , getting rp into 2<br>
> back end app servers<br>
><br>
> I had a line in my error log, saying one of the upstream was failed caused<br>
> it timeout -<br>
><br>
><br>
> then I got this<br>
><br>
> 2017/05/18 13:30:42 [notice] 2662#2662: exiting<br>
> 2017/05/18 13:30:42 [notice] 2662#2662: exit<br>
> 2017/05/18 13:30:42 [notice] 2661#2661: signal 17 (SIGCHLD) received<br>
> 2017/05/18 13:30:42 [notice] 2661#2661: worker process 2662 exited with<br>
> code 0<br>
> 2017/05/18 13:30:42 [notice] 2661#2661: signal 29 (SIGIO) received<br>
><br>
><br>
> I am not sure what initiated this ? there are no cron jobs running at that<br>
> time<br>
><br>
> and it looks like a lot of my long lived tcp session where TCP-FIN'ed.<br>
><br>
><br>
> I also checked my audit logs to see what command / process run at that time<br>
> ... nothing that signaled or initiated a nginx reload ...<br>
<br>
</span>Try searching error log for prior messages from process 2662 (note<br>
that each error message have process ID in it, "... 2662#..."), it<br>
should help to identify why it exited.<br>
<br>
Most likley it was an old worker previously instructed to shutdown<br>
gracefully due to a configuration reload, and it finished serving<br>
all the existing clients and exited. If it's the case, you should<br>
see something like "gracefully shutting down" from the worker<br>
somewhere earlier in logs, and "reconfiguring" from master just<br>
before it.<br>
<span class="m_-4756504063898370487HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailm<wbr>an/listinfo/nginx</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br></blockquote></div><br></div></div>