Failed to create wl_display (No such file or directory)

Technical Support
, , , , ,
1

My application container fails to load. Reviewing the docker logs reveals the following error message:

Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, xcb.
Aborted

The weird thing is, this configuration has been working on other modules, and it was working before on this module. The Weston container is running, so my container should have a Wayland display to connect to.

When I start my container manually, it runs just fine. It’s only failing at boot.

Could this be an issue with the order in which containers are loaded? My container is set to “depend_on” Weston, so Weston should load first, right? Does Weston actually need to appear first in the docker-compose file?

Here’s my full docker-compose.yml:

services:
  lari2-firmware-1:
    depends_on:
    - weston
    devices:
    - /dev/gpiochip0
    - /dev/gpiochip1
    - /dev/gpiochip2
    - /dev/gpiochip3
    - /dev/gpiochip4
    - /dev/gpiochip5
    - /dev/spidev0.0
    - /dev/spidev1.0
    - /dev/apalis-uart1
    - /dev/apalis-uart2
    - /dev/apalis-uart3
    - /dev/apalis-uart4
    - /dev/ttyUSB0
    image: fbmyers/lari2-firmware-1
    ports:
    - 6502/tcp
    volumes:
    - /tmp:/tmp:rw
    - /dev/dri:/dev/dri:rw
    - /sys:/sys:rw
    - /var/lari:/var/lari:rw
    - /sys/class/pwm/pwmchip0:/sys/class/pwm/pwmchip0:rw
    - /sys/class/pwm/pwmchip2:/sys/class/pwm/pwmchip2:rw
    - /sys/class/pwm/pwmchip3:/sys/class/pwm/pwmchip3:rw
  weston:
    environment:
    - ENABLE_VNC=1
    - ENABLE_RDP=1
    cap_add:
    - CAP_SYS_TTY_CONFIG
    device_cgroup_rules:
    - c 4:0 rmw
    - c 4:7 rmw
    - c 13:* rmw
    - c 226:* rmw
    image: torizon/weston:2
    network_mode: host
    volumes:
    - source: /tmp
      target: /tmp
      type: bind
    - source: /dev
      target: /dev
      type: bind
    - source: /run/udev
      target: /run/udev
      type: bind
version: '2.4'
2

Greetings @mosaic-engineering,

This does seem strange that your configuration isn’t working on this specific module.

My only theory is that perhaps there’s a very tight race condition that is happening when you try to run this at boot. Your usage of the depends_on parameter is correct, but there’s a bit of nuance here.

All depends_on guarantees is that the Weston container will “start” before your container. It does not guarantee that the Weston process inside the container will be initialized and ready before your container starts. Usually Weston starts up quick enough that this distinction doesn’t really matter. However, it could be possible that the Weston process isn’t ready before your container starts, which could explain the issue you’re seeing here.

You can try a quick test to determine if this is what is happening. Try adding a script to your container that waits briefly before starting your Qt application. If it is really a race condition then the short wait should allow Weston enough time to fully start up.

For a more sophisticated process you can try a combination of the healthcheck and depends_on parameters. See the Docker documentation for more information on healthcheck in docker-compose. But basically you an define a test that will be used to determine if the container is “healthy”. Then depends_on will only start your container if the Weston container has started and passes the healthcheck.

Best Regards,
Jeremias

3

Hi @jeremias.tx, I think you are right about this being a race condition. When I execute docker-compose up and watch the timing of the two containers, I sometimes see Weston take a little longer to come up. I actually did two runs back to back–the first time my application starts too soon and exits, the second time it works. See below–both containers start at roughly the same time. The difference seems to be that the first time Weston runs, it is generating new RDP certificates, whereas the second time it runs, it is using the cached RDP certificates from before, so it speeds through and is available by the time my application requests the UI. This tracks with the fact that, before I enabled RDP, this problem didn’t occur.

To fix, I’ve removed the ENABLE_RDP=1 flag in Weston since I’m not actually using RDP (using VNC only). I’m also going to add a short delay to my application at startup.

First attempt: Weston takes too long to start, application container (lari2-firmware-1_1) crashes:

root@lari200:/var/sota/storage/docker-compose# docker-compose up
Creating network "docker-compose_default" with the default driver
Creating docker-compose_weston_1 ... done
Creating docker-compose_lari2-firmware-1_1 ... done
Attaching to docker-compose_weston_1, docker-compose_lari2-firmware-1_1
weston_1            | SoC is: 'i.MX6Q'
weston_1            | SoC has GPU: true
weston_1            | SoC has DPU: false
weston_1            | g2d implementation: viv
weston_1            | tee: /var/volatile/weston.log: No such file or directory
weston_1            | Certificates for RDP not found in /var/volatile
weston_1            | Generating RSA private key, 2048 bit long modulus (2 primes)
lari2-firmware-1_1  | Starting application...
weston_1            | .....................+++++
lari2-firmware-1_1  | Failed to create wl_display (Connection refused)
lari2-firmware-1_1  | qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
lari2-firmware-1_1  | This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
lari2-firmware-1_1  |
lari2-firmware-1_1  | Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, xcb.
lari2-firmware-1_1  |
lari2-firmware-1_1  | Aborted
docker-compose_lari2-firmware-1_1 exited with code 134
weston_1            | .............................................................................................................................................................................+++++
weston_1            | e is 65537 (0x010001)
weston_1            | Signature ok
weston_1            | subject=C = CH, ST = Luzern, L = Luzern, O = Toradex, CN = www.toradex.com
weston_1            | Getting Private key
weston_1            | Certificate for RDP successfully generated
weston_1            | 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.
weston_1            | dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format...
weston_1            | dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format...
weston_1            | Couldn't open /dev/tty1
weston_1            | /usr/bin/entry.sh: line 89: [: =: unary operator expected
weston_1            | Date: 2022-04-25 UTC
weston_1            | [15:16:41.742] weston 9.0.0
weston_1            |                https://wayland.freedesktop.org
weston_1            |                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
weston_1            |                Build: 9.0.0
weston_1            | [15:16:41.742] Command line: /usr/bin/weston --current-mode
weston_1            | [15:16:41.743] OS: Linux, 5.4.154-5.5.0+git.73d0438130d3, #1-TorizonCore SMP Tue Dec 28 12:11:43 UTC 2021, armv7l
weston_1            | [15:16:41.748] Using config file '/etc/xdg/weston/weston.ini'
weston_1            | Date: 2022-04-25 UTC
weston_1            | [15:16:41.742] weston 9.0.0
weston_1            |                https://wayland.freedesktop.org
weston_1            |                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
weston_1            |                Build: 9.0.0

Second attempt: Weston starts up faster, everything works:

root@lari200:/var/sota/storage/docker-compose# docker-compose up
Starting docker-compose_weston_1 ... done
Starting docker-compose_lari2-firmware-1_1 ... done
Attaching to docker-compose_weston_1, docker-compose_lari2-firmware-1_1
weston_1            | SoC is: 'i.MX6Q'
weston_1            | SoC has GPU: true
weston_1            | SoC has DPU: false
weston_1            | g2d implementation: viv
weston_1            | Certificates for RDP found in /var/volatile. Skipping generation.
weston_1            | 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.
weston_1            | dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format...
lari2-firmware-1_1  | Starting application...
weston_1            | dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format...
weston_1            | Couldn't open /dev/tty1
weston_1            | /usr/bin/entry.sh: line 89: [: =: unary operator expected
weston_1            | Date: 2022-04-25 UTC
weston_1            | [15:18:38.878] weston 9.0.0
weston_1            |                https://wayland.freedesktop.org
weston_1            |                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
weston_1            |                Build: 9.0.0
weston_1            | [15:18:38.879] Command line: /usr/bin/weston --current-mode
weston_1            | [15:18:38.879] OS: Linux, 5.4.154-5.5.0+git.73d0438130d3, #1-TorizonCore SMP Tue Dec 28 12:11:43 UTC 2021, armv7l
weston_1            | Date: 2022-04-25 UTC
weston_1            | [15:18:38.878] weston 9.0.0
weston_1            |                https://wayland.freedesktop.org
weston_1            |                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
weston_1            |                Build: 9.0.0
weston_1            | [15:18:38.879] Command line: /usr/bin/weston --current-mode
weston_1            | [15:18:38.879] OS: Linux, 5.4.154-5.5.0+git.73d0438130d3, #1-TorizonCore SMP Tue Dec 28 12:11:43 UTC 2021, armv7l
weston_1            | [15:18:38.886] Using config file '/etc/xdg/weston/weston.ini'
weston_1            | [15:18:38.886] Using config file '/etc/xdg/weston/weston.ini'
weston_1            | [15:18:38.887] Output repaint window is 7 ms maximum.
weston_1            | [15:18:38.887] Loading module '/usr/lib/arm-linux-gnueabihf/libweston-9/drm-backend.so'
weston_1            | [15:18:38.887] Output repaint window is 7 ms maximum.
weston_1            | [15:18:38.887] Loading module '/usr/lib/arm-linux-gnueabihf/libweston-9/drm-backend.so'
weston_1            | [15:18:38.906] initializing drm backend
weston_1            | [15:18:38.906] initializing drm backend
weston_1            | [15:18:38.907] logind: not running in a systemd session
weston_1            | [15:18:38.908] logind: cannot setup systemd-logind helper (-61), using legacy fallback
weston_1            | [15:18:38.907] logind: not running in a systemd session
weston_1            | [15:18:38.908] logind: cannot setup systemd-logind helper (-61), using legacy fallback
weston_1            | [15:18:38.918] using /dev/dri/card1
weston_1            | [15:18:38.918] DRM: supports atomic modesetting
4

I see it was a race condition due to the RDP setup time. Well glad it was a fairly simple issue then. So is everything fine on your end then?

5

Yes, all set on this issue.

6

Alright thank you for confirming. Glad to hear your issue was resolved.