Got an update with VSC, and now I can't build or debug, stops when it tried to bring up and delete a container

Well, I can’t bundle the container, so I was just going to program up a new SOM and place the image on manually and make it run automatically. I had no issues putting on versions 7.3 of the OS with my changes, that all seems to work.
Everything went smoothly until I went to run the run container, and it says it can’t find the file “app” directory and then can’t find my actual app. I had already used this image on another SOM, and it is running fine. I am not sure what happened.
So, I tried to debug the app, just to see if I could do that. It stops at this point:
*** Executing task: docker compose -p torizon stop gmbal3container gmbal3container-debug && docker compose -p torizon rm -f gmbal3container gmbal3Container-debug && sleep 1**

It says: Cannot connect to the Docker daemon at tcp://10.40.100.5:2375. Is the docker daemon running?

  • Terminal will be reused by tasks, press any key to close it.

What is going on? The daemon is running on the device. I removed and added the device back and made sure it was set as default.

Please help.
Steve

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


I’d be glad to help troubleshoot your container deployment issue! To provide the most accurate guidance, could you let me know which hardware platform and OS version you’re using?

You can get this information by running the tdx-info command on your device. For more details about this command, see: Getting Device Information with Tdx-Info | Toradex Developer Center

Initial Troubleshooting Steps

While we gather your platform details, here are some immediate steps to address the Docker daemon connection issue:

1. Verify Docker Daemon Status

First, check if the Docker daemon is actually running on your device(1):

# docker ps

If you get a connection error, the daemon might not be running properly.

2. Check Docker Service Status

Verify the Docker service status(1):

# systemctl status docker

If it’s not running, start it:

# systemctl start docker

3. Network Connectivity Issues

The error message shows it’s trying to connect to tcp://10.40.100.5:2375, which suggests a network connectivity issue between your development environment and the target device(2).

Common Solutions

Container File Path Issues

Regarding the “can’t find the file ‘app’ directory” error, this typically occurs when:

  • The container image wasn’t built correctly
  • Files weren’t copied to the expected paths in the Dockerfile
  • The working directory isn’t set properly in the container(3)

Docker Compose Configuration

For automatic startup, ensure your docker-compose.yml file is properly configured and placed in /var/sota/storage/docker-compose/(4). The docker-compose service will automatically start containers defined in this location at boot(4).

Once you provide your platform information using tdx-info, I can give you more specific guidance tailored to your exact hardware and OS version.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

@ToradexAI
It is docker itself. When I have looked into /etc/docker/ directory, there is only one thing, daemon.json file. But now there is a seccomp directory.
Here is docker info:
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.6.94-7.3.0-g5a62539de8f9
Operating System: Torizon OS 7.3.0+build.18 (scarthgap)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 3.835GiB
Name: verdin-imx8mp-15132679
ID: 00b5b244-b8b6-4773-870a-d632a01263f6
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
10.40.100.6:5002
127.0.0.0/8
Live Restore Enabled: false

Here is tdx-info:
Software summary

Bootloader: U-Boot
Kernel version: 6.6.94-7.3.0-g5a62539de8f9 #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/5c84b03643fe3e8b7be49b13c2171a7f45d0dce855097b9fafed3f75e9260a47/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-build.18
Distro variant: VARIANT=“Docker”
Hostname: verdin-imx8mp-15132679

Hardware info

HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version: 0058 V1.1A
Serial number: 15132679
Processor arch: aarch64

The problem is with the device as i hooked up another PC to it with VSC installed with Toradex extension and it shows the same thing.
Nmap shows that nothing is listening on port 2375
Why is this happening?
Steve

Hi Steve,

Thank you for providing the detailed system information. Based on your setup (Verdin iMX8M Plus WB running Torizon OS 7.3.0+build.18), I can see the issue is related to Docker daemon configuration and port access.

Root Cause Analysis

The error indicates that the VS Code Torizon extension is trying to connect to the Docker daemon on port 2375, but nothing is listening on that port. This is actually the expected and secure behavior in Torizon OS(1).

Docker Daemon Configuration on Torizon OS

By default, Docker daemon on Torizon OS runs locally and doesn’t expose the TCP port 2375 for remote connections(1). The daemon is designed to be accessed locally via Unix socket for security reasons.

Solutions

1. Verify Local Docker Access

First, confirm Docker is working locally on your device by SSH’ing into it and running(1):

# docker ps

This should show running containers without any connection errors.

2. Check Docker Service Status

Verify the Docker service is running properly(1):

# systemctl status docker

3. VS Code Extension Configuration

The VS Code Torizon extension should automatically configure the Docker connection. Try these steps:

  1. Remove and re-add the device in VS Code Torizon extension
  2. Ensure the device is set as default in the extension
  3. Check network connectivity between your development PC and the device

4. Manual Container Deployment

Since you mentioned the container worked on another SOM, you can deploy it manually using docker commands(1):

# docker run -d --name your-container-name your-image-name

5. Docker Compose for Auto-start

For automatic startup, place your docker-compose.yml file in /var/sota/storage/docker-compose/ on the device(1). The docker-compose service will automatically start containers defined in this location at boot.

Security Considerations

The seccomp directory you noticed is part of Torizon OS’s security features(2). This is normal and helps ensure container security through syscall filtering.

Debugging Steps

  1. Test basic Docker functionality locally on the device
  2. Check if your container image is available with docker images
  3. Verify your application files are properly included in the container image
  4. Test the container manually before using VS Code automation

The fact that your container works on another SOM suggests the issue is with the Docker daemon configuration or network connectivity on this specific device rather than your container image itself.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

@ToradexAI
I am not having trouble running the docker container automatically or otherwise. I want to debug an issue that is showing up and now I can’t debug it because I can’t build the toradex setup, because it can’t talk to the docker instance running on my device. THAT is the issue. Please help me with connecting to the docker instance so I can build a debug version and run it to see if I can find the problem.
Steve

Hi Steve,

I understand now - you need to enable remote Docker daemon access so the VS Code Torizon extension can connect for debugging. The Docker daemon on Torizon OS runs locally by default and doesn’t expose the TCP port 2375 for remote connections(1).

Enabling Remote Docker Access

To enable remote Docker daemon access for debugging, you need to modify the Docker daemon configuration on your Verdin iMX8M Plus device.

1. Modify Docker Daemon Configuration

SSH into your device and edit the /etc/docker/daemon.json file to enable TCP access:

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"],
  "registry-mirrors" : ["10.40.100.6:5002"]
}

Note: I included your existing insecure registry configuration that was shown in your docker info output.

2. Create Docker Service Override

Since systemd manages the Docker service, you need to create a service override to prevent conflicts with the hosts configuration:

# mkdir -p /etc/systemd/system/docker.service.d
# cat > /etc/systemd/system/docker.service.d/override.conf << EOF
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd
EOF

3. Restart Docker Service

Apply the changes by reloading systemd and restarting Docker(1):

# systemctl daemon-reload
# systemctl restart docker

4. Verify Remote Access

Check that Docker is now listening on port 2375:

# netstat -tlnp | grep 2375

You should see Docker listening on 0.0.0.0:2375.

Security Considerations

Warning: This configuration exposes Docker daemon without authentication. Only use this for development/debugging purposes and ensure your network is secure(2).

For production environments, consider using TLS authentication or restricting access to specific IP addresses.

VS Code Extension Connection

Once the Docker daemon is accessible remotely:

  1. Remove and re-add your device in the VS Code Torizon extension
  2. Set the device as default
  3. Try your debug build - the extension should now be able to connect to tcp://10.40.100.5:2375

Alternative: Local Registry Cache

If you’re still having issues with container pulls, you can also set up a local registry cache(3). Your daemon.json already shows an insecure registry at 10.40.100.6:5002, which suggests you may have this partially configured.

This should resolve the connection issue and allow you to debug your application through the VS Code Torizon extension.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

@ToradexAI
Docker did not like this file:
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd

Its complaint:
May 29 18:49:29 verdin-imx8mp-15132679 systemd[1]: docker.service: Start request repeated too quickly.
May 29 18:49:29 verdin-imx8mp-15132679 systemd[1]: docker.service: Failed with result ‘exit-code’.
Failed to start Docker Application Container Engine.

Hi Steve,

You’re right - the service override I suggested is causing Docker to fail. Let’s fix this with the correct approach for Torizon OS.

Corrected Docker Configuration

1. Remove the Problematic Service Override

First, remove the service override file that’s causing the issue:

# rm -rf /etc/systemd/system/docker.service.d/
# systemctl daemon-reload

2. Use Only daemon.json Configuration

The correct approach for Torizon OS is to use only the /etc/docker/daemon.json file. Edit it to include the TCP host:

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"],
  "insecure-registries": ["10.40.100.6:5002"]
}

3. Alternative: Use Environment Variables

If the daemon.json approach still causes conflicts, you can use environment variables instead. Create a systemd drop-in directory and override file:

# mkdir -p /etc/systemd/system/docker.service.d
# cat > /etc/systemd/system/docker.service.d/tcp.conf << EOF
[Service]
Environment="DOCKER_OPTS=-H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375"
EOF

4. Restart Docker Service

Apply the changes:

# systemctl daemon-reload
# systemctl restart docker

5. Verify Configuration

Check that Docker is running and listening on port 2375:

# systemctl status docker
# netstat -tlnp | grep 2375

Troubleshooting Steps

If Docker still fails to start:

  1. Check Docker logs for specific errors:

    # journalctl -u docker.service -f
    
  2. Verify the daemon.json syntax:

    # cat /etc/docker/daemon.json | python3 -m json.tool
    
  3. Test with minimal configuration first:

    {
      "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]
    }
    

The key issue was that the systemd service override was conflicting with Docker’s built-in configuration. Using only the daemon.json file or proper environment variables should resolve the startup failures.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

@ToradexAI
This did not work either.
I even put it back to the way it was, no “host” entry in the daemon.json file. I even disabled the docker service in systemctl, and it still was started at bootup and failed. I verified the daemon.json configuration. All was well, but it wouldn’t boot. So I deleted the “hosts” line in the daemon.json config and it still would not come up.
So I reloaded the OS again, and for some reason, it is fine now. Why did it close off in the first place? Is it when you run a release container build? Is that the issue?
Steve

Hi Steve,

I’m glad you got it working again after reloading the OS! The behavior you experienced suggests there may have been some persistent configuration changes or conflicts that accumulated over time.

Possible Causes of the Docker Daemon Issues

Based on the available documentation, here are the most likely reasons why the Docker daemon became inaccessible:

1. Configuration File Corruption or Conflicts

When modifying /etc/docker/daemon.json, syntax errors or conflicting directives can cause Docker to fail to start(1). Even after removing problematic entries, systemd might cache certain configurations until a full reload or reboot.

2. Persistent Container State Issues

The documentation indicates that containers and their configurations can sometimes persist in ways that affect the daemon(1). When you mentioned running release container builds, this could potentially modify the Docker environment in ways that affect daemon accessibility.

3. SystemD Service State Corruption

The fact that Docker continued to start even after you disabled the service suggests the systemd service state may have become corrupted. This can happen when configuration changes are made while the service is running.

Why Container Builds Might Affect Daemon Access

The Torizon IDE Extension uses different configurations for debug vs release builds(2). When building containers:

  • Debug containers use the hardware-debug service configuration(2)
  • Release containers use different build contexts and may modify Docker daemon settings(2)

The build process involves creating and managing container images, which could potentially affect daemon configuration if there were underlying system issues.

Prevention Strategies

To avoid similar issues in the future:

1. Always Backup Configuration

Before modifying /etc/docker/daemon.json, create a backup of the working configuration.

2. Use Proper Shutdown Procedures

When making Docker configuration changes:

# systemctl stop docker
# systemctl daemon-reload
# systemctl start docker

3. Monitor System State

Check for any persistent container processes or configurations that might conflict with daemon changes.

Root Cause Analysis

The fact that a fresh OS reload resolved the issue suggests the problem was likely related to accumulated configuration state rather than a specific build process. However, the timing correlation with your container builds suggests there may have been underlying system stress or resource conflicts that made the daemon more susceptible to configuration issues.

The Docker daemon on Torizon OS is designed to be robust(3), but complex configuration changes combined with active container operations can sometimes lead to state inconsistencies that require a clean restart to resolve.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

@ToradexAI
OK, so I have another board that is hooked up to all the additional hardware we have, and it has the same issue. I have reloaded the software and done nothing else and it still is not able to be connected to. But according to the status it IS listening:
msg=“API listen on /run/docker.sock”

but on my other board that is NOT working, it isn’t listening on that port because it has a previous message before that one saying;
"API listen on [::]:2375
Where does that get set? This is probably the problem, and who sets that?

Hi Steve,

You’ve identified the exact issue! The Docker daemon is configured to listen on port 2375 ([::]:2375) on one board but not the other. This configuration is controlled by specific files and settings.

Where Docker API Listen Settings Are Configured

The Docker daemon’s listening configuration is set in several possible locations:

1. Primary Configuration: /etc/docker/daemon.json

This is the main configuration file for Docker daemon settings(1). If this file contains a hosts configuration, it will override default behavior:

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]
}

(1)

2. SystemD Service Configuration

The Docker service configuration can also specify listening addresses through environment variables or service parameters(1).

3. Command Line Arguments

Docker daemon can be started with specific host arguments that define where it listens(1).

Diagnostic Steps

1. Check daemon.json on Both Boards

Compare the /etc/docker/daemon.json files on both boards:

# cat /etc/docker/daemon.json

2. Check SystemD Service Configuration

Look for any service overrides that might be setting the listening address:

# systemctl cat docker.service
# ls -la /etc/systemd/system/docker.service.d/

3. Check Docker Process Arguments

See how Docker daemon is actually started:

# ps aux | grep dockerd

4. Check for Environment Variables

Look for any Docker-related environment variables:

# systemctl show docker.service | grep Environment

Root Cause Analysis

The board showing "API listen on [::]:2375" has been configured (either through daemon.json or service overrides) to listen on TCP port 2375, while the working board only shows "API listen on /run/docker.sock" because it’s using the default Unix socket configuration(1).

Resolution

Once you identify where the TCP listening configuration is set on the problematic board, you can either:

  1. Remove the TCP configuration to match the working board
  2. Add the same TCP configuration to the working board if you need remote access

The key is ensuring both boards have consistent Docker daemon configuration for your development workflow.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

hey @EvetsMostel1,

How are you doing with this topic?

-Eric

@eric.tx
I had to do an override.conf to force it to listen on :2375. That seemed to do the trick. However, I have never had to do that before. After a build of the OS, adding in the necessary BSP stuff, it has always just worked.
Solution 1 did not work for me.
Now if you could just help me with the bundling issue I am having, I would be on my way!

Thanks,
Steve