Torizon OTA update using docker-compose.override.yml

I am in the process of configuring my application to be deployed with OTA and have read several articles including Using Multiple Containers with TorizonCore | Toradex Developer Center and Visual Studio Code Extension for Torizon | Toradex Developer Center.

Basically my application is to be configured as follows:

  • Image: goji-io - [based on torizon/debian] - should not be accessible outside, but communicates to goji-server over UDP. e.g networks: - backend
  • image: goji-server - based on [based on torizon/debian] - main webserver which is accessible by users from outside the box on port 80. e.g networks: -backend -frontend
  • image: goji-display - [based on torizon/weston-vivante] - Chromium browser which displays on the main screen and access goji-server but is not accessible outside the box. e.g networks: - backend
  • image: goji-flightsim - based on [based on torizon/debian] - an internal tool whihc communicates to goji-server over UDP but is not accessible outside the box. e.g networks: - backend

The Example MultiContainer Application with Grafana Collectd and InfluxDB seems like a good template for what I am doing, and I understand where to upload the docker-compose.yml to the OTA software, but where I am struggling is trying to understand how I provide the docker-compose.override.yml to the OTA software.

Thanks!

Greetings @toebes,

Just to make sure I understand. Are you asking how to handle 2 compose files at the same time with our OTA update system?

If so, this is currently not possible. Our OTA update system only updates and manages a single docker-compose.yml file at a time.

Best Regards,
Jeremias

I think you understand. To make it even simpler… How do you implement the Example MultiContainer Application with Grafana Collectd and InfluxDB using the OTA system?

I’m not sure I quite understand what you mean by “implement” this example in OTA. But, let me try and see if I can clarify things.

Our OTA update system can update the docker-compose.yml on a TorizonCore device. This in turn updates the containers when the system tries to pull the new container images based off the docker-compose.yml. If you push an update, this will replace the current docker-compose.yml with a new one based on what you chose to update.

This is what I meant by our system currently only “manages” a single docker-compose.yml at a time. So if you have two docker-compose files docker-compose.yml and docker-compose.override.yml you can only really have one of these on the system at a time.

The example you’re referencing does not take our OTA system into account at all. I hope this helps clear things up.

Best Regards,
Jeremias

I didn’t pick this example by accident, I took the example because the OTA code recommends it when you are uploading a Docker Compose Package as you can see in the screen snapshot.

Given that, it might make sense either to remove the link on the OTA page or update the example to work with OTA.

Oh well that example was referenced on how to use multiple containers via docker-compose. Not so much on how to use multiple docker-compose files concurrently, which as I said is not possible currently.

But I can see how one might make that assumption. I’ll provide this feedback to the team.

Best Regards,
Jeremias

After merging the docker-compose.override.yml file into my docker-comose.yml file, I was unable to get the kiosk container to launch. After tracking down the logs I found that it was failing with a message .

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
[1:1:0316/221015.355959:FATAL:zygote_host_impl_linux.cc(190)] Check failed: ReceiveFixedMessage(fds[0], kZygoteBootMessage, sizeof(kZygoteBootMessage), &boot_pid).
#0 0xaaaaebb0a800 (/usr/lib/chromium/chromium+0x4da67ff)
.... (stack trace lines deleted)
#18 0xaaaae969a8f4 (/usr/lib/chromium/chromium+0x29368f3)
[end of stack trace]
Calling _exit(1). Core file will not be generated.

after reading linux - google-chrome Failed to move to new namespace - Stack Overflow and Web Browser / Kiosk Mode with TorizonCore | Toradex Developer Center it became clear that the reason that it failed is because the example on the page is missing an important line that is in the github repository version

    security_opt:
      - seccomp=unconfined

However, that gets me a bit further with the container coming up but doesn’t display my web page, and it gives me a new set of problems that I can see in the logs for the container. Is there some additional configuration I am missing?

[1:61:0316/230015.140470:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[1:61:0316/230015.147319:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[1:61:0316/230015.148657:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[1:40:0316/230015.172368:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[1:40:0316/230015.172482:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[1:40:0316/230015.853796:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[1:40:0316/230015.854860:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
Fontconfig error: Cannot load default config file
[41:48:0316/230016.261972:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230016.315601:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230016.386334:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230016.417169:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230016.648764:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230017.178262:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230017.501325:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230022.273571:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230022.537803:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230052.309329:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230052.600708:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648

Here’s my docker-compose file

version: "2.4"
services:
  pilot:
    container_name: pilot
    networks:
      - backend
      - frontend
    volumes:
      - type: bind
        source: /mnt/gojimedia
        target: /mnt/gojimedia
    ports:
      - "80:80"
      - "8809:8809"
      - "8810:8810"
      - "8811:8811"
    image: johntoebes/goji:goji-server

  weston:
    # pass environment variables to the container
    # in this example, you accept the NXP EULA with regards to use of Vivante
    # binaries for GPU-accelerated graphics
    environment:
      - ACCEPT_FSL_EULA=1
    container_name: weston
    # For i.MX 8-based modules use this image:
    image: torizon/weston-vivante:2
    # Required to get udev events from host udevd via netlink
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /run/udev
        target: /run/udev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    # Add device access rights through cgroup rules
    device_cgroup_rules:
      # ... for tty0
      - 'c 4:0 rmw'
      # ... for tty7
      - 'c 4:7 rmw'
      # ... for /dev/input devices
      - 'c 13:* rmw'
      - 'c 199:* rmw'
      # ... for /dev/dri devices
      - 'c 226:* rmw'

  kiosk:
    container_name: kiosk
    image: torizon/kiosk-mode-browser:2
    # run a custom command, equivalent to CMD on a Dockerfile
    command: --window-mode http://0.0.0.0/map?bulkhead
    security_opt:
      - seccomp:unconfined
    networks:
      - frontend
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /var/run/dbus
        target: /var/run/dbus
      - type: bind
        source: /dev/dri
        target: /dev/dri
    # only bring-up this container if others are successfully started
    depends_on:
      - weston
      - pilot
    # size of shared memory between containers
    shm_size: '256mb'
    device_cgroup_rules:
      # ... for /dev/dri devices
      - 'c 226:* rmw'

networks:
  backend:
    internal: true
  frontend:
    internal: false

Well I can’t reproduce this exactly since I don’t have access to your johntoebes/goji:goji-server container image. However when I run your docker-compose (minus the parts related to pilot), it does work if I target other websites. That is to say there doesn’t seem to be issues with the weston and kiosk part of the compose file.

Also as a side-note the following errors/warning:

kiosk     | [1:60:0317/203015.173918:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk     | [1:60:0317/203015.177671:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk     | [1:60:0317/203015.179392:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk     | [1:40:0317/203015.194748:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk     | [1:40:0317/203015.195432:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk     | [1:40:0317/203015.875570:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk     | [1:40:0317/203015.875986:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")

Usually pop up with chromium, but they can be ignored and are not typically fatal errors. So the only abnormality I see in your logs is the lines about Cannot send request of length 32568648. Since I don’t have any knowledge about your Web UI container I can’t really assume too much more. The only thing I would suggest is to make sure the endpoints you’re trying to reach can be contacted by the kiosk container.

Best Regards,
Jeremias

I’ve decided to run in --browser-mode to see what is going on and discovered that I am getting the dreaded Chromium “The browser supports WebGL, but initialization failed” message. It appears that WebGL isn’t enabled on the iMX8. I’ve created a simple docker compose which shows this going to webglreport.com

Docker-Webgl.yml (1.8 KB)

So since it appears that Webgl isn’t supported on Chromium (Chromium is not accelerated ( webgl not activated )) on the iMX8 I switched to using Cog and it shows that webgl1 is enabled, but not webgl2. You can see it with this example docker compose
Docker-Cog.yml (1.7 KB)

I’ve managed to launch a COG version going to our application, but to to be honest, the frame rate with Cesium is really bad.

What are my options to get a WebGL enabled browser on the iMX8?

I see, I wasn’t aware your web UI was using CesiumJS. As you noticed our chromium is currently lacking hardware acceleration for webgl. On the other hand while Cog is hardware accelerated it has it’s own issues. I’ve heard reports that it has not the best performance with various JS frameworks.

For chromium the team is looking into if it is now possible to get proper hardware support. For Cog we’ve raised the performance issues with Igalia (company behind cog) already. However for either case I don’t have any definite timelines or roadmaps. Since some of this stuff is outside of Toradex control.

As for alternative browsers besides chromium/cog. We haven’t identified any browsers yet that behave well on i.MX while also providing GPU support. If you happen to hear of any such embedded browsers it would be appreciated if you let us know.

In summary, we are aware of such issues. But there is no good answer yet at this time.

Best Regards,
Jeremias

I will agree with that. After only a few hours, Cog goes from an initial state of extremely slow to a complete crawl updating only once every 10-20 seconds.

Do any of the other Apalis SOMs provide support for accelerated CesiumJS? We moved from the TK1 to the iMX8 in hope of getting better performance.

Thank you very much

Given that the Raspberry Pi is using the Arm Cortex and has implemented supported for WebGL 2.0 with Chromium (one article here) is there any possibility of benefiting from the work that was done there?

Also, has anyone talked to the Flow Browser people?

Given that the Raspberry Pi is using the Arm Cortex and has implemented supported for WebGL 2.0 with Chromium (one article here ) is there any possibility of benefiting from the work that was done there?

The issue is that i.MX based devices use a proprietary GPU from NXP. For a browser to be properly hardware accelerated there needs to be support in that browser for this specific GPU.

Now there was recent news that Chromium now supports i.MX GPUs. However, this was rather recent and still hasn’t been investigated, tested, and integrated in our Chromium.

This is what I mean by a lot of this is outside of Toradex control. Since we have little to no control over the browser side or the GPU side of the issue. We’re actively investigating possible solutions for both Cog & Chromium. But such things take time.

Also, has anyone talked to the Flow Browser people?

There hasn’t been any talk of this browser, at least that I’m aware of.

Best Regards,
Jeremias

I would be more than happy to test out anything as early as you are willing to share.

I’ll definitely share with you what I can once we have something. We just don’t currently have anything at the moment I’m afraid.