-
Notifications
You must be signed in to change notification settings - Fork 2k
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
NIC Pod fails to bind to unix socket when NGINX master process exists unexpectedly and does not clean up #4604
Comments
Hi @shaun-nx thanks for reporting! Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂 Cheers! |
Fixed in #7121 |
Hello, I've performing some testing with Nginx v4.0.1 this morning to verify the fix for this ticket (issue also captured in #6752 and #4370). I'm afraid to report that v4.0.1 does not resolve the issue reported. I deployed Nginx with a low memory limit of 125Mi so that I could be able to trigger an OOMKill with some modest traffic. After the OOMKill the pod was unable to restart. We see the same familiar error message: with a debug log level:
|
@shaun-nx Hi, I'm just wondering if you saw my message above? |
@MarkTopping thank you for reporting. We will re-open the issue and continue investigating. |
Describe the bug
When the NGINX master process exists unexpectedly (e.g. the process is killed using
kill -9 <master-process-pid>
), system files generated by NGINX are not cleaned up.This bug outlines the impact of unix socket files in
/var/lib/nginx
persisting after the NGINX master process exists unexpectedly.Log output from NGINX when master process exists unexpectedly
E1102 09:38:53.243649 1 main.go:501] nginx command exited with an error: signal: killed I1102 09:38:53.243740 1 main.go:511] Shutting down the controller I1102 09:38:53.244035 1 main.go:521] Exiting with a status: 1
To Reproduce
Steps to reproduce the behavior:
volume
or typeemptyDir:{}
andvolumeMount
for/var/lib/nginx
kubectl debug -it -n <ic-namespace> <ic-pod> --image=busybox:1.28 --target=nginx-ingress
ps -ef
to get the process id of the NGINX master processkill -9 <master-process-pid>
Expected behavior
NGINX Ingress Controller is able to recover and operate normally after exiting unexpectedly.
Your environment
Additional context
Full deployment manifest used:
Log output
The text was updated successfully, but these errors were encountered: