-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Internet connection stops working when using Lens #6063
Comments
hmm, I may have experienced this too. weird. |
We would like to better understand how you are using Lens to see if we can track down why Lens would be able to do this. Are you connecting to a lot of clusters at once? Do you use other features such as Lens Spaces? Could you use a network analyzer to display the active connections that Lens is making when this next happens? |
|
I've had this happen as well maybe 3-5 times over 2 weeks, but haven't been able to figure out any specific behavior that triggers it. Lens version: 6.0.1-latest.20220810.2
I'm mostly only looking at the logs of pods and will have several tabs open at once for an extended period, so that my best guess for a cause. |
The same issue. Two days I tried to understand where is the problem and figured out that when my Lens is open my internet connection after ~10-15 minutes stop working. Also yesterday there was a situation, Lens was frozen, and I couldn’t close it even through the activity monitor, after which my laptop froze and I had to turn it off while holding the button Lens version: 6.0.1-latest.20220810.2 I ran Also, were a lot of situations where I closed Lens and ping started work again. I opened Lens, worked ~10 mins, and everything repeated |
I happened the same to me a few weeks ago. At that time I didn't realice it was Lens. |
Same issue here, from time to time the internet connection drops, and after closing Lens, everything goes back to normal. version: Lens: 6.0.1-latest.20220810.2 @Nokel81 I'm connecting to multiple clusters at once, up to 3-4 at the same time and I use Lens Space for 1 cluster. |
I have seen this also once, didn't realize it was Lens fault. Is everyone else also using M1 (arm64)? |
@jakolehm Indeed using M1 |
I've also seen this issue twice this week but unfortunately, I don't have specific details at the moment.
|
I'm hitting this several times a day, the more clusters I have connected the worse it is, and the more resources in those clusters the worse it is. Having 1 cluster open that has several hundred pods on 10 nodes will cause a complete network failure in under 40 minutes every time. It seems to be related to the total amount of resources in currently connected clusters. M1 MBP with macOS 12.5.1 (21G83) |
Just had it happen again while monitoring ping and netstat, no unusual amount of sockets opened, once I disconnected the clusters and closed lens everything works again, will add more diagnostics and try catch more data. |
I've been connected to EKS cluster but in a one-moment connection session expired, right after that Lens UI got stuck (I think it's electron part) and my VPN connection was dropped. Maybe it's just a coincidence.
|
Opening lens again after its happened but before a reboot causes it to happen immediately. |
Seems to be related to the amount of kubernetes updates being processed, potentially something broken in a watch loop. |
Any news regarding this issue? |
Same Thing here. Lost the connection many times during the day. Latest version of Lens |
@wallacepf and others - are you using Lens with multiple clusters? |
In my case, nope. I have a single AKS for demo purposes. Brand new BTW, so I don't believe the number of objects influences the issue. |
Hi! Same happening here, it's like the app does something with the host network and overflows something |
Any updates on this issue? It's making the use of Lens a bit frustrating. |
I've switched to using OpenLens directly instead of the proprietary binary and have not had a problem since. I think it's something in their telemetry/data harvesting addons that's broken. |
We had a similar issue in one of our products, thought you might be interested in what we found so that it might help you find/fix your problem:
|
Any news on this? |
Just found this issue while searching google for "isLensCloudStatusOk". Similar issue here (Ubuntu 20.04, Lens 2023.4.60821-latest) while trying to run LDK (Lens Desktop Kube): after Lens was open for few days, LDK refused to start. Relevant logs provided below. Trying to create LDK (first time, Lens didn't have image locally):
Unable to configure new cluster because Lens can't fetch list of supported k8s versions (LDK > Settings > Create New Profile):
And from time to time in logs also this line that thankfully brought me here:
|
I can see leakage of socket/file descriptors with latest stable version but not with latest alpha versions -> I believe this is fixed in the master branch. Let's close it once we can verify the fix with beta/stable builds. |
when this happens, please run |
so maybe the problem is in Console Ninja if lens using it need to be uppgrade to v1.0.105+. |
This has also been described here hashicorp/terraform#31467 and the current workaround seems to be related to disabling IPv6 |
Likely related to golang issue described here: golang/go#52839 |
Same issue with me. Is there any official person who can reply to this question? This problem has been happening for a year, that's unacceptable. |
same issue with me |
one year with this issue |
Firstly, thank you all for bringing this issue to our attention and for all your patience as we work to resolve it. We understand how disruptive this can be to your workflow and appreciate the detailed reports you've providing. We wanted to update the community on this particular issue regarding network connectivity being blocked after using Lens for an extended period. Our team has been actively investigating this matter since quite a while already, and it's been challenging due to the sporadic nature of the problem. Previously we were able to reproduce the issue related to a third-party Golang binary that Lens utilized in lens-proxy for managing network connections. This issue we tired to fix by using the most recent golang version to compile this binary. (see golang/go#52839) Here are some other tools that have the same issue:
However, as you've experienced, the problem still occurs, albeit rarely. This indicates that there might be more underlying factors contributing to the issue that we've yet to identify. To move closer to a resolution, we need more data that can only come from occurrences in diverse user environments. If you encounter this issue again, could you please provide us with the following information?
This information will be crucial for us to attempt to replicate the issue under similar conditions. We are committed to resolving this issue and improving Lens for all users. |
Hello,
|
@msa0311 - did you see my comment above regarding the use of the JavaScript I saw Lens is an electron app. I assume you're using Basically, you will have the problem if you use For example: // This will ultimately leak system resources on the MacOS M1
// when a certain number of responses have been made. The
// network will become unavailable at this point for the entire system.
const resourceExists = async (url) => {
try {
const response = await fetch(url);
return response.ok;
} catch (_) {
return false;
}
}; If you're using For example: // Use of the abort controller to clean up the fetch resources will fix the issue
const controller = new AbortController();
try {
const response = await fetch(url, {signal: controller.signal});
return response.ok;
} catch (_) {
return false;
} finally {
controller.abort();
} |
@smcenlly we tried to reproduce the |
same issue here on mac m2 pro |
Describe the bug
From time to time when using Lens, the internet connection stops working on my computer. After closing Lens, it starts working again.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Internet connection keeps active.
Environment (please complete the following information):
Additional context
Usually it happens once in a work day (8 - 9 hours).
The text was updated successfully, but these errors were encountered: