Repository navigation
SSLError: FileNotFoundError: [Errno 2] No such file or directory #1236
Description
Activity
- addedkind/bugCategorizes issue or PR as related to a bug.Categorizes issue or PR as related to a bug.
on Aug 20, 2020 After digging through the code, I can see that the tempfile is created because
certificate-authority-datais defined in my kubeconfig. The only reason I can find that this tempfile would be removed would be by the_cleanup_temp_filesfunction defined inconfig/kube_config.py. However, this function is only called fromatexit. My server app is running underuwsgi, so I'm not sure the internals of how processes are managed. Either way, it seems if the process is existing, there is something that is still referencing the temp file.In the meantime, I'm changing my kubeconfig to use
certificate-authority, which points to a file, instead ofcertificate-authority-data. We'll see if that works, but this could still pose a problem for other things that rely on config data that is stored in a file.cc @yliaog
it looks that you have already root caused the problem. after changing to certificate-authority, do you still see the issue?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with/remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.If this issue is safe to close now please do so with
/close.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale- addedlifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.Denotes an issue or PR has remained open with no activity and has become stale.
on Dec 2, 2020 Stale issues rot after 30d of inactivity.
Mark the issue as fresh with/remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.If this issue is safe to close now please do so with
/close.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten- addedlifecycle/rottenDenotes an issue or PR that has aged beyond stale and will be auto-closed.Denotes an issue or PR that has aged beyond stale and will be auto-closed.and removedlifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.Denotes an issue or PR has remained open with no activity and has become stale.
on Jan 1, 2021 Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close@fejta-bot: Closing this issue.
Details
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/closeInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
I'm still having this issue. Use
certificate-authorityis just a workaround, not a fix. Why it still uses the tmp file even the program is restarted?/reopen
@wb14123: You can't reopen an issue/PR unless you authored it or you are a collaborator.
Details
In response to this:
I'm still having this issue. Use
certificate-authorityis just a workaround, not a fix. Why it still uses the tmp file even the program is restarted?/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
i also saw this problem and because of this issue i was able to debug why i saw it. I had a code which was doing CRUDs on multiple kubernetes clusters, while that code was still running i went in the /tmp folder of and deleted everything, include all the tmp*******( eg: tmp2xng8a6e) files which were created. This led to failure in some CRUD APIs
Although i do not know why these files are created.
/reopen
@yliaog: Reopened this issue.
Details
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-contributor-experience at kubernetes/community.
/close@fejta-bot: Closing this issue.
Details
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-contributor-experience at kubernetes/community.
/closeInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
This should be reopened, this issue makes this lib incompatible with spec-compliant kubeconfigs.
More selfishly, it is incompatible with kubeconfigs that are served from Rancher's cluster API at
/v3/clusters/<cluster id>?action=generateKubeconfigsince those have the CA data embedded./reopen
/reopen
@ba-work do you have time to send a PR to fix it?
@yliaog I think this probably just a case of me misusing the lib or not understanding the scope properly. I had a function to setup a connection to a cluster that returned a
kubernetes.client.CoreV1Api()and once I took that logic out of the function and put it in the caller it worked just fine.
If you have any guidance on this I would welcome it. This is what didn't work (but did ifinsecure-skip-tls-verify):def kubernetes_config(): ''' Sets up kubernetes connection ''' in_cluster = os.getenv('IN_CLUSTER', 'true').lower() in ('true', '1', 't', 'yes', 'y') if in_cluster: kubernetes.config.load_incluster_config() else: kube_config = os.getenv('KUBECONFIG', '/etc/kubernetes/kuebconfig.yaml') logging.info('The kubeconfig file has been set to: %s', kube_config) kubernetes.config.load_kube_config(kube_config) return kubernetes.client.CoreV1Api(), kubernetes.watch.Watch()
Then outside of the function I had something like this:
kubernetes_api, kubernetes_watch = kubernetes_config()
And accessing it like this would cause the above issue.
I have read the source code, and we can solve the problem by transfer certificate-authority-data to a certificate-authority file like this:
I have opened a new issue for this with more details: #1782
Ultimately, modern linux servers run things like
tmpwatchthat clean old files from/tmp, so the client cannot expect a temp file to live forever.I have read the source code, and we can solve the problem by transfer certificate-authority-data to a certificate-authority file like this:
hello from the other side


I'm getting an intermittent error on my production Django website (running under UWSGI) when the kubernetes client library is called:
The strange thing is, I can simply restart my server and the problem goes away, but after a few hours I see the same error again.
I added some extra logging to the load_verify_locations function in
urllib3/util/ssl_.pyto see what file it's trying to open. Theca_certsargument is passing in a temp file,/tmp/tmp2xng8a6e. The other two arguments areNone.So, why a temp file, and why is it missing? Is there a reason why the temp file would get deleted? I filed an issue with urllib3, but they said the temporary file doesn't happen on the urllib3 side.
I'm using kubernetes python client version
11.0.0. My OpenSSL version is1.0.2g.Here's the full exception with traceback: