DevContainer: Exit code 137

I can not reopen folder to develop in a container.

Error message: An error occurred setting up the container.

[3142 ms] Installing VS Code Server for commit e8653663e8840adaf45af01eab5c627a5af81807
[3143 ms] Start: Installing VS Code Server
[3144 ms] Start: Run in container: mkdir -p /vscode/vscode-server/bin/linux-x64/e8653663e8840adaf45af01eab5c627a5af81807_1731177276323
[3191 ms] 
[3191 ms] 
[3308 ms] Start: Run in container: (dd iflag=fullblock bs=8192 count=7283; dd iflag=fullblock bs=6631 count=1) | tar --no-same-owner -xz -C /vscode/vscode-server/bin/linux-x64/e8653663e8840adaf45af01eab5c627a5af81807_1731177276323
[4618 ms] Exit code 137
[4618 ms] Keep-alive process ended.
[4619 ms] Start: Run in container: rm -rf /vscode/vscode-server/bin/linux-x64/e8653663e8840adaf45af01eab5c627a5af81807_1731177276323
[4622 ms] Shell server terminated (code: 137, signal: null)

My VM Workstation (Linux client):
Memory: 8GB
OS: RHEL8

After adding these runArgs

--memory=8g --memory-swap=2g

in devcontainer.json the error messages changes to

[2626 ms] Error: Command failed: docker run --sig-proxy=false -a STDOUT -a STDERR --mount type=bind,source=/home/myuser/LFS148-code,target=/workspaces/LFS148-code --mount type=volume,src=vscode,dst=/vscode -l devcontainer.local_folder=/home/myuser/LFS148-code -l devcontainer.config_file=/home/myuser/LFS148-code/.devcontainer/devcontainer.json -e SHELL=/bin/bash -e EXERCISES=/workspaces/LFS148-code/exercises --privileged --memory=8g --memory-swap=2g --entrypoint /bin/sh -l devcontainer.metadata=[{"customizations":{"vscode":{"settings":{"files.autoSave":"afterDelay","[python]":{"editor.formatOnSave":true},"[dockercompose][yaml]":{"editor.defaultFormatter":"redhat.vscode-yaml","editor.formatOnPaste":true,"editor.formatOnSave":true,"editor.insertSpaces":true,"editor.tabSize":2},"[adoc][markdown]":{"editor.defaultFormatter":"vscode.markdown-language-features","editor.formatOnPaste":true,"editor.formatOnSave":true,"editor.insertSpaces":true,"editor.tabSize":2},"[dockerfile]":{"editor.quickSuggestions":{"strings":true},"editor.defaultFormatter":"ms-azuretools.vscode-docker"},"python.analysis.typeCheckingMode":"strict","python.analysis.autoImportCompletions":true},"extensions":["vscjava.vscode-java-pack","vscjava.vscode-java-dependency","ms-python.vscode-pylance","charliermarsh.ruff","ms-python.isort","ms-python.python","njpwerner.autodocstring","KevinRose.vsc-python-indent","ms-python.black-formatter","usernamehw.errorlens","redhat.vscode-yaml","ms-azuretools.vscode-docker"]}},"containerEnv":{"SHELL":"/bin/bash","EXERCISES":"/workspaces/LFS148-code/exercises"},"overrideCommand":false,"portsAttributes":{"5000":{"label":"Python Flask app"},"5001":{"label":"Python Flask app"},"5432":{"label":"Postgres DB"},"8080":{"label":"Spring Boot Backend app"},"8090":{"label":"Spring Boot Thymeleaf app"},"9090":{"label":"Prometheus UI"},"16686":{"label":"Jaeger UI"}},"forwardPorts":[5000,5001,5432,8080,8090,9090,16686]}] ghcr.io/lftraining/lfs148-code-application:latest -c echo Container started

@Yumin-Sun-00

Hi @Yumin-Sun-00 could you maybe try running Ctrl + Shift + P or Command + Shift + P on MacOS and type Dev Containers: Rebuild and Reopen in Container?

@JenSeReal

Hi @JenSeReal

I provision a EC2 instance with Instance type m4.2xlarge, which means

And I remove my changes and have tried:

Dev Containers: Rebuild and Reopen in Container
Dev Containers: Rebuild Without Cache and Reopen in Container

Both returns with exit code 137.

@JenSeReal

Hi @JenSeReal

I provision a EC2 instance with Instance type m4.2xlarge, which means
And I remove my changes and have tried:
Dev Containers: Rebuild and Reopen in Container Dev Containers: Rebuild Without Cache and Reopen in Container

Both returns with exit code 137.

Maybe more system informarion of my EC2 instance might helpful?

# cat /proc/meminfo
MemTotal:       32639544 kB
MemFree:        26015840 kB
MemAvailable:   31394256 kB
Buffers:            3924 kB
Cached:          5590628 kB
SwapCached:            0 kB
Active:          1111928 kB
Inactive:        4852000 kB
Active(anon):       2084 kB
Inactive(anon):   393912 kB
Active(file):    1109844 kB
Inactive(file):  4458088 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB

Hi, I am not sure, if the problem originates from the memory config of your VM instance.

Can you give some more details about your setup. I understood RHEL8.
Which version of Docker do you use? Which version of VSCode?

If you use the way Jens has described before, there also is an option "Dev Containers: Show container log"
Can you please provide that? This would probably give us more background.
Or was the log snippet above the entire log?

If the rebuild step from above did not work, you may want to try to delete the stopped container instance and image directly via docker commands and completely start from scratch.

In general I am not sure if it makes a lot of sense to deploy a VM instance only for this purpose.
An complete alternative approach would be to use GitHub Codespaces for doing the lab. Here is a link how to set one up:
https://github.com/codespaces/new?skip_quickstart=true&machine=basicLinux32gb&repo=751957128&ref=main&devcontainer_path=.devcontainer%2Fdevcontainer.json

Here is some general codespace documentation, if this is new for you: https://docs.github.com/en/codespaces

@maeddes

Hi, I am not sure, if the problem originates from the memory config of your VM instance.

Can you give some more details about your setup. I understood RHEL8. Which version of Docker do you use? Which version of VSCode?

If you use the way Jens has described before, there also is an option "Dev Containers: Show container log" Can you please provide that? This would probably give us more background. Or was the log snippet above the entire log?

If the rebuild step from above did not work, you may want to try to delete the stopped container instance and image directly via docker commands and completely start from scratch.

In general I am not sure if it makes a lot of sense to deploy a VM instance only for this purpose. An complete alternative approach would be to use GitHub Codespaces for doing the lab. Here is a link how to set one up: https://github.com/codespaces/new?skip_quickstart=true&machine=basicLinux32gb&repo=751957128&ref=main&devcontainer_path=.devcontainer%2Fdevcontainer.json

Here is some general codespace documentation, if this is new for you: https://docs.github.com/en/codespaces

Hi @maeddes ,

# docker --version
Docker version 27.3.1, build ce12230

VS Code version: 1.95.2 (user setup)

Dev Containers version: v0.388.0

Delete images and containers I have to keep everything clean before rebuild:

# docker images
REPOSITORY    TAG       IMAGE ID       CREATED         SIZE
hello-world   latest    d2c94e258dcb   18 months ago   13.3kB

# docker ps -a
CONTAINER ID   IMAGE         COMMAND    CREATED             STATUS                         PORTS     NAMES
b639d9e02e9c   hello-world   "/hello"   About an hour ago   Exited (0) About an hour ago             amazing_torvalds

Now: In VS Code, reopen in containers --> exit code 137. Here is the logs:

[1180 ms] Dev Containers 0.388.0 ov.txt

Thanks for providing alternative. I will have a look now.

@maeddes

Hi, I am not sure, if the problem originates from the memory config of your VM instance.
Can you give some more details about your setup. I understood RHEL8. Which version of Docker do you use? Which version of VSCode?
If you use the way Jens has described before, there also is an option "Dev Containers: Show container log" Can you please provide that? This would probably give us more background. Or was the log snippet above the entire log?
If the rebuild step from above did not work, you may want to try to delete the stopped container instance and image directly via docker commands and completely start from scratch.
In general I am not sure if it makes a lot of sense to deploy a VM instance only for this purpose. An complete alternative approach would be to use GitHub Codespaces for doing the lab. Here is a link how to set one up: https://github.com/codespaces/new?skip_quickstart=true&machine=basicLinux32gb&repo=751957128&ref=main&devcontainer_path=.devcontainer%2Fdevcontainer.json
Here is some general codespace documentation, if this is new for you: https://docs.github.com/en/codespaces

Hi @maeddes ,
# docker --version
Docker version 27.3.1, build ce12230
VS Code version: 1.95.2 (user setup)

Dev Containers version: v0.388.0

Delete images and containers I have to keep everything clean before rebuild:
# docker images
REPOSITORY    TAG       IMAGE ID       CREATED         SIZE
hello-world   latest    d2c94e258dcb   18 months ago   13.3kB

# docker ps -a
CONTAINER ID   IMAGE         COMMAND    CREATED             STATUS                         PORTS     NAMES
b639d9e02e9c   hello-world   "/hello"   About an hour ago   Exited (0) About an hour ago             amazing_torvalds
Now: In VS Code, reopen in containers --> exit code 137. Here is the logs:

[1180 ms] Dev Containers 0.388.0 ov.txt

Thanks for providing alternative. I will have a look now.

I found in the logs there is another exit code 128 before exit code 137:

fatal: detected dubious ownership in repository at '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/workspaces/LFS148-code'
To add an exception for this directory, call:

    git config --global --add safe.directory /workspaces/LFS148-code

Do you think this could be the cause?

I think it could be, but I can't verify (yet). We've never seen this issue and we can't reproduce it

You could try to set the save directory in a startup command like this postStartCommand": "git config --global --add safe.directory ${containerWorkspaceFolder} in devcontainer.json.

@JenSeReal

Hi @JenSeReal ,

I have tried different versions of such commands

"initializeCommand": "sudo git config --system --add safe.directory '*'",
"postStartCommand": "sudo git config --system --add safe.directory '*'",

"initializeCommand": "git config --global --add safe.directory /workspaces",
"postStartCommand": "git config --global --add safe.directory  /workspaces",

"initializeCommand": "git config --global --add safe.directory ${containerWorkspaceFolder}",
"postStartCommand": "git config --global --add safe.directory ${containerWorkspaceFolder}",

None of them worked. I currently give up on this, and will try the codespaces as maeddes recommended.

Thanks for your support, I am appreciated on that.

@Yumin-Sun-00

Hi @Yumin-Sun-00

thanks for the updates here. We were still unable to reproduce this behaviour on our end.

If we get the chance, can you let us some details, about the VM and in particular the OS and settings.
I would really like to figure this out before more people step into these problems.

many thanks for patience here!

@maeddes

Hi @maeddes

I was also thinking about it is because of VM workstation, therefore at the beginning I provision a ec2 instance to try again.

I think this is more related to Git new security features, that the owner of files must match to the user who perform git operations. I found in github there were/are issues/discussions about this new features, some solutions are proposed. But it seems like there are still people suffering from this.

It sounds like it is about when .gitconfig will be copy pasted from host into the container.

From this perspective, I think it is less relevant to VMs, though at the beginning I indeed had such idea, therefore you see I provisioned a new ec2 instance.

I see 2 options to fix this, however I am not familiar with docker container.

What could make sure .gitconfig will be copied from local host into container.
Create a user inside container that matches the owner of repository.

I just roughly say out my opinions, but I do not know whether this is promising.

BTW the codes pace things also not work by me, not sure whether it is because I am using my company laptop....

Have a good day!

🍻

You could also maybe try to download the repo as a zip file or to just delete the .git/ folder

You could also maybe try to download the repo as a zip file or to just delete the .git/ folder

Hey, that is a good idea! I get rid of the exit code 128 now 🎶🤩🥳

However, it still not work 🥲😂😂😂😂😂😂😂😂 Here is the log...I am done with this, I have to move on. It is a nice tutorial though that I wish to have a look very long time.

[2024-11-12T152355.546Z] Dev Contai.txt

first of all thanks for providing all the feedback here. If we can resolve it we will reach out to you. Sorry we couldn't make it work yet

Hi,

I had the same problem on my Fedora 43. I solved it with these changes:

devcontainer.json
entrypoint.sh

i don't know how cannot attach the dockfile so i paste the content here:

FROM maven:3-eclipse-temurin-21

ARG DEBIAN_FRONTEND=noninteractive
ENV PIP_ROOT_USER_ACTION=ignore

RUN set -eux;
apt-get update;
apt-get install -y --no-install-recommends
ca-certificates
curl
bash
git
build-essential
python3.12
python-is-python3
python3-dev
python3-pip
python3-setuptools
python3-wheel
python3-psutil
docker.io;
rm -rf /var/lib/apt/lists/*

ENV JAVA_HOME=/usr/lib/jvm/temurin-21-jdk-amd64
ENV PATH="$JAVA_HOME/bin:$PATH"

RUN rm -f /usr/lib/python3*/EXTERNALLY-MANAGED

COPY requirements.txt /tmp/requirements.txt
RUN pip install --no-cache-dir -r /tmp/requirements.txt &&
rm /tmp/requirements.txt

WORKDIR /workspace

EXPOSE 5000

CMD ["bash"]

Navigation Menu

Repository navigation

DevContainer: Exit code 137 #2

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

DevContainer: Exit code 137 #2

Description

Activity

Yumin-Sun-00 commented on Nov 9, 2024

JenSeReal commented on Nov 10, 2024

Yumin-Sun-00 commented on Nov 10, 2024

Yumin-Sun-00 commented on Nov 10, 2024

maeddes commented on Nov 10, 2024

Yumin-Sun-00 commented on Nov 10, 2024

Yumin-Sun-00 commented on Nov 10, 2024

maeddes commented on Nov 10, 2024

JenSeReal commented on Nov 11, 2024

Yumin-Sun-00 commented on Nov 12, 2024

maeddes commented on Nov 12, 2024

Yumin-Sun-00 commented on Nov 12, 2024

JenSeReal commented on Nov 12, 2024

Yumin-Sun-00 commented on Nov 12, 2024

maeddes commented on Nov 12, 2024

Nazario-DApote commented on Feb 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions