First attempt at rebuild always fails (container removal already in progress) #6509
Comments
|
Same issue here |
|
I'm seeing a cluster of issues that seem to be based on VSCode not being able to stop and/or remove running containers. The rebuild, described above, is the most reliable one. Sometimes when I re-open the project locally, the container persists and keeps running. Containers keep running beyond VSCode being quit entirely. In all of these situations, once the error state is encountered, the only way to stop the container is to restart docker desktop entirely. Docker itself can't stop the containers. These issues are new! Everything was rock-solid a mere couple weeks ago, when I was able to tweak and rebuild containers repeatedly without issue. My system:
It's the same on both the regular VSCode and on Insiders, with these versions:
Here's what it looks like in action.
remoteContainers-.....log
installed pre-release of remote-container plugin and said rebuild and reopen to get this:
|
|
Related my last comment, there's also another NEW transient issue where the in-VSCode terminal lags, never appears, or completely hangs when connected to a container. Sometimes it never appears when reloading into the container environment. Sometimes it works fine, then after the first or second command never returns to the prompt, hanging forever. When this happens, if I reload the project locally, the container doesn't stop running. If I try to stop it with Docker Desktop, I eventually get this nice error:
This makes me think it has something to do with the core control code that VSCode uses; the software that runs in the container is hung and isn't responding, preventing shutdown. |
|
I'm not entirely sure your issue is related @marksherman. You should open a separate issue. Anyways, I'm also getting this issue. It almost seems like the container is eagerly removed before quitting and then when VSCode launches it wants to ensure the container is removed, but it already is. This is happening to me inside of a |
|
I've also been seeing this issue over the last week or so, with steps to reproduce and log output identical to what @dmartin originally posted. Try to rebuild container, fail on removing container, click Retry, second rebuild works. My config:
Please let me know if there's any additional information you need, happy to provide! |
|
same issue here. version: 1.68.0 |
|
@theonlyfoxy Could you append your log from when this happens? ( |
|
Also experience this, I'll try to get logs next time. |
@chrmarti I attempted to run Remote-Containers: Show Container Log after clicking "more actions" after the failure, didn't see anything happen as far as logs. Regardless here is some of the text I can see:
I couldn't copy the text from this error, but here's a screenshot with the tail end of the path cropped.
|
|
I've found that if VS Code is, for any reason, delayed then you don't get this issue. Seems like it is not waiting entirely for the container to shut down before reopening it. On Mac OS 12 |
|
I'm seeing this as well, just about every time I rebuild the container on an M1 mac. If i click the |
|
Trying to reopen project in Container and got this error message: Env: Docker: VS Code: Log: [2022-10-07T21:49:40.025Z] Error: Command failed: docker-compose -f /Users/someuser/Projects/someteam/sko/composer/docker-compose.yml --profile * config
[2022-10-07T21:49:40.025Z] at no (/Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js:288:900)
[2022-10-07T21:49:40.025Z] at process.processTicksAndRejections (node:internal/process/task_queues:96:5)
[2022-10-07T21:49:40.025Z] at async ZF (/Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js:259:1393)
[2022-10-07T21:49:40.025Z] at async XF (/Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js:241:2391)
[2022-10-07T21:49:40.025Z] at async bD (/Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js:303:2193)
[2022-10-07T21:49:40.025Z] at async ys (/Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js:303:3182)
[2022-10-07T21:49:40.025Z] at async UL (/Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js:423:10319)
[2022-10-07T21:49:40.025Z] at async ML (/Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js:423:10075)
[2022-10-07T21:49:40.027Z] Stop (425 ms): Run: /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js up --user-data-folder /Users/someuser/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-containers/data --workspace-folder /Users/someuser/Projects/someteam/sko/composer/packages/sko-fin-api --workspace-mount-consistency cached --id-label devcontainer.local_folder=/Users/someuser/Projects/someteam/sko/composer/packages/sko-fin-api --log-level debug --log-format json --config /Users/someuser/Projects/someteam/sko/composer/packages/sko-fin-api/.devcontainer/devcontainer.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root true
[2022-10-07T21:49:40.027Z] Exit code 1
[2022-10-07T21:49:40.030Z] Command failed: /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/someuser/.vscode/extensions/ms-vscode-remote.remote-containers-0.255.2/dist/spec-node/devContainersSpecCLI.js up --user-data-folder /Users/someuser/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-containers/data --workspace-folder /Users/someuser/Projects/someteam/sko/composer/packages/sko-fin-api --workspace-mount-consistency cached --id-label devcontainer.local_folder=/Users/someuser/Projects/someteam/sko/composer/packages/sko-fin-api --log-level debug --log-format json --config /Users/someuser/Projects/someteam/sko/composer/packages/sko-fin-api/.devcontainer/devcontainer.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root true
[2022-10-07T21:49:40.030Z] Exit code 1 |
|
Could you append the full log? |
I wasn't able to get the full log previously, is there a different process we could follow to get the full logs you're looking for? |
|
Here are the logs I get: Env: Docker: VS Code: VS Code Terminal logs: Are there other logs I should be looking to grab for you? |
|
@JohnRoesler That's all I need, thanks. |
|
Same error here as @DougPlumley, I am on M1 mac. @JamesHutchisonCarta, what do you mean "delayed"? I am struggling to avoid getting this error. |
|
@nimpy do you have any errors running your docker-compose file without cache( |
I may case, about a second would probably already be enough. |
|
A retry would be a good workaround, but there must be some effort in understanding why is it happening and how to prevent the extension into getting in that state. |
|
Still reproducible on 1.76.2. |
|
+1 with DockerDesktop on Mac. On a remote Linux machine, it seems fine. |
|
Still reproducible on 1.80.1, running devcontainer in wsl |
|
Same error with VSCode 1.83.1 + colima 0.5.5 as container runtime (on MacOS Monterey 12.7) |
|
Reproducible Pop_OS 22.04 + VSCode 1.83.1. Is there anything we can do to solve this. Some pointers in the right direction? Can we delay the removal of the container to verify our assumptions? |
|
Still happens in M1 with Sonoma 14.0 (23A344) + VSCode Version: 1.84.2 |
|
Same issue on VSCode version 1.85.2, Mac M1. Come on guys, this has been going on years. Please fix up. |
|
Still an issue with 1.86.0. But, this seems to happen less frequently for me vs previous versions |
|
Same issue for years now, and still present in 1.86.2. When you work on everyday basis in dev containers, this is a very frustrating issue. When stopping dev containers, VS Code should just wait for the docker compose resource removal to be over before starting a new instance. |
|
Fixed for the next pre-release. |
Brilliant! Out of curiosity, when it will be on GA? |
Awesome thank you @chrmarti! |
|
Please give it a try in Dev Containers 0.385.0-pre-release and let me know if that fixes it for you. Thanks! This fix will be in the September release which is about 1 month out (it will release alongside VS Code 1.94). |
|
thx for the fix ❤️ this bug was incredibly annoying. for years this didn't work reliably or at all. to me one thing still remains an issue: from my POV it looks like we will keep run into bugs like these until vscode-remote leaves the starting/stopping of the container(s) to the user. kindly request feedback/clarification. happy to create a separate issue for this. |
|
@fetzig Could you open a new issue for this? (There is an issue for the containers staying up when connecting through SSH.) Thanks. |
and others
Steps to Reproduce:
Does this issue occur when you try this locally?: N/A
Does this issue occur when you try this locally and all extensions are disabled?: Yes
The text was updated successfully, but these errors were encountered: