Cog container unstable on Torizon OS 7

vix · December 16, 2024, 9:58am

I’ve just installed Torizon OS 7 (7.1.0-devel-202412+build.4) on Verdin iMX8M-Plus, with the following containers:

torizon/weston-imx8:4.2
torizon/cog-imx8:4.2

I read in the known issues on github that

Chromium is not stable at the moment

but I see that for cog it’s the same.
If I execute some reboots, sometimes it starts and is able to render on the screen, and in the docker log I see

docker logs --tail 1000 -f ca372ab7c0068f00389c634d971dfa270993fd63f26f7521dcd77be58f6a86c1 

Could not determine the accessibility bus address

(cog:1): GLib-GIO-WARNING **: 09:47:11.556: Your application does not implement g_application_activate() and has no handlers connected to the 'activate' signal.  It should do one of these.
Cog-Core-Message: 09:47:11.904: <https://webglsamples.org/> Load started.
Cog-Core-Message: 09:47:12.804: <https://webglsamples.org/> Loading...
WARNING: trying to load platform resource 'missingImage'
Cog-Core-Message: 09:47:15.269: <https://webglsamples.org/> Loaded successfully.

Sometimes I see that the container is started, but nothing is rendered over the weston dark blue background.
Here is the log when this happens:

docker logs --tail 1000 -f 8e7149eec063213125a47c5befb7b179ef83c32c31785ab065bf33605252652c 


(cog:1): Cog-DRM-WARNING **: 09:50:07.880: Renderer 'modeset' does not support rotation 0 (0 degrees).
Could not determine the accessibility bus address

(cog:1): GLib-GIO-WARNING **: 09:50:07.990: Your application does not implement g_application_activate() and has no handlers connected to the 'activate' signal.  It should do one of these.

(cog:1): Cog-DRM-WARNING **: 09:50:08.668: failed to import a wl_buffer resource into gbm_bo
Cog-Core-Message: 09:50:08.670: <https://webglsamples.org/> Load started.
Cog-Core-Message: 09:50:09.152: <https://webglsamples.org/> Loading...
WARNING: trying to load platform resource 'missingImage'
Cog-Core-Message: 09:50:12.273: <https://webglsamples.org/> Loaded successfully.

I see two more messages when it fails:

...
(cog:1): Cog-DRM-WARNING **: 09:50:07.880: Renderer 'modeset' does not support rotation 0 (0 degrees).
...
(cog:1): Cog-DRM-WARNING **: 09:50:08.668: failed to import a wl_buffer resource into gbm_bo
...

Is this a known issue?

ToradexAI · December 16, 2024, 10:00am

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

Hello,

It seems you’re encountering some instability with the Cog container on Torizon OS 7 on your Verdin iMX8M-Plus. The warning messages, such as “Renderer ‘modeset’ does not support rotation 0 (0 degrees)” and “failed to import a wl_buffer resource into gbm_bo,” suggest there might be issues with the graphics rendering pipeline.

Here are some steps you can take to troubleshoot and potentially resolve these issues:

Check Container Configuration: Ensure that the Cog container is configured to use the GPU correctly. Verify that the necessary environment variables and Docker run options are set to enable hardware acceleration.
Weston Configuration: Since Weston is the Wayland compositor, make sure it is properly configured and running before starting the Cog container. Any issues with Weston could affect the rendering of Cog.
Update Containers: Ensure you are using the latest versions of the Cog and Weston containers. Updates often include bug fixes that might resolve your issue.
Review Known Issues: Check the Toradex GitHub or forums for any known issues related to the specific versions of the containers you are using. There might be ongoing work or patches available.
Logs and Diagnostics: Continue to monitor the logs for any additional error messages that might provide more context. You can increase the verbosity of the logs if possible to gather more detailed information.

By following these steps, you should be able to narrow down the cause of the instability. If the issue persists, consider whether there are any specific configurations or applications running that could be causing conflicts.

I hope this helps you resolve the issue.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Torizon OS 7 + weston-imx8 + chromium-imx8: WebGL not supported.

henrique.tx · December 16, 2024, 8:31pm

Hi @vix !

I was informed that for Cog we currently just install the official Debian package (the one that comes from Debian’s feed) and we are currently not running any tests to check the results.

Having said that, the straight answer to this question would be no. But anyway we currently don’t have information about the state of Cog.

Best regards,

vix · December 17, 2024, 8:11am

I know, it has been discussed here.

This sounds strange to me, because every time someone on this community describes some issue with chromium, the answer is something like “try using cog that is much more stable, with better performance and hardware accelerated”

Based on the issues described on the other topic (see my link above) I would suggest Toradex to build the release 0.18.4 + the latest table wpewebkit (2.46.1) in the torizon/cog-imx8 container.

henrique.tx · December 17, 2024, 3:27pm

Hi @vix !

Since both Cog and Chromium are available and both have a very different use case, we usually recommend to try one if the other is not fulfilling the requirements. Having said that, since they are third party software (and quite complex software), we do not control their quality/stability. Having tests for them involve quite some R&D work and for now we don’t have it for Cog.

Cog is more lightweight than Chromium and it is designed for some use cases (WPE's Frequently Asked Questions). If your use case is aligned with Cog’s, then it might be indeed better than Chromium.

Also, Cog has a list of supported hardware (Supported Hardware) and AM62 is not one of them (at least not currently), therefore there is no guarantee.

By the way, which kind of reboots are these? Container reboots or OS’s? If it is container’s are you restarting the whole docker-compose.yml (Weston & Cog) or only Cog?

Best regards,

vix · December 17, 2024, 3:48pm

I mean sudo reboot.
If I docker stop and restarts all the containers, the situation seems stable (i.e., it’s rendered on the screen).

henrique.tx · December 17, 2024, 3:56pm

That’s interesting. This might mean that something is not “ready” for Cog to start healthy. Something related to this: Wait! My Container is Crashing Before Startup

Could you please share the docker-compose.yml you are using?

Best regards,

vix · December 17, 2024, 3:58pm

Here is the file (quite simple)
docker-compose-torizon7-cog.yaml (1.4 KB)

henrique.tx · December 17, 2024, 4:37pm

Hi, @vix!

Have you followed the Torizon blog post I shared previously?

I see your depends_on from kiosk to weston is defined as service started. Have you tried using healthcheck and service_healthy instead?

Besides the blog post shared previously, we have some examples in our Torizon Samples repository and in the Toradex Developer. E.g.:

Also I see you are allowing your Cog container to use the whole RAM of the module (shm_size: 4GB). This doesn’t seem to be a good idea. But TBH I am not sure what are the effects of this.

Best regards,

vix · December 18, 2024, 12:18pm

I had read it, getting some useful info.
But I hadn’t modified my docker-compose yet.

Now I didi it with the following changes (based on your suggestion):

kiosk:
  ...
  depends_on:
    weston:
      condition: service_healthy
  ...
  shm_size: 256mb

weston:
  healthcheck:
    test: ["CMD-SHELL", "test", "$$WAYLAND_DISPLAY"]
    start_period: 5s

taken from the blog post.

Nothing changes. I can see cog over weston surface only if I stop the containers and restart them with docker compose up.
It doesn’t work after a cold boot.
I can add that from the logs of weston container (not cog) I see the following difference:

cold boot - not working

Switching VT tty1 to text mode if currently in graphics mode
Switching VT mode of /dev/tty1 to text
Switching to VT 7
SoC is: 'i.MX8MP'
SoC has GPU: true
SoC has DPU: false
 g2d implementation: viv
...

docker compose up - working

Switching VT tty1 to text mode if currently in graphics mode
Switching to VT 7
SoC is: 'i.MX8MP'
SoC has GPU: true
SoC has DPU: false
 g2d implementation: viv
...

Note that the line
Switching VT mode of /dev/tty1 to text
is missing.

Is this something helpful?

henrique.tx · December 18, 2024, 12:49pm

Hi @vix !

Thanks for the further tests.

Seems like Weston itself is having some hard time.

Let me ask: are you able to reproduce this issue on a vanilla Torizon OS 7.1.0? (I will try on my side as well)

Also which display are you using? And connected thought which interface?

What I am thinking: for some reason, Weston itself might be failing to start (not related to Cog). Is it possible? Could you try to simply remove Cog from your docker-compose and check if Weston itself is able to start healthy?

Best regards,

vix · December 18, 2024, 1:15pm

Yes, it’s the Vanilla scarthgap/verdin-imx8mp/torizon/torizon-docker/monthly 7.1.0-devel-202412+build.4 running on Yavia board.
The display is an external monitor connected through HDMI (1920 x 1080 @ 60 Hz).

It seems to me that weston is able to run, because I see the dark blue weston surface on the monitor.
This is the full log from weston container on a cold boot:

Switching VT tty1 to text mode if currently in graphics mode
Switching VT mode of /dev/tty1 to text
Switching to VT 7
SoC is: 'i.MX8MP'
SoC has GPU: true
SoC has DPU: false
g2d implementation: viv
Removing previously created '.X*-lock' entries under /tmp before starting Weston. Pass 'IGNORE_X_LOCKS=1' environment variable to Weston container to disable this behavior.
dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format...
dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format...
00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound seat seat0
00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
Date: 2024-12-18 UTC
[12:06:19.930] weston 12.0.4
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 12.0.4
[12:06:19.932] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0 --use-g2d
[12:06:19.932] OS: Linux, 6.6.54-7.1.0-devel-g8de35b780872, #1-Torizon SMP PREEMPT Mon Nov 25 16:38:54 UTC 2024, aarch64
[12:06:19.932] Flight recorder: enabled
[12:06:19.933] Using config file '/etc/xdg/weston/weston.ini'
[12:06:19.934] Output repaint window is 7 ms maximum.
[12:06:19.935] Loading module '/usr/lib/aarch64-linux-gnu/libweston-12/drm-backend.so'
[12:06:19.974] initializing drm backend
[12:06:19.974] Trying libseat launcher...
00:00:00.113 [INFO] [seatd/server.c:145] New client connected (pid: 32, uid: 1000, gid: 1000)
00:00:00.113 [INFO] [seatd/seat.c:170] Added client 7 to seat0
[12:06:19.975] [libseat/libseat.c:73] Seat opened with backend 'seatd'
[12:06:19.975] [libseat/backend/seatd.c:212] Enabling seat
[12:06:19.975] libseat: session control granted
00:00:00.116 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
[12:06:19.979] using /dev/dri/card0
[12:06:19.979] DRM: supports atomic modesetting
[12:06:19.979] DRM: does not support GBM modifiers
[12:06:19.979] DRM: does not support async page flipping
[12:06:19.979] DRM: supports picture aspect ratio
[12:06:19.980] Loading module '/usr/lib/aarch64-linux-gnu/libweston-12/g2d-renderer.so'
[12:06:20.614] event1  - gpio-keys: is tagged by udev as: Keyboard
[12:06:20.615] event1  - gpio-keys: device is a keyboard
[12:06:20.618] event0  - 30370000.snvs:snvs-powerkey: is tagged by udev as: Keyboard
[12:06:20.618] event0  - 30370000.snvs:snvs-powerkey: device is a keyboard
[12:06:20.621] event2  - audio-hdmi HDMI Jack: is tagged by udev as: Switch
[12:06:20.779] event2  - not using input device '/dev/input/event2'
[12:06:20.834] libinput: configuring device "gpio-keys".
[12:06:20.834] libinput: configuring device "30370000.snvs:snvs-powerkey".
[12:06:21.095] DRM: head 'HDMI-A-1' found, connector 38 is connected, EDID make 'ROW', model 'AAA', serial 'unknown'
               Supported EOTF modes: SDR
[12:06:21.095] DRM: head 'HDMI-A-2' found, connector 40 is disconnected.
[12:06:21.096] Registered plugin API 'weston_drm_output_api_v1' of size 40
[12:06:21.096] Registered plugin API 'weston_drm_virtual_output_api_v2' of size 48
[12:06:21.096] Color manager: no-op
[12:06:21.096] Module '/usr/lib/aarch64-linux-gnu/libgbm.so' already loaded
[12:06:21.100] Output 'HDMI-A-1' attempts EOTF mode: SDR
[12:06:21.100] Output 'HDMI-A-1' using color profile: built-in default sRGB SDR profile
[12:06:21.114] Output HDMI-A-1 (crtc 33) video modes:
               1920x1080@60.0, current, 148.5 MHz
               1920x1080@60.0 16:9, 148.5 MHz
               1920x1080@59.9 16:9, 148.4 MHz
               1920x1080@50.0 16:9, 148.5 MHz
               1280x720@60.0, 74.2 MHz
               1280x720@60.0 16:9, 74.2 MHz
               1280x720@59.9 16:9, 74.2 MHz
               1280x720@50.0 16:9, 74.2 MHz
               1024x768@60.0, 65.0 MHz
               800x600@75.0, 49.5 MHz
               800x600@60.3, 40.0 MHz
               800x600@56.2, 36.0 MHz
               640x480@75.0, 31.5 MHz
               640x480@72.8, 31.5 MHz
[12:06:21.114] associating input device event1 with output HDMI-A-1 (none by udev)
[12:06:21.114] associating input device event0 with output HDMI-A-1 (none by udev)
[12:06:21.114] Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
[12:06:21.115] Compositor capabilities:
               arbitrary surface rotation: yes
               screen capture uses y-flip: yes
               cursor planes: yes
               arbitrary resolutions: no
               view mask clipping: yes
               explicit sync: yes
               color operations: no
               presentation clock: CLOCK_MONOTONIC, id 1
               presentation clock resolution: 0.000000001 s
[12:06:21.116] Loading module '/usr/lib/aarch64-linux-gnu/weston/desktop-shell.so'
[12:06:21.118] Loading module '/usr/lib/aarch64-linux-gnu/libweston-12/xwayland.so'
[12:06:21.195] Registered plugin API 'weston_xwayland_v1' of size 32
[12:06:21.195] Registered plugin API 'weston_xwayland_surface_v1' of size 16
[12:06:21.195] xserver listening on display :0
[12:06:21.197] Loading module '/usr/lib/aarch64-linux-gnu/weston/screen-share.so'
[12:06:21.199] launching '/usr/lib/aarch64-linux-gnu/weston-keyboard'
[12:06:21.206] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'

Why du you think that weston is failing to start?

henrique.tx · December 20, 2024, 12:39pm

Hi @vix !

After some testing, I couldn’t reproduce the issue you are facing.

Here is what I am using:

Hardware
- Verdin iMx8MP Q 4GB WB IT V1.1A
- Verdin Development Board V1.1A
- Toradex Capacitive 10" LVDS display V1.0A
OS
- Torizon OS 7.1.0-devel-202412+build.4
Docker containers
- I got the exact same docker-compose.yml you previously shared here (I didn’t even applied the recommendations I shared yet)
  - torizon/cog-imx8:4.2
  - torizon/weston-imx8:4.2

Output of tdx-info:

torizon@verdin-imx8mp-15247228:~$ sudo tdx-info

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.54-7.1.0-devel-g8de35b780872 #1-Torizon SMP PREEMPT Mon Nov 25 16:38:54 UTC 2024
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/90d74883388b28a534b5136e3b9f1f40f5e32266d119398e729492e8e1c904ee/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.1.0-devel-202412-build.4
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15247228
------------------------------------------------------------

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

We need to find a way for me to reproduce the issue you are facing, otherwise it will be hard to investigate.

Could you please share your setup in the same way I did above (I know you shared some of it already. Sorry for asking again, but it is neat to have everything in one place )?

Also, would you be able to test using Toradex’s Capacitive 10" LVDS display?

If you really always see weston’s blue background, then it is all right with Weston itself. It was just a wild guess from my side.

Best regards,

vix · December 20, 2024, 1:02pm

Output from my tdx-info (EDITED):

torizon@verdin-imx8mp-15007389:~$ sudo tdx-info

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.54-7.1.0-devel-g8de35b780872 #1-Torizon SMP PREEMPT Mon Nov 25 16:38:54 UTC 2024
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/90d74883388b28a534b5136e3b9f1f40f5e32266d119398e729492e8e1c904ee/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.1.0-devel-202412-build.4
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15007389
------------------------------------------------------------

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

My setup:

Hardware
- Verdin iMx8MP Q 4GB WB IT V1.1A
- Yavia Board V1.0A
- External monitor HDMI 1920 x 1080 @60 Hz
OS
- Torizon OS 7.1.0-devel-202412+build.4
Docker containers
- the docker-compose.yml I posted above with
  - torizon/cog-imx8:4.2
  - torizon/weston-imx8:4.2

I wouldn’t, unfortunately.

henrique.tx · December 20, 2024, 1:17pm

Hi, @vix!

Thank you for the details.

From what you shared, I can only see the display used as a difference…

Are you using the native HDMI from Verdin iMX8MP or the DSI-HDMI?

If you use one or the other, do you get a different outcome? E.g. DSI-HDMI being more successful than HDMI (or the other way)

Best regards,

vix · December 20, 2024, 2:02pm

I’ve been using the DSI-HDMI.
If I use the native one, I cannot see the weston dark blue background.
But, is the native HDMI supported in the Vanilla Toradex OS 7 for the iMX8M-Plus?

The strange thing is that on both the interfaces I can see the Torizon splashscreen during the boot. But then, only DSI-HDMI can show something. On the native, black screen and the monitor goes to “power saving” (usually this happens when no signal is detected on the cable).

I can add two more (interesting?) things:

using a Verdin Dev Board, instead of Yavia works in the same way (i.e., native HDMI shows nothing, DSI-HDMI shows only the weston blue background)
if I boot the SoM without any HDMI cable connected, and then I plug HDMI cable after the boot, DSI-HDMI works perfectly and I see cog over weston. The native HDMI doesn’t work in any case.

So the issue comes only if the boot starts with a HDMI monitor connected to DSI-HDMI (on Yavia or Dev Board+mezzanine).

henrique.tx · December 20, 2024, 3:39pm

Hi @vix !

Thank you for the further details. They are helpful since we are not sure why Cog is failing

On my side, I got an HDMI display connected through DSI-HDMI and I could reproduce the issue you are facing: it shows Weston but not Cog.

This is the log when Cog fails:

torizon@verdin-imx8mp-15247228:~$ docker logs torizon-kiosk-1

(cog:1): Cog-DRM-WARNING **: 14:39:44.889: Renderer 'modeset' does not support rotation 0 (0 degrees).
Could not determine the accessibility bus address

(cog:1): GLib-GIO-WARNING **: 14:39:45.001: Your application does not implement g_application_activate() and has no handlers connected to the 'activate' signal.  It should do one of these.
Cog-Core-Message: 14:39:45.487: <https://webglsamples.org/> Load started.
Cog-Core-Message: 14:39:45.638: <https://webglsamples.org/> Loading...
WARNING: trying to load platform resource 'missingImage'

(cog:1): Cog-DRM-WARNING **: 14:39:46.542: failed to import a wl_buffer resource into gbm_bo
Cog-Core-Message: 14:39:46.740: <https://webglsamples.org/> Loaded successfully.

Even hotplugging the HDMI on the DSI-HDMI also shows the same behavior: Cog is displayed.

Btw: I was informed that indeed there is currently some issue with Verdin iMX8M Plus’s native HDMI.

Now I added the same healthcheck you added. And here are some interesting information.

Below, we can see that the environment variable WAYLAND_DISPLAY is correctly set and using test on it indeed doesn’t return an error code.

torizon@verdin-imx8mp-15247228:~$ docker exec -it torizon-weston-1 bash
root@verdin-imx8mp-15247228:/home/torizon# echo $WAYLAND_DISPLAY
wayland-0
root@verdin-imx8mp-15247228:/home/torizon# test $WAYLAND_DISPLAY; echo $?
0
root@verdin-imx8mp-15247228:/home/torizon# exit
exit

But from Docker’s point of view, we can see that the status of torizon-weston-1 is Unhealthy.

torizon@verdin-imx8mp-15247228:~$ docker inspect --format "{{json .State.Health }}" torizon-weston-1 | jq
{
  "Status": "unhealthy",
  "FailingStreak": 3,
  "Log": [
    {
      "Start": "2024-12-20T14:49:26.658187287Z",
      "End": "2024-12-20T14:49:26.826725287Z",
      "ExitCode": 1,
      "Output": ""
    },
    {
      "Start": "2024-12-20T14:49:56.828144436Z",
      "End": "2024-12-20T14:49:57.006038327Z",
      "ExitCode": 1,
      "Output": ""
    },
    {
      "Start": "2024-12-20T14:50:27.008028258Z",
      "End": "2024-12-20T14:50:27.175776366Z",
      "ExitCode": 1,
      "Output": ""
    }
  ]
}

Because of that, as expected, Cog is not starting: torizon-kioski-1 is Created instead of Up.

torizon@verdin-imx8mp-15247228:~$ docker ps -a
CONTAINER ID   IMAGE                     COMMAND                  CREATED          STATUS                      PORTS     NAMES
8cbf31c51fff   torizon/cog-imx8:4.2      "/usr/bin/start-brow…"   18 minutes ago   Created                               torizon-kiosk-1
b78e1d246cbd   torizon/weston-imx8:4.2   "/usr/bin/entry.sh"      18 minutes ago   Up 18 minutes (unhealthy)             torizon-weston-1

Without the healthcheck, Cog is started, it is Up, but it won’t start (as we already know):

torizon@verdin-imx8mp-15247228:~$ docker ps -a
CONTAINER ID   IMAGE                     COMMAND                  CREATED          STATUS                             PORTS     NAMES
006404217b13   torizon/cog-imx8:4.2      "/usr/bin/start-brow…"   29 seconds ago   Up 27 seconds                                torizon-kiosk-1
c3fed61b0429   torizon/weston-imx8:4.2   "/usr/bin/entry.sh"      29 seconds ago   Up 28 seconds (health: starting)             torizon-weston-1

So seems like we need to understand why Docker Compose is deeming Weston unhealthy.

Best regards,

vix · December 23, 2024, 6:52am

Great!
Reproducing the issue is the first step towards a fix

I see that you found something unexpected.
I hope that the team can find what happens.
This topic is for Torizon OS 7, but I can say that even on Torizon OS 6 cog is somehow unstable (in different way). Not sure if the root reason can be the same

henrique.tx · January 2, 2025, 1:50pm

Hi @vix !

A quick comeback here regarding the native HDMI issue you stumbled upon:

While this problem is being worked on, a workaround was found. Please check it on my message here:

Best regards,

bruno.tx · January 6, 2025, 3:13pm

Hello @vix,

Following up on this topic, I did some additional tests and found that the following heath check works reliably with Weston + Cog:

healthcheck:
      test: ["CMD", "sh", "-c", "test -n \"$$WAYLAND_DISPLAY\" || exit 1"]
      start_period: 5s

To get a faster startup, reducing the start_period value would be a possibility.

Best Regards,
Bruno