Internet connection stops working when using Lens

[cachila]

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:

1. Open Lens.
2. Keep using it and after some hours, Internet will stop working.

Expected behavior Internet connection keeps active.

Environment (please complete the following information):

• Lens Version: 6.0.1-latest.20220810.2
• OS: OSX 12.4
• Installation method: Installed from .dmg

Additional context Usually it happens once in a work day (8 - 9 hours).

[matti]

Again with no buffer space, this time I got this error on chrome and it disappeared when I relaunced Lens

[Atomzwieback]

Same problem here, happens about every hour atm and i have to disable my whole network connection to reset it.

[raw0w]

Hi there. I have the same problem. Every time restoring my network by killing lenses' pids, because just pressing "close button" is not leading to full exit from lens and issue is remaining.

[monoxane]

I've had a lot of luck running the 6.2.5 release from the OpenLens build repo running directly out of my downloads folder instead of properly installed. It's only crashed once in the last month or so.

[maslow]

Same problem here, happens about every hour atm and i have to disable my whole network connection to reset it.

Again with ERR_NO_BUFFER_SPACE.

Restart macbook several times every day.

M1 pro

[ckosmowski]

We experiencing very similar issues the error description is quite the same it also affects only our MacBook Users. But we did not yet see the ERR_NO_BUFFER_SPACE error or we don't know where to look. If we had the same problem, where would we find that error message?

[raw0w]

Same problem here, happens about every hour atm and i have to disable my whole network connection to reset it.

Again with ERR_NO_BUFFER_SPACE.

Restart macbook several times every day.

M1 pro

You can avoid restarting macbook by killing lens' PIDs: ps -A | grep Lens | awk '{print $1}' | xargs kill -9 $1

[smcenlly]

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:

The problem was actually a bug/behavior in one of our dependencies, node-fetch and they way that we were using it. To optimize performance, we were returning content immediately without processing the response body in some cases (the requirement to process the body is not explicitly mentioned in their docs). This is a known bug that can lead to sockets/file descriptors being left open and is apparently an issue on MacOS and Linux (see https://github.com/node-fetch/node-fetch/issues/1673).

[bruno-lopes]

Any news on this?

[boogi]

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. Just closing and starting afresh Lens helped.

Trying to create LDK (first time, Lens didn't have image locally):

error: [LENS-DESKTOP-KUBE] failed to start vm: RequestError: getaddrinfo EAI_AGAIN downloads.k8slens.dev
    at ClientRequest.<anonymous> (/opt/Lens/resources/app.asar/node_modules/@lensapp/lens-desktop-kube-lens-extension/dist/main.js:2:485643)
    at Object.onceWrapper (node:events:646:26)
    at ClientRequest.emit (node:events:538:35)
    at ClientRequest.emit (node:domain:475:12)
    at e.emit (/opt/Lens/resources/app.asar/node_modules/@lensapp/lens-desktop-kube-lens-extension/dist/main.js:2:263345)
    at TLSSocket.socketErrorListener (node:_http_client:442:9)
    at TLSSocket.emit (node:events:526:28)
    at TLSSocket.emit (node:domain:475:12)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:71:26) {
  code: 'EAI_AGAIN',
  timings: [Object]
}

Unable to configure new cluster because Lens can't fetch list of supported k8s versions (LDK > Settings > Create New Profile):

error: [LENS-DESKTOP-KUBE] unable to fetch supported versions list Unexpected exception [Lens Platform SDK] {"errorCode":null,"rawException":{"code":"EAI_AGAIN","config":{"env":{},"headers":{"Accept":"application/json, text/plain, */*","Authorization":"Bearer: <cut>", "User-Agent":"Lens/2023.4.60821-latest lens-desktop-kube-lens-extension/0.25.0 (Linux)"},"httpsAgent":{"_events":{},"_eventsCount":0,"freeSockets":{},"maxFreeSockets":1,"maxSockets":1,"maxTotalSockets":null,"options":{},"pacProxyAgentOptions":{},"proxyStringCache":{},"requests":{},"sockets":{},"timeout":null},"maxBodyLength":-1,"maxContentLength":-1,"method":"get","timeout":0,"transformRequest":[null],"transformResponse":[null],"transitional":{"clarifyTimeoutError":false,"forcedJSONParsing":true,"silentJSONParsing":true},"url":"https://api.k8slens.dev/lens-desktop-kube/k0s-versions.json","xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN"},"message":"getaddrinfo EAI_AGAIN api.k8slens.dev","name":"Error","stack":"Error: getaddrinfo EAI_AGAIN api.k8slens.dev\n    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:71:26)","status":null},"stack":"Error: Unexpected exception [Lens Platform SDK]\n    at t.throwExpected (/opt/Lens/resources/app.asar/node_modules/@lensapp/lens-desktop-kube-lens-extension/dist/main.js:2:657585)\n    at process.processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at async LensDesktopKubeService.getK0sVersions (/opt/Lens/resources/app.asar/node_modules/@lensapp/lens-desktop-kube-lens-extension/dist/main.js:2:619443)\n    at async /opt/Lens/resources/app.asar/node_modules/@lensapp/lens-desktop-kube-lens-extension/dist/main.js:2:967034\n    at async t.getK0sVersions (/opt/Lens/resources/app.asar/node_modules/@lensapp/lens-desktop-kube-lens-extension/dist/main.js:2:966953)\n    at async /opt/Lens/resources/app.asar/node_modules/@k8slens/core/static/build/library/main.js:8829:32\n    at async node:electron/js2c/browser_init:189:563"}

And from time to time in logs also this line that thankfully brought me here:

warn: [LENS-SPACES-EXTENSION]: 4/13/2023, 4:25:46 PM isLensCloudStatusOk returns false

[jakolehm]

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.

[matti]

when this happens, please run lsof -p <lens-helper-renderer-pid> | grep TCP | wc -l and post here

[matti]

[matti]

2023.4.141316-latest

[jwklijnsma]

so maybe the problem is in Console Ninja if lens using it need to be uppgrade to v1.0.105+.

[gabriel-mirantis]

This has also been described here https://github.com/hashicorp/terraform/issues/31467 and the current workaround seems to be related to disabling IPv6

[jakolehm]

Likely related to golang issue described here: https://github.com/golang/go/issues/52839

[ischenxin]

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.

[matias-cova-skydropx]

same issue with me

[dshershov]

one year with this issue connections are dropped every 15 minutes looks like we need to add new feature with namespace...

[msa0311]

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 https://github.com/golang/go/issues/52839)

Here are some other tools that have the same issue:

• Terraform (https://github.com/hashicorp/terraform/issues/31467)
• kubectl (https://github.com/kubernetes/kubectl/issues/1299)
• helm (https://github.com/helm/helm/issues/11306)
• docker compose (https://github.com/docker/compose/pull/9932)

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?

• Have you been using IPV6 network?
• Did you configure IPV6 to "link-local" DNS resolve for this network?
• Are you using MacOS with Apple Silicon Chips (M1, M2)?
• Are you using the latest version of Lens?
• Details of the operations being performed within Lens leading up to the issue?

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.

[dshershov]

Hello, Thanks @msa0311 ! So:

• ipv6 was not use on my PC
• MacOS with m1Pro chip
• Latest drop 4 days ago with the next version of Lens - v2024.1.170738-latest
• Details? hmm, i'm use Lens for default k8s operations such as port-forwarding, logging, checks some manifests, network settings, CRDs and other

[smcenlly]

@msa0311 - did you see my comment above regarding the use of the JavaScript node-fetch package?

I saw Lens is an electron app. I assume you're using node-fetch for network communication and may have the same issue we had. We had exactly the same behavior as you are describing in our own product and it was very hard to track down.

Basically, you will have the problem if you use node-fetch and do not consume the body of the request:

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 node-fetch, you'd need to check that all usages of it consume the body (e.g. .json, .text, etc.). The workaround is to dispose of the response with an abort signal.

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();
}

[jakolehm]

@smcenlly we tried to reproduce the node-fetch issue back in April but we could not reproduce it anymore. We should probably verify it has not popped back.

[dshershov]

still reproduce this issue with the next version:

[dandrade-pedbot]

same issue here on mac m2 pro

[balusarakesh]

looks like OpenLens is holding up a lot of connections sudo lsof -n -i TCP | grep openlens -i

[saowu]

Any news on this?