Docker containers auto-start after stopping

Technical Support
, , ,
1

Hello,

I built a custom Torizon image with a bundle referenced in the tcbuild.yaml (created with a docker-compose.yml and bundle command) and deployed it to my board (I unpacked the newly built custom image before deploying and verified the OSTree commit hash is the same as the latest).

For some reason my board continues to open docker containers from my last image instead of the new bundle I built into the new image. I wanted to try stopping the old containers and pull/run the new containers manually to test them but after stopping the old containers they just start up again.

Why is this happening, the containers reopening a few seconds after closing if anything?

2

I’ve tried unpacking and deploying multiple images including the torizon-core-docker-verdin-imx8mp-Tezi_5.7.2+build.20.tar image from the Toradex Website and although the OSTree commit hash matches the latest unpacked image the board keeps opening containers from the initial image I flashed over during the first Toradex easy installer setup.

One of the containers is just running a pysimplegui app so to me it’s confusing why it opens after deploying a torizon base image.

Here’s the terminal log where it just reopens the containers I just closed within seconds:

torizon@verdin-imx8mp-15036272:~/containers$ docker stop $(docker ps -a -q) && docker rm $(docker ps -a -q)
56f54498f762
de82516feed1
221e1af746b8
a00d5ed1d7a5
001d46c14ba3
56f54498f762
de82516feed1
221e1af746b8
a00d5ed1d7a5
001d46c14ba3
torizon@verdin-imx8mp-15036272:~/containers$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
torizon@verdin-imx8mp-15036272:~/containers$ docker ps
CONTAINER ID        IMAGE                    COMMAND               CREATED             STATUS                  PORTS               NAMES
bdf6d4332bb7        torizon/weston-vivante   "/usr/bin/entry.sh"   1 second ago        Up Less than a second                       torizon_weston_1
torizon@verdin-imx8mp-15036272:~/containers$ docker ps
CONTAINER ID        IMAGE                               COMMAND                  CREATED             STATUS                  PORTS               NAMES
1eb588eb6298        leonardoheldattoradex/pysimplegui   "python3 pysimplegui…"   2 seconds ago       Up Less than a second                       torizon_accel_app_1
bdf6d4332bb7        torizon/weston-vivante              "/usr/bin/entry.sh"      3 seconds ago       Up 1 second                                 torizon_weston_1
3

Greetings @bengur,

How are you deploying your new container images? Are you just deploying the OSTree over network? If so that won’t work because container images are not managed by OSTree.

As stated in the article here: Pre-provisioning Docker Containers onto a Torizon OS image | Toradex Developer Center

To deploy your custom image with custom containers you must use Toradex Easy Installer to flash the image whole.

Best Regards,
Jeremias

4

I see, I am deploying over ssh so I guess that’s why the new container images aren’t applying.

I tried loading the easy installer back on to the board but get the following error:

parallels@ubuntu-linux-22-04-02-desktop:~/Downloads/Verdin-iMX8MP_ToradexEasyInstaller_5.7.3+build.17$ ./recovery-linux.sh 
Downloading Toradex Easy Installer...
[sudo] password for parallels: 
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.4.127-0-g08c58c9

assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
Trace/breakpoint trap

Downloading Toradex Easy Installer failed...

Any Ideas? Could it be because I’m on a vm x86 emulation? The board is in the recovery mode and plugged into my dev computer via ucb-c to usb-c through the boards x34 port.

5

Could it be because I’m on a vm x86 emulation?

Possibly, as it was with your other post. The binaries to recover/load Easy Installer are meant for x86 machines. Looking at the error message you got this seems likely.

Best Regards,
Jeremias