Yes this exactly, I ended up been schooled by support :) Seems like my understanding of graceful shutdown / reload ..
for the list and the archives No keep alive for http1.0, has to be http1.1 client -> nginx keep alive session - these are shutdown once the current request is completed nginx -> backend server keep alive session - these are shutdown once the current request is completed client -> nginx - websockets ... these are kept alive until the client closes it nginx -> backend - websocket ... these are kept alive until the client closes it client -> nginx -> backend ... ssl passthrough ? I presume these are kept alive until either the client or the backend closes it. it would be nice to allow a reload/refresh but keep keep-alive session open until the client closes it Alex On 19 May 2017 at 23:10, Maxim Dounin <mdou...@mdounin.ru> wrote: > Hello! > > On Fri, May 19, 2017 at 11:28:05AM +1000, Alex Samad wrote: > > > Hi > > > > so I have lots of clients on long lived tcp connections , getting rp > into 2 > > back end app servers > > > > I had a line in my error log, saying one of the upstream was failed > caused > > it timeout - > > > > > > then I got this > > > > 2017/05/18 13:30:42 [notice] 2662#2662: exiting > > 2017/05/18 13:30:42 [notice] 2662#2662: exit > > 2017/05/18 13:30:42 [notice] 2661#2661: signal 17 (SIGCHLD) received > > 2017/05/18 13:30:42 [notice] 2661#2661: worker process 2662 exited with > > code 0 > > 2017/05/18 13:30:42 [notice] 2661#2661: signal 29 (SIGIO) received > > > > > > I am not sure what initiated this ? there are no cron jobs running at > that > > time > > > > and it looks like a lot of my long lived tcp session where TCP-FIN'ed. > > > > > > I also checked my audit logs to see what command / process run at that > time > > ... nothing that signaled or initiated a nginx reload ... > > Try searching error log for prior messages from process 2662 (note > that each error message have process ID in it, "... 2662#..."), it > should help to identify why it exited. > > Most likley it was an old worker previously instructed to shutdown > gracefully due to a configuration reload, and it finished serving > all the existing clients and exited. If it's the case, you should > see something like "gracefully shutting down" from the worker > somewhere earlier in logs, and "reconfiguring" from master just > before it. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
