You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an issue with pods running goofys as a sidecar in kubernetes. When we delete the pod, it takes time or stuck shutting down the goofys container. This is due to goofys connection to s3 endpoint not being terminated properly.
We weren't able to reproduce it in hyperscalers (aws,gcp,etc) .
The normal behavior of goofys when sent a sigkill , is to exit with exit code 137.
We're trying to figure out if there's a way to avoid having this exit code in goofys so that our pods will not be stuck on terminating and be deleted properly.
We have an issue with pods running goofys as a sidecar in kubernetes. When we delete the pod, it takes time or stuck shutting down the goofys container. This is due to goofys connection to s3 endpoint not being terminated properly.
We weren't able to reproduce it in hyperscalers (aws,gcp,etc) .
The normal behavior of goofys when sent a sigkill , is to exit with exit code 137.
We're trying to figure out if there's a way to avoid having this exit code in goofys so that our pods will not be stuck on terminating and be deleted properly.
goofys version 0.23.1
running command: goofys -f --dir-mode 0777 --file-mode 0777 -o allow_other --debug_s3 --endpoint https://xxx.xxx.xxx bucket_name /data
The pod is running as privileged in kubernetes.
We can rule out OOM issues as this was checked. It also happens with empty buckets and with new pods that were just spun up.
Any assistance will be appreciated.
The text was updated successfully, but these errors were encountered: