No containers open on startup

Hello,

I have been building images for a verdin imx8mp and recently started having no containers open on startup.

I think the issue is likely with my build more than my applications, but for context my accel_server runs a python script unrelated to the display while accel_app starts up a python tkinter gui. This is the docker file for the gui app:

ARG BASE_NAME=wayland-base-vivante
ARG IMAGE_ARCH=linux/arm64/v8
ARG IMAGE_TAG=3
ARG DOCKER_REGISTRY=torizon
ARG DEBIAN_FRONTEND=noninteractive

FROM --platform=$IMAGE_ARCH $DOCKER_REGISTRY/$BASE_NAME:$IMAGE_TAG

WORKDIR /home/torizon

#### Install GPU Drivers ####
RUN apt-get -y update && apt-get install -y --no-install-recommends \
    imx-gpu-viv-wayland-dev \
    && apt-get clean && apt-get autoremove && rm -rf /var/lib/apt/lists/*

#### Install Python and other utilities ####
RUN apt-get -y update && apt-get install -y --no-install-recommends \
    python3 python3-venv wget python3-pip python3-tk python3-matplotlib emacs \
    && apt-get clean && apt-get autoremove && rm -rf /var/lib/apt/lists/*

RUN pip3 install --break-system-packages --no-cache-dir numpy

RUN pip3 install --break-system-packages --no-cache-dir pillow

RUN pip3 install --break-system-packages --no-cache-dir p4p

ENV NO_AT_BRIDGE 1

COPY gui.py .
COPY utility.py .
COPY /static/open.png static/
COPY /static/close.png static/
COPY /static/pvs.json static/

ENTRYPOINT ["python3"]
CMD ["gui.py"]

Accel_server doesn’t have a dockerfile because it’s pulled from a commit on docker hub.
I have been bundling my containers for building with the following docker-compose:

version: "2.4"
services:
  weston:
    image: torizon/weston-vivante:2
    # Accept the EULA required to run imx8 vivante graphic drivers
    environment:
     - ACCEPT_FSL_EULA=1
    networks:
      - apps
    # Required to get udev events from host udevd via netlink
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /run/udev
        target: /run/udev
      - type: bind
        source: /dev
        target: /dev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    # Add device access rights through cgroup...
    device_cgroup_rules:
      # ... for tty0
      - 'c 4:0 rmw'
      # ... for tty1
      - 'c 4:1 rmw'
      # ... for tty7
      - 'c 4:7 rmw'
      # ... for /dev/input devices
      - 'c 13:* rmw'
      - 'c 199:* rmw'
      # ... for /dev/dri devices
      - 'c 226:* rmw'
      - 'c 81:* rmw'

  accel_app:
    depends_on:
      - weston
    image: benshlomogur/accel_app
    user: torizon
    volumes:
      - '/tmp:/tmp'

  accel_server:
    image: benshlomogur/accel_server
    user: torizon
    command: bash -c "source /home/torizon/rogue/setup_rogue.sh && python3 /home/torizon/darpa-accel-llrf-phase-1p5/software/scripts/devGui.py --ip 10.2.2.11 --guiType None"
    networks:
      - apps
    volumes:
      - '/tmp:/tmp'

networks:
  apps:
    driver: default

Builds from this configuration worked fine mid January, now images still build and deploy but no containers are running after booting, in contrast to all three containers (accel_app, accel_server, weston-vivante) running on startup with the exact same build config last month.

Also on the board docker ps -a returns a completely empty list so it doesn’t seem like the containers were run and exited. All of my images can be found however with docker images.

I’ve tried updating my docker-compose to use torizon/weston-vivante:3 (with wayland-base-vivante:3 still in my accel_app dockerfile) but no change.

I am using a capacitative touch display 10.1 and a previous version of torizon-core, here is the tcbuild.yaml for my build:

input:
  easy-installer:
    local: ./static/torizon-base-images/torizon-core-docker-verdin-imx8mp-Tezi_6.4.0+build.5.tar

customization:
  splash-screen: static/splashscreen/RadiaSoftLogo_1200x234.png
  device-tree:
    # >> Directories where to look for include files.
    include-dirs:
      - static/linux/include
    # >> Custom device tree source:
    custom: static/linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-dev.dts
    overlays:
      # >> Whether to ignore all overlays from the base image (or ostree archive in the future).
      clear: true
      # >> Overlays to add to output image.
      add:
        # - static/device-trees/overlays/touch-atmel-mxt_overlay.dts
        # - static/device-trees/overlays/verdin-imx8mp_sn65dsi84-lt170410_overlay.dts
        # - static/device-trees/overlays/verdin-imx8mp_sn65dsi84_overlay.dts
        - static/device-trees/overlays/verdin-imx8mp_dsi-to-lvds_panel-cap-touch-10inch-lvds_overlay.dts

output:
  # >> Parameters for deploying to an Easy Installer image.
  easy-installer:
    # >> Output directory of the customized image (REQUIRED):
    local: 6.4.0.CUSTOM
    bundle:
      dir: bundle/

Are there any known issues with the versions I’m building with? I think my current configuration broke in the last round of updates and I’m looking for suggestions before trying to get things running on the latest torizon-core version.

Thanks

Greetings @bengur,

What exactly happens then, when you manually try to docker-compose up your compose file here? Any logs? Errors? Anything?

Are there any logs from the docker-compose systemd service that is responsible for auto-running your file on boot?

I need a little more information than just the containers don’t start on boot.

I’ve tried updating my docker-compose to use torizon/weston-vivante:3 (with wayland-base-vivante:3 still in my accel_app dockerfile) but no change.

Well I see you’re on Torizon 6.X you should always be using tag 3. Tag 2 was meant to be used with Torizon 5.X.

I think my current configuration broke in the last round of updates

Could you elaborate what exactly you updated/changed?

Best Regards,
Jeremias

Turns out the docker compose was failing to create the app network before creating the containers. I had set the network driver to “default” which doesn’t exists, so not sure how my apps have been running till now.

Thanks for suggesting running the docker compose from the board, I’m still new to this and didn’t consider thats how the kernel opens containers in the first place.

Glad I was able to help!