Failed to connect to Docker

Technical Support
, , , ,
1

Hello!

I have a Colibri i.MX7 Module with Torizon 7.2 installed

In my first try I built a little Test QT application using VSCode and QTCreator under Ubuntu 24.04. This worked fine on my my module with an image built using Torizon Core Builder and the default iris board and 7’’ display overlay.

Now I modified the tcbuild.yaml file to include my own device tree without an overlay. In this configuration the module starts without any problems, but when I try to deploy a QT application to the module, the Docker daemon on the module can no longer be reached by the Torizon Core builder plugin of VSCode.

I checked that Docker is still up and running, but does not seem to open a port using the -H parameter:

ps auxw | grep docker
root       624  0.1  5.6 664340 57728 ?        Ssl  09:14   0:15 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
torizon   1028  0.0  0.0   2008   896 ttymxc0  S+   11:31   0:00 grep docker

What could be the reason that this is no longer working and how to fix it without directly tweaking the systemd service file

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

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

Docker Daemon Connection Issue with Custom Device Tree

Hello! Based on your description, the issue appears to be related to how your custom device tree configuration affects the Docker daemon’s network accessibility from the VS Code extension.

Understanding the Problem

When you switched from using the default device tree with overlay to your custom device tree without overlay, you likely modified network-related configurations that affect how Docker exposes its API endpoints. The Docker daemon is running (as shown by your ps output), but the VS Code Torizon extension cannot reach it remotely.

Troubleshooting Steps

1. Verify Network Configuration

Check if your custom device tree affects network interface initialization or configuration that might impact Docker’s ability to bind to network interfaces.

2. Check Docker Service Configuration

The Docker daemon is running with -H fd:// which uses file descriptors for communication(1). For remote access, Docker typically needs additional host configurations.

3. Device Tree Comparison

Compare your custom device tree with the working configuration. Focus on:

  • Network interface definitions
  • GPIO configurations that might affect network hardware
  • Clock configurations for network controllers

4. TorizonCore Builder Configuration

When creating your custom image with TorizonCore Builder, ensure your tcbuild.yaml properly configures the device tree(2). The configuration should look like:

customization:
  device-tree:
    include-dirs:
      - linux/include
    custom: path/to/your/custom/device-tree.dts

5. VS Code Connection Settings

In VS Code, verify that the Torizon extension can still discover and connect to your device(3). The extension scans the local network for devices, and network configuration changes might affect device discovery.

Recommended Solution

  1. Review your custom device tree for any network-related changes compared to the working overlay configuration
  2. Ensure network interfaces are properly configured in your custom device tree
  3. Test network connectivity between your development machine and the module
  4. Verify the Docker daemon configuration hasn’t been inadvertently modified by the device tree changes

If the issue persists, consider temporarily reverting to the overlay-based approach to isolate whether the problem is specifically related to your device tree modifications.

Best regards,
Toradex AI Assistant.

3

@ToradexAI
Hello!

The network is up and running: I can connect to the module using ssh, the Torizon VSCode plugin can open an SSH terminal session and reboot the module, it just cannot connect to the Docker daemon due to the missing configuration

tdx-info

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.85-7.2.0-00045-gf1a07aac82ca #1-Torizon SMP PREEMPT Thu Feb 27 10:29:52 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.0/torizon/70fa9f81bb49be200a65d6ad01fc35705bfd2dbab785403d7df85afa52bc276e/0
Distro name:              NAME="Torizon OS Upstream"
Distro version:           VERSION_ID=7.2.0-build.13
Distro variant:           VARIANT="Docker"
Hostname:                 colibri-imx7-emmc-15723871
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Colibri iMX7D on LDP030 Mainboard
Toradex version:          0039 V1.1B
Serial number:            15723871
Processor arch:           armv7l
------------------------------------------------------------
4

In the meantime I reverted back the device tree settings to the original values, but this did not help. The error is still the same

5

@ToradexAI

This is what is printed in the Terminal window when running the
start-gdb-server-remote-arm
task:

 *  Executing task: pkill nc.traditional || true 

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

 *  Executing task: xonsh .conf/validate-deps-running.xsh 


⚠️ VALIDATING ENVIRONMENT

OS:         Linux
OS Version: 6.14.0-29-generic
OS Arch:    x86_64
Under WSL:  false
VS Code:
1.103.2
6f17636121051a53c88d3e605c491d22af2ba755
x64

TOR Extension:  toradex.apollox-vscode@3.1.1

✅ Environment is valid!

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

 *  Executing task: bash -c [[ ! -z "192.168.30.112" ]] && true || false 

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

 *  Executing task: bash -c [[ "armv7l" == "armv7l" ]] && true || false 

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

 *  Executing task: sleep 1 

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

 *  Executing task: sshpass -p ******* scp -P 22 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no /home/moeller/Development/VSStudioQtTest/VSSQtTest/docker-compose.yml torizon@192.168.30.112:~/ 

Warning: Permanently added '192.168.30.112' (ED25519) to the list of known hosts.
 *  Terminal will be reused by tasks, press any key to close it. 

 *  Executing task: /home/moeller/Development/VSStudioQtTest/VSSQtTest/.conf/remove-dangling-images.xsh 192.168.30.112:2375 

Waiting for prune lock on host 192.168.30.112:2375
Pruning dangling images on 192.168.30.112:2375
Cannot connect to the Docker daemon at tcp://192.168.30.112:2375. Is the docker daemon running?
 *  Terminal will be reused by tasks, press any key to close it. 

 *  Executing task: docker compose -p torizon stop qttest qttest-debug && docker compose -p torizon rm -f qttest qttest-debug 

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

 *  The terminal process "/usr/bin/bash '-c', 'docker compose -p torizon stop qttest qttest-debug && docker compose -p torizon rm -f qttest qttest-debug'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it.
6

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Docker Daemon TCP Port Configuration Issue

Based on your error output, the VS Code extension is trying to connect to Docker on port 2375 (tcp://192.168.30.112:2375) but cannot reach it. The Docker daemon is running with -H fd:// which only provides local socket communication, not TCP network access(1).

Root Cause

The Docker daemon on your Torizon OS device is not configured to accept TCP connections on port 2375. This is why the VS Code extension cannot connect remotely, even though SSH and other network services work fine.

Solution: Enable Docker TCP Access

You need to configure the Docker daemon to listen on TCP port 2375. Since you want to avoid directly modifying systemd service files, you can use TorizonCore Builder to create a custom image with the proper Docker configuration.

Method 1: Using TorizonCore Builder with Custom Configuration

  1. Create a custom Docker daemon configuration by adding a file that will configure Docker to listen on TCP port 2375(2).

  2. Use the union command in TorizonCore Builder to apply this configuration to your custom image(2).

  3. Deploy the updated image to your device using the deploy command(2).

Method 2: Runtime Configuration (Temporary)

For immediate testing, you can temporarily enable TCP access by modifying the Docker service configuration on the device:

  1. SSH into your device
  2. Edit the Docker service configuration to add TCP listening
  3. Restart the Docker service

However, this change will be lost on the next system update, so the TorizonCore Builder approach is recommended for production.

Verification

After applying the configuration, you should see Docker listening on port 2375:

netstat -tlnp | grep 2375

The Docker daemon should then show both file descriptor and TCP listening options in the process list.

Important Security Note

Opening Docker’s TCP port without TLS authentication poses security risks. Consider implementing proper authentication or restricting access to trusted networks only(1).

Best regards, Toradex AI Assistant.

7

@ToradexAI
Thank you for your suggestion. I will come back to you if your solution is working.

In order to find out, what destroyed my setup: How is the TCP configuration of the Docker done when I am using the default image without any modifications?

8

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Default Docker Configuration in Torizon OS

In the default Torizon OS image, Docker is configured to enable remote access for development purposes. The VS Code extension expects to connect to Docker on TCP port 2375 for remote debugging and deployment operations (1).

How the VS Code Extension Connects

When you connect a target device using the Torizon IDE Extension, it automatically configures the connection to the Docker daemon (1). The extension scans your network for devices and establishes both SSH and Docker connections (1).

Default Docker Service Configuration

In an unmodified Torizon OS image, the Docker daemon is typically configured to accept both:

  • Local connections via Unix socket
  • Remote TCP connections on port 2375 for development tools

This allows the VS Code extension to:

  1. Connect to the device for SSH operations (1)
  2. Access the Docker daemon remotely for container operations (1)
  3. Deploy and debug applications directly from the IDE (1)

What May Have Changed

Since you mentioned that reverting the device tree changes didn’t restore functionality, the issue might be related to:

  1. Image customization process - When building custom images with TorizonCore Builder, certain Docker configurations might not be preserved
  2. Service initialization order - Custom device tree changes could affect how services start up
  3. Network interface timing - Changes in hardware initialization might affect when Docker binds to network interfaces

Workspace Settings Impact

The Torizon IDE Extension uses workspace settings to manage Docker connections (2). Key settings include:

  • host_ip - IP address of the development machine (2)
  • torizon_arch - Target device architecture (2)
  • Various debug port configurations (2)

These settings are automatically configured when you connect a device, but custom image modifications might interfere with this process.

Recommendation

To restore the default Docker TCP configuration, I recommend using a fresh Torizon OS base image and carefully reapplying only your essential device tree modifications using TorizonCore Builder’s device tree commands (3). This will help isolate which specific change caused the Docker configuration issue.

Best regards, Toradex AI Assistant.

9

Hello @alins,

I don’t think the issue that you see has anything to do with your custom device tree. It looks like a connection issue.

Have you already tried removing the device and adding it again?
You can try in the following order:
Remove device → Remove default → Add the device again → set default

This will refresh the settings.json file. After this, try rebuilding the application. Let me know if this helps improve the situation.

10

Hello @rudhi.tx

I think it has something to do with the Torizon IDE Extension of VSCode: After some Restarts of the VSCode IDE my new setup project did not work anymore. Sometimes a restart of the computer helps, sometimes not.

I think I will try to setup my project without the IDE plugin to have more control over the whole process.

Thank you for your assistance!
Andreas

11

Hello @alins,

That is a strange behavior. I will try to reproduce this behavior. I have Ubuntu 24.04 on my PC as well. I have never tried to build a Qt project for Colibri iMX7. So that could be interesting.

12

Hi @alins,

I just finished building my a Qt application here on my Colibri iMX7D module, running Torizon OS 7.3.0. The build was successful for me. I tested it on Colibri iMX7, Colibri evaluation board and a capacitive touch display.

I have seen a similar issue with connection once due to the torizon device (colibri) not setting the insecure registries properly. It should be defined correctly like:

torizon@colibri-imx7-emmc-07209912:~$ cat /etc/docker/daemon.json 
{
   "insecure-registries" : ["<host-ip>:5002"]
}

This is explained here: Connect a Target Device | Toradex Developer Center
After that you need to restart the docker daemon on the target:
sudo systemctl restart docker

If you still have the VSCode project, could you please give this a try?

13

Sorry for my late reply.
I was busy with another project and now had some hours to solve the problem.
I analysed the steps, the VSCode plugins are doing together with the help from the developer center and wrote me two shell scripts: One that generates a build system docker container for my development PC and one that generates a container for the target for debugging. After generation it is automatically copied to the colibri module.
I have a directory bound into the container so that I just have to upload my executable to be debugged to the remote host system and restart the debugging container on the device. This solution has a fast rebuild and deploy cycle and does exactly what I was looking for without the need of VSCode.
Thank you for your help anyway.

1 Like