Friday, November 27, 2020

Sigterm handling on the TCP server

Hi community,

I am now using the Django server with gunicorn.
I hit a problem in the worker termination. 
I've got logs with tshark in the following.

2020-11-27 06:50:37.509 GMT [2020-11-27 06:50:37 +0000] [1] [INFO] Handling signal: term
2020-11-27 06:50:37.560 GMT [2020-11-27 06:50:37 +0000] [20] [INFO] Worker exiting (pid: 20)
2020-11-27 06:50:37.560 GMT [2020-11-27 06:50:37 +0000] [19] [INFO] Worker exiting (pid: 19)
2020-11-27 06:50:37.572 GMT 237049 157.117734757 xxxxx → xxxx TCP 68 8000 → 51758 [ACK] Seq=97126 Ack=53637 (Last logs from tshark)
2020-11-27 06:50:37.959 GMT Failed to proxy request: connection error: Connection reset by peer (os error 104)

So, from the logs, you can see the last packet sent from server to my client is a packet with ACK. Before that, there was no FIN ACK sent from my Django server.
I supposed that the Django TCP/HTTP server would wait for existing request and send the FIN/ACK to the client in order to terminate the TCP connection.
But right now, the TCP connection wasn't terminated properly before the web server fully exited. 
Eventually, my client would occasionally receive 502, which was handled by my service mesh in this case, during the service update.

I've dug into the code in Django and cpython. I think cpython's http server has the function shutdown, which make the server exiting safely. I wonder if the Django handles this case properly. Or any suggestion that I can handled the connection close properly in Django?

Thank you!

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0cf9a406-06f7-4103-8be4-a9467d3933ddn%40googlegroups.com.

No comments:

Post a Comment