Remote Container: connection drops when attaching and opening a directory #6685
Assignees
Labels
containers
Issue in vscode-remote containers
info-needed
Issue requires more information from poster
Comments
RaananHadar
changed the title
|
Which version of Remote-Containers are you using? Could you append the full log? |
|
I am using version Re-running this produces the following log: |
|
Could you retry with VS Code 1.67? That comes with a fix in the reconnection code. |
|
Unfortunately I am getting the very same error with 1.67. The logs seem to indicate the same issue: |
|
It looks like the VS Code server stops listening on the container's local port. Could you retry with 'trace' logging enabled in the user settings for Remote-Containers and post the log from that again? |
|
I also have this with podman on Fedora 34, though I don't see This was working fine not too long ago, but I did a relatively recent upgrade of VS code, so it could have been that. I tried 1.67 and it is the same. Also seeing this, but nothing else that would suggest any problem: |
|
Removed VS Code 1.67 and installed 1.60 and it now works fine... I did nothing else and the only thing that changed was VS code version. In VS Code 1.60 the log is like this: |
|
So I decided to attack this a bit more today. I decided to go through the list from version 1.67 and install each version up to 1.60 and find out where the break happens. I was able to install all versions up to 1.63.1 which all worked fine. I could not install 1.63.2, because it says: As soon as I installed 1.64.0 it stops working and none of the subsequent versions are any different: 1.64.0.log - no longer works with my container... Unfortunately, using an old version means my source control window is showing nothing, but this does in fact show something on later versions...: |
|
Recent versions of Remote-Containers require VS Code 1.64 or later. So it could be a change in VS Code or Remote-Containers causing this. Could you try VS Code 1.64 or later with Remote-Containers 0.224.3? (This is before a larger refactoring.) |
|
I apologize for the delay, here are he logs: |
|
What do you get for |
|
As I cannot open a terminal on the dev container as vscode cannot reconnect, I opened a terminal at that point on the original container once reaching that point and here is what I got: |
|
@aeschli The server stopped with exit code 0 after about a minute. Any idea what the cause could be? (The log above #6685 (comment) includes the server log.) |
|
@chrmarti Sorry, no idea. |
|
This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines. Happy Coding! |
|
This issue has not been resolved, please reopen. |
|
Very similar issue here maybe this log can help: This log was recorded on an ubuntu 22:04 host. I tested the same container on an ubuntu 20:04 host with the same version of vscode(1.67.2) and remote-containers(0.234.0) and everything just ran fine. What differs is the podman installation: 3.4.2 kubic packages on ubuntu 20.04 and 3.4.4 from official repos on ubuntu 22.04. |
|
@RaananHadar Are you seeing this with Podman? |
|
This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines. Happy Coding! |
|
Seeing the same error on another ubuntu 22:04 host with vscode 1.68.0 and remote-containers 0.238.2 and podman 3.4.4. Using docker instead of podman fixes the problem. Unfortunately i have currently no time to dig deeper into this. In the long term i would prefer to use podman |
|
Sorry for my lack of availability. Had some personal matters. I saw this problem with docker and not podman. I can try to replicate this on podman if that's of interest. |
|
Could you attach your devcontainer.json and Dockerfile (and Docker Compose file if you use that)? |
|
I use the following: {
"name": "Existing Dockerfile",
"context": "..",
"dockerFile": "../Dockerfile",
"postCreateCommand": "git config --global --add safe.directory /workspaces/serialtool",
"customizations": {
"vscode": {
"extensions": [
"ms-vscode.cpptools-themes",
"twxs.cmake",
"ms-vscode.cmake-tools",
"jeff-hykin.better-cpp-syntax",
"ms-vscode.cpptools",
"matepek.vscode-catch2-test-adapter",
"jbenden.c-cpp-flylint"
]
}
},
"mounts": [
"source=/etc/ssl/certs,target=/etc/ssl/certs,type=bind,readonly",
"source=${localWorkspaceFolder}/.home,target=/root,type=bind"
]
}# syntax=docker/dockerfile:1.2
FROM ubuntu:22.04
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get -y install \
git \
wget \
unzip \
ca-certificates \
nano \
tar \
gcc-12 \
g++-12 \
googletest \
google-mock \
libboost-all-dev \
cmake \
cppcheck \
flawfinder \
clang-format \
clang-tidy \
curl \
gdb \
libssl-dev
ENV CC=/usr/bin/gcc-12
ENV CXX=/usr/bin/g++-12
WORKDIR /
RUN mkdir -p /tools && \
cd tools && \
git clone https://github.com/SergiusTheBest/plog.git && \
cd plog && \
git checkout 1.1.8 && \
mkdir -p build && \
cmake . -DPLOG_BUILD_SAMPLES:booloean=false && \
cmake --build . && \
cmake --install . Pretty standard nothing special |
|
Also reporting a similar issue here on a fresh Ubuntu 22:04 machine and default When trying to run a rootless devcontainer with the following devcontainer.json settings {
"name": "Node.js & TypeScript",
"build": {
"dockerfile": "Dockerfile",
"args": {
"VARIANT": "18-buster"
}
},
"customizations": {
"vscode": {
"extensions": [
"dbaeumer.vscode-eslint"
]
}
},
"remoteUser": "node",
"workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind,Z",
"workspaceFolder": "/workspace",
"runArgs": ["--userns=keep-id"],
"containerUser": "node"
}I get a crash loop that produces the following failure in the logs: [27974 ms] Start: Reconnection attempt 4
[27974 ms] Start: Run: podman inspect --type container 1ceab2f80e91bd2598662176d3ead3e968fc1ab8ea70fb84df9d75aedd987102
[28167 ms] Port forwarding connection from 36344 > 35307 > 35307 in the container.
[28167 ms] Start: Run in container: /home/node/.vscode-server/bin/30d9c6cd9483b2cc586687151bcbcd635f373630/node -e
[28353 ms] Port forwarding 36344 > 35307 > 35307 stderr: Connection established
[28368 ms] [10:34:51] [127.0.0.1][42c49301][ManagementConnection] The client has reconnected.
[33399 ms] Port forwarding 36344 > 35307 > 35307 stderr: Error: timed out waiting for file /home/user/.local/share/containers/storage/overlay-containers/1ceab2f80e91bd2598662176d3ead3e968fc1ab8ea70fb84df9d75aedd987102/userdata/ce7150922540d0bb38fc33241979057d8ecc203b57329e10810612993d6f7101/exit/1ceab2f80e91bd2598662176d3ead3e968fc1ab8ea70fb84df9d75aedd987102: internal libpod error
[33403 ms] Port forwarding 36344 > 35307 > 35307 terminated with code 255 and signal null.
[33404 ms] Port forwarding 36344 > 35307 > 35307: Local close |
|
As some time has passed since opening the issue, I tried testing this with podman and removing docker desktop but i've also updated everything to the latest versions of vscode and the remote containers extension and even kubectl (which might had a timeout with port forwarding). So i'm actually happy to note that now everything seems to work fine! I will test this again with the latest versions of vscode, remote containers and docker desktop instead of podman just in case and once I update on this further I think we can move forward on closing this if we see that this is applicable to all users. |
|
After checking this further, things seem to be working now even with Docker and not just podman (Please note that i've made special care that podman or docker are not installed at the same time on my system while testing this and the prior test). I've updated both vscode to version 1.68.1, remote containers to version 0.238.2, kubectl and docker desktop to the latest version. I am fine with closing this issue unless other users believe it should stay open for any reason i've missed. |
|
It continues to not work for me. However, I’ve noticed that it doesn’t seem to happen consistently, sometimes it will just go through the loop I described a number of times before working but even once it has established the connection properly it will intermittently need to reconnect which can take up to 20 seconds each time. Using the latest version of podman, VSCode and the remote containers plug-in on an otherwise fresh Ubuntu 22.04 install so something is still not right here. |
|
Short update: error still exists on ubuntu22:04, vscode 1.69.0, remote containers 0.241.3, podman 3.4.4 |
|
I've also been getting the problem @mhoad described in #6685 (comment), using VS Code on an Ubuntu 22.04 host with podman. I want to point out that there seem to be multiple problems described in this issue and the one that I'm getting is this one, mentioned by @mhoad: That is, a time out trying to read a storage overlay file resulting in an It's very irritating: it's a gamble when I start VS Code and a container whether it will just cycle through reconnection attempts forever, or try a bunch of times and then work, or work right away. If it tries forever I shut down VS Code and try again until it works. @chrmarti Should we create another issue to get proper attention on the |
|
This is still an issue. I upgraded to Fedora 36 and part of the process is to update all installed packages, which included After that, code was broken again. So, to fix it I installed remote containers 0.209.6 and then closed VS code, then I ran:
And VOILA 🧙 like magic, it is back working again. FWIW, the container's config is this: {
"workspaceMount": "/home/craig.crawford/mycodefolder",
"workspaceFolder": "/home/craig.crawford/mycodefolder",
"remoteUser": "${localEnv:USER}",
"settings": {
"terminal.integrated.shell.linux": "/usr/sbin/capsh",
"terminal.integrated.shellArgs.linux": [
"--caps=",
"--",
"-c",
"exec \"$@\"",
"/bin/sh",
"${localEnv:SHELL}",
"-l"
]
},
"remoteEnv": {
"COLORTERM": "${localEnv:COLORTERM}",
"DBUS_SESSION_BUS_ADDRESS": "${localEnv:DBUS_SESSION_BUS_ADDRESS}",
"DESKTOP_SESSION": "${localEnv:DESKTOP_SESSION}",
"DISPLAY": "${localEnv:DISPLAY}",
"LANG": "${localEnv:LANG}",
"SHELL": "${localEnv:SHELL}",
"SSH_AUTH_SOCK": "${localEnv:SSH_AUTH_SOCK}",
"TERM": "${localEnv:TERM}",
"VTE_VERSION": "${localEnv:VTE_VERSION}",
"XDG_CURRENT_DESKTOP": "${localEnv:XDG_CURRENT_DESKTOP}",
"XDG_DATA_DIRS": "${localEnv:XDG_DATA_DIRS}",
"XDG_MENU_PREFIX": "${localEnv:XDG_MENU_PREFIX}",
"XDG_RUNTIME_DIR": "${localEnv:XDG_RUNTIME_DIR}",
"XDG_SESSION_DESKTOP": "${localEnv:XDG_SESSION_DESKTOP}",
"XDG_SESSION_TYPE": "${localEnv:XDG_SESSION_TYPE}"
},
"extensions": [
"ms-python.python",
"ms-python.vscode-pylance",
"golang.go"
]
} |
If you install VS Code 1.63.1 and remote containers 0.209.6 does it start working? If so, this would indicate the issue is probably related but the error may be slightly different. |
|
@NotoriousPyro That's a good idea but I wouldn't stick with v1.63.1, it would just be for testing. So I'll wait for feedback from the VS Code team before doing anything like that. I hope they can make progress without needing me to test old versions. |
@jeremyn Yes please! |
|
Same error when tried to run https://github.com/darklang/dark |
|
I'm getting a similar error when using https://github.com/frappe/frappe_docker dev container. Dev containers used to work for this project before. VS Code version info: |
|
Closing since the original issues when attaching to a container in k8s is resolved (#6685 (comment)). The libpod issue is tracked as #7175. If you are seeing other problems, please open a new issue, so we can investigate separately. Thanks. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
VSCode Version:
Version: 1.66.2 (Universal)
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-11T07:49:20.994Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: 9.8.177.11-electron.0
Local OS Version:
OS: Darwin x64 21.4.0
Remote OS Version:
ubuntu:focal official image (this happens with other versions as well).
Remote Extension/Connection Type: SSH/Docker/WSL
Docker
Logs:
The logs are repeating with retries. A trace appears once and seems to be the most informative:
Then the reconnection logs appear as following:
Steps to Reproduce:
Does this issue occur when you try this locally?: No
The text was updated successfully, but these errors were encountered: