Docker container registry not running

[nimble-william]

Hello,

I am encountering the following issue when I attempt to execute the task: run-container-torizon-release-arm64. This command worked a couple days ago (Saturday) to deploy the docker config to the board. The host computer has restartd since then, but nothing else about the environment has changed. The Torizon IDE extension does not show any initialization errors.

My issue is similar to this one: Docker container registry is not running! - That is resolved, but does not offer a clear-cut fix. Similar to that issue, I noticed that I was not logged into Docker Hub until after I got this error for the first time. I logged into Docker Hub successfully. the Docker extension shows that I’m connected and my remote container images, but this issue persists.

The Error:

⚠️ VALIDATING ENVIRONMENT

OS:         Linux
OS Version: 5.15.167.4-microsoft-standard-WSL2
OS Arch:    x86_64
Under WSL:  Torizon
VS Code:
1.99.3
17baf841131aa23349f217ca7c570c76ee87b957
x64

TOR Extension:  toradex.apollox-vscode@3.0.4
⚠️  Please make sure to reload the VS Code Window if you had initialization errors

❌ Docker container registry is not running!

Error cause: Not configured


 *  The terminal process "xonsh '.conf/validate-deps-running.xsh'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it. 

Output of the run-docker-registry initialization task

 *  Executing task: /home/puttrax/.local/bin/xonsh /home/puttrax/puttrax-torizon/.conf/run-container-if-not-exists.xsh --container-runtime docker --run-arguments "-d -p 5002:5000 --restart=always registry:2" --container-name registry 

Container Runtime: docker
Run Arguments: -d -p 5002:5000 --restart=always registry:2
Container Name: registry
Container registry already created
Checking if container registry is running...
 *  Terminal will be reused by tasks, press any key to close it. 

tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.84-7.2.0-g87bfb710b6f1 #1-Torizon SMP PREEMPT Mon Mar 31 08:47:48 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/157a467dd3b97eaebfbf6e17d0c8859fdd0abc1d397c637c6ecd808f79dc0260/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.2.0-build.13
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15601692
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0070 V1.1A
Serial number:            15601692
Processor arch:           aarch64
------------------------------------------------------------

Thank you,
William

[ToradexAI]

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?

---

Hello William,

Thank you for the detailed information. This situation looks closely related to your local Docker registry setup and how it interacts with WSL 2. Even if nothing else has changed, system restarts—especially with WSL 2—can disrupt key services or port bindings needed by the Torizon IDE for container deployment.

Here are steps to help you resolve this issue:

---

1. Re-enable ARM Emulation (if developing on x86_64 for ARM targets):

After a host reboot, ARM emulation (used for building ARM64 images on x86_64 hosts) often needs to be re-initialized within WSL. Run this in your WSL terminal:

docker run --rm -it --privileged torizon/binfmt

Reference:

Configure Build Environment for Torizon Containers | Toradex Developer Center

---

2. Verify and (Re-)Create the Local Docker Registry Container

Check if your Docker registry is running and properly mapped to the expected port (commonly 5000 or 5002 as in your setup).

To ensure the registry is running, execute:

docker ps | grep registry

If nothing appears or it’s not listening on the correct port, re-create it:

docker stop registry || true
docker rm registry || true
docker run -d -p 5002:5000 --restart=always --name registry registry:2

Reference:

Store and Share Container Images | Toradex Developer Center

---

3. Ensure WSL 2 Port Forwarding

If you’re running WSL 2, sometimes port forwarding from WSL to Windows gets disrupted after a reboot. The Torizon IDE usually runs a PowerShell script to help bind registry ports from WSL to Windows.

You can manually check and forward if needed. For example, in PowerShell (as Administrator):

netsh interface portproxy add v4tov4 listenport=5002 listenaddress=0.0.0.0 connectport=5002 connectaddress=<WSL_IP>

First, get your WSL IP (wsl hostname -I).
This ensures port 5002 is reachable from your device.

Reference:

Create a Single-Container Project | Toradex Developer Center

---

4. Check Docker Daemon Configuration

Make sure your /etc/docker/daemon.json inside WSL matches the required configuration. Sometimes, insecure-registries need to be declared for the board to fetch images from the local registry. Example:

{
  "insecure-registries": ["<host-ip>:5002"]
}

Reference:

Store and Share Container Images | Toradex Developer Center

---

5. Restart and Re-Initialize the Environment

• Stop any running registry containers (docker stop registry)
• Remove them if needed (docker rm registry)
• Re-run the Torizon IDE “initialize” tasks
• Validate the Docker registry is up and accessible at http://localhost:5002/v2/_catalog from both your WSL and the target device

---

Summary of Action Steps:

• Re-enable ARM emulation
• Confirm and (re-)create your registry container
• Double-check ports if using WSL 2
• Verify Docker daemon config for insecure registry
• Restart and re-initialize the VS Code/Torizon IDE extension

Let me know if you need further information on any step, or if any error persists!

Best regards,
Toradex AI Assistant.

---

References:

• Configure Build Environment for Torizon Containers | Toradex Developer Center
• Store and Share Container Images | Toradex Developer Center
• Create a Single-Container Project | Toradex Developer Center

[matheus.tx]

Hey @nimble-william

we are seeing on the most recent versions of Docker that it becomes a bit strict about anonimous push/pull operations, it should work better logged in:

docker login

Then reload the VS Code Window, and this should work.
Let me know.

BR,

[matheus.tx]

@nimble-william

I forget to mention to try this also before reload the window:

docker container rm -vf registry

This will clean some bad cache.

BR,

[nimble-william]

Thanks @matheus.tx

Running docker login and restarting VSCode did not work

But - after running it, I noticed a new “fetch failed” warning under the Docker Hub registry of the Docker extension sidebar. I wonder if authenticating through the command line is invalidating my authentication in the extension and vice versa. Perhaps switching to a Personal Access Token could help?

I’m also trying @ToradexAI 's advice, but no luck yet.

William

[ToradexAI]

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?

---

Hello William,

You’re correct—recent Docker changes (including stricter authentication and token requirements) can cause issues, especially when using both the Docker extension and CLI. Auth tokens and credentials may conflict, and with Docker Hub’s recent restrictions, using a Personal Access Token (PAT) for login is a more reliable and secure method than simple CLI logins.

Here’s what you can try:

1. Remove the Existing Registry Container
   This cleans up any potentially “stuck” or misconfigured container instance:

   docker container rm -vf registry
   

2. Log In Using a Personal Access Token (PAT)

   • Go to your Docker Hub account settings and generate a Personal Access Token:
     https://hub.docker.com/settings/security
   • Log in from the terminal using your Docker Hub username and the new token:

     docker login
     

     (Use your username and the PAT as the password.)

3. Restart the Registry Container

   docker run -d -p 5002:5000 --restart=always --name registry registry:2
   

4. Verify Registry Is Running

   docker ps | grep registry
   

5. Reload the VS Code Window
   This ensures the Torizon IDE extension reinitializes and picks up any credential changes.

References:

• Configure the GitLab Repository - Using PAT
• Using Private Registries with the Torizon Platform
• IDE Extension Fresh Install Troubleshooting

If issues persist:

• Ensure you’re not logged in with conflicting users between CLI and extension.
• For a fresh start, consider logging out from both Docker CLI and Docker Desktop/Extension, then logging in again with the PAT.

Let me know if this resolves the issue or if you see any new errors.

Best regards,
Toradex AI Assistant.

[matheus.tx]

Try to login in a terminal out of the VS Code please, because the terminal of the VS Code could be using the context of the device if you have a device connected.

And If removing with:

docker container rm -vf registry

does not work. Please provide the logs from:

docker container logs registry

BR,

[nimble-william]

Thank you @matheus.tx for the swift replies. I have tried a few different things, including restarting everything and removing the Torizon image from WSL 2 and allowing Torizon IDE to reinstall it, but the issue persists.

First, trying to run the registry container says it already exists:

docker run -d -p 5002:5000 --restart=always --name registry registry:2

docker: Error response from daemon: Conflict. The container name "/registry" is already in use by container "7d3abc5ca17db27b68957b33865cf2d231c852050e612d3d95339e47e4ad67ab". You have to remove (or rename) that container to be able to reuse that name.

Run 'docker run --help' for more information

So I remove it as you instructed:

~: docker container rm -vf registry
registry

And try to run it again:

~: docker run -d -p 5002:5000 --restart=always --name registry registry:2

a47ff4627c6307e0342069f41f9ef91bbf196537ada6c34dfc26e9e084b99a24
docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint registry (8a2f107c8d5dd478586239a46c95944fa4104334d7bdad466fe331607389f807): failed to bind host port for 0.0.0.0:5002:172.17.0.2:5000/tcp: address already in use

Run 'docker run --help' for more information

I don’t know what could be holding up the port.

Strangely, docker ps shows no output:

~: docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

And docker container logs registry also has no output. I have also tried restarting the docker service.

William

[nimble-william]

I’m sorry, it looks like there was an issue with the terminal session I had open. I’m getting proper output from docker now. Destroying and recreating the registry container worked as expected, but the original issue persists:

docker ps
CONTAINER ID   IMAGE                             COMMAND                  CREATED              STATUS              PORTS                                         NAMES
ff78f018950d   registry:2                        "/entrypoint.sh /etc…"   About a minute ago   Up About a minute   0.0.0.0:5002->5000/tcp, [::]:5002->5000/tcp   registry
8b5b42c44fdf   10.4.7.2:5002/puttraxapp:v0.0.0   "/start"                 3 days ago           Up 18 minutes       0.0.0.0:8000->8000/tcp, [::]:8000->8000/tcp   torizon-puttraxapp-1
5a141e42c05e   postgres:12                       "docker-entrypoint.s…"   7 days ago           Up 18 minutes       0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp   torizon-postgres-1

The registry logs appear to be OK

docker container logs registry
time="2025-05-07T18:52:14.800562811Z" level=warning msg="No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable." go.version=go1.20.8 instance.id=1429b299-5ad0-4425-b189-bbfc9a84144c service=registry version=2.8.3 
time="2025-05-07T18:52:14.801522539Z" level=info msg="Starting upload purge in 24m0s" go.version=go1.20.8 instance.id=1429b299-5ad0-4425-b189-bbfc9a84144c service=registry version=2.8.3 
time="2025-05-07T18:52:14.802158149Z" level=info msg="redis not configured" go.version=go1.20.8 instance.id=1429b299-5ad0-4425-b189-bbfc9a84144c service=registry version=2.8.3 
time="2025-05-07T18:52:14.80276776Z" level=info msg="using inmemory blob descriptor cache" go.version=go1.20.8 instance.id=1429b299-5ad0-4425-b189-bbfc9a84144c service=registry version=2.8.3 
time="2025-05-07T18:52:14.80338062Z" level=info msg="listening on [::]:5000" go.version=go1.20.8 instance.id=1429b299-5ad0-4425-b189-bbfc9a84144c service=registry version=2.8.3 

[matheus.tx]

ok, so, quick tip here. If you open a new terminal from inside the VS Code, and you are under a Torizon project workspace it automatically set the DOCKER_HOST to the context address, of the device connected:

It means that any Docker command will be executed on the Docker from the remote device.

If you want to use the docker from the WSL side set it back to nothing:

export DOCKER_HOST=

Now, back to your issue. You continue to get the ❌ Docker container registry is not running! ?

[nimble-william]

Aha, I see. That explains why the output of docker ps was empty - I was running that on my host (Torizon under WSL2). When I connected the device with “Set Default” and restarted my terminal, then docker ps is showing me the containers running on the device.

OK, yes, I’m still getting the message ❌ Docker container registry is not running!

The root of it seems to be that I can’t start the registry container in Torizon on WSL. So we’re back to what I shared a couple messages ago:

First, trying to run the registry container (on host, not device) says it already exists:

docker run -d -p 5002:5000 --restart=always --name registry registry:2

docker: Error response from daemon: Conflict. The container name "/registry" is already in use by container "7d3abc5ca17db27b68957b33865cf2d231c852050e612d3d95339e47e4ad67ab". You have to remove (or rename) that container to be able to reuse that name.

Run 'docker run --help' for more information

So I remove it as you instructed:

~: docker container rm -vf registry
registry

And try to run it again:

~: docker run -d -p 5002:5000 --restart=always --name registry registry:2

a47ff4627c6307e0342069f41f9ef91bbf196537ada6c34dfc26e9e084b99a24
docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint registry (8a2f107c8d5dd478586239a46c95944fa4104334d7bdad466fe331607389f807): failed to bind host port for 0.0.0.0:5002:172.17.0.2:5000/tcp: address already in use

Run 'docker run --help' for more information

This indicates the port is already in use. No containers are running:

~: docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

[nimble-william]

Ok, I have found a workaround and maybe the root cause…

On the Windows side I see an svchost process holding port 5002.

PS C:\WINDOWS\system32> netstat -aon | findstr :5002
  TCP    0.0.0.0:5002           0.0.0.0:0              LISTENING       16764

PS C:\WINDOWS\system32> Get-Process -Id 16764

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    377      24     5548      16544      57.95  16764   0 svchost

I could try to kill this process, but for now I tried changing the registry port to 5050 like so:

docker run -d -p 5050:5000 --restart=always --name registry registry:2

And then I did a find-and-replace in VSCode to change 5002 to 5050 throughout the Torizon tasks. I restarted VSCode and triggered the release task. I am now past the Docker registry error and my containers are deploying to the device.

I don’t know what service is using 5002 on the Windows side. Could be that this wasn’t cleaned up on restart (my power went out yesterday). I’ll try killing that process and reverting to port 5002 and will report back on how that goes.

I think my issue is resolved for now.

[matheus.tx]

On my env:

It seems to be ok to have the svchost blocking the 5002, if this is shared with the wslrelay.
Did you have only the Torizon WSL installed, not other distro?

[nimble-william]

Yes, I do have another distro (Ubuntu) on WSL, but I made sure to terminate it while working with Torizon. Still, when I start that distro, I see that port 5002 is bound, but no process is specified:

sudo netstat -tulpn | grep :5002
tcp        0      0 0.0.0.0:5002            0.0.0.0:*               LISTEN      -
tcp6       0      0 :::5002                 :::*                    LISTEN      -

I confirmed that killing the process holding port 5002 on the Windows side fixed the issue and I was able to revert back to port 5002 for the registry container.

Stop-Process -Id 16764 -Force

This command is not currently working for me, and I don’t see the wslrelay process:

PS C:\WINDOWS\system32> Get-Process -Id (Get-NetTCPConnection -LocalPort 5002).OwningProcess
Get-NetTCPConnection : No MSFT_NetTCPConnection objects found with property 'LocalPort' equal to '5002'.  Verify the
value of the property and retry.

I’m still not certain how it got in this state, but it seems like it was a zombie port binding in WSL was blocking the registry container from starting. Now that it’s cleared, the registry container can start and the Torizon IDE check passes.

[jeremias.tx]

Hi @nimble-william,

Just to confirm, your issue here is resolved now correct?

[nimble-william]

Yes - resolved. Thank you!

[jeremias.tx]

Great, thank you for confirming and glad we could help.

Best Regards,
Jeremias