-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
controller can't shutdown gracefully on >=0.18.0 #3533
Comments
Using the most recent version (ea89d27) with this patch diff --git a/images/nginx/rootfs/entrypoint.sh b/images/nginx/rootfs/entrypoint.sh
index 46bb5e076..e8317012c 100755
--- a/images/nginx/rootfs/entrypoint.sh
+++ b/images/nginx/rootfs/entrypoint.sh
@@ -16,4 +16,4 @@
set -e
-authbind --deep $@
+exec authbind --deep $@ I cannot reproduce the issue anymore. This is the non-verbose log output after deleting the pod, with a long running connection still being open:
The long running connection gets closed at around 10:37:14, after which nginx exists. |
Closing. Fixed in master (#3536) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug report:
There appears to be a stray SIGKILL during post-SIGTERM cleanup tasks that doesn't allow the controller to gracefully shutdown with 0.
This was discovered after upgrading from 0.10 to 0.21. There is a custom controller that makes changes to an external on-premise load balancer when an ingress controller receives a SIGTERM in order to stop receiving traffic until it comes back up again, and this stopped working correctly with the upgrade.
Via git bisect and manual testing, we found that the commit responsible for the SIGKILL is this one, between 0.17.1 and 0.18: 7210518
--- difference in loglines and strace after SIGTERM ---
0.17.1:
In regards to SIGKILL, it sometimes also happens in <=0.17.1, but it mostly ++exits with 0++. >0.18 always gets a SIGKILL and these three loglines.
SIGQUIT goes to nginx itself in <0.17), while it is absent on >0.18 - controller dies before that.
What you expected to happen:
ingress controller shutting down gracefully
How to reproduce it:
Shut down ingress controller (delete the pod). It can be reproduced most of the time but not always.
NGINX Ingress controller version: >=0.18.0
Kubernetes version: 1.10.11
Environment:
The text was updated successfully, but these errors were encountered: