killed child process
alex at samad.com.au
Fri May 19 21:40:59 UTC 2017
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
nginx -> backend - websocket ... these are kept alive until the client
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
On 19 May 2017 at 23:10, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 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
> > 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
> > 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
> > ... 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
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx