killed child process

[Alex Samad]

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 <mdounin at 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170520/2b3bb70b/attachment.html>