Hello,
I have a Qt application built with Torizon OS. I bundled it via the torizoncore-builder bundle
, and then torizoncore-builder build
commands. I flashed it using Tezi, however it does not autostart. After navigating to /var/sota/storage/docker-compose/
, I can run docker-compose up
, and the application will run as expected. I went to investigate, and the docker-compose.service is available in the /lib/systemd/system/
. Anything off the top of the head that may indicate why it won’t autostart?
docker-compose.yml and .service are attached for reference.
docker-compose.service (610 Bytes)
docker-compose.yml (1.0 KB)
Thanks much,
Tim
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hi, Tim
It sounds like you’ve done most of the steps correctly. Here are a few things to check:
-
Enable the docker-compose
service: Ensure that the docker-compose
service is enabled to start at boot. You can do this by running:
sudo systemctl enable docker-compose
-
Check the docker-compose
service status: Verify if the docker-compose
service is running correctly:
sudo systemctl status docker-compose
If it’s not running, you can start it manually and check for any errors:
sudo systemctl start docker-compose
-
Permissions: Ensure that the docker-compose.yml
file and the directory /var/sota/storage/docker-compose/
have the correct permissions. The Docker service needs to have read access to these files.
-
Logs: Check the logs for the docker-compose
service to see if there are any errors or warnings that might indicate why the containers are not starting automatically:
journalctl -u docker-compose
-
Docker Compose File: Ensure that your docker-compose.yml
file is correctly formatted and valid. Sometimes, even a small syntax error can prevent the containers from starting.
-
Dependencies: Make sure that all dependencies and images specified in your docker-compose.yml
are available and correctly referenced.
If all the above checks are fine and the issue persists, it might be helpful to review the contents of your docker-compose.yml
and docker-compose.service
files for any potential misconfigurations.
Best regards,
Toradex AI Assistant
Judging by the logs provided from journalctl -u docker-compose
, the containers are being created and started in the proper sequence, but strangely the user interface is not presenting.
Hello Tim,
Can you run this command and check the status
of the containers?
docker ps -a
Also, you can check the container logs with:
docker container logs tcpclient
@allan.tx,
Here’s the result of docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
96b5fb553306 tharperept/tcpclient "./tcpclient" 53 seconds ago Exited (133) 51 seconds ago torizon-tcpclient-1
f661c20fe943 torizon/weston-vivante "/usr/bin/entry.sh" 54 seconds ago Up 52 seconds torizon-weston-1
and of docker container logs tcpclient
:
Error: No such container: tcpclient
Thanks for your help!
Hello Tim,
Sorry, the second command is actually:
docker container logs torizon-tcpclient-1
torizon-tcpclient-1 is the name of the container with your application.
I can see that the container status is Exited
.
I tried running the container manually and it seems the script stopped because of a segfault.
./tcpclient
qrc:/tcpclient/QML/main.qml:57:9: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Hello Torizon!
Segmentation fault
@allan.tx,
Edit 2:
Don’t think this is Torizon OS related. I believe it is a hardware issue. Will report back.
Editted:
The error below also occurs on the original TCP Client application, however the UI would present itself as expected. Similarly, the torizon-weston-1 container is created, and remains in the “up” state.
Thanks for this. If I can switch gears slightly, I have a similar (but definitely different) question. I have no problem creating a fresh thread if needed. I have a custom Qt application that for all intents and purposes should be performing the same as the TCP Client application and container. I am building this exact same way I built the tcpclient image (same device tree, etc.)
However, when I run it, I’m hitting this error immediately upon start up (that’s good! it’s indicating to me that it’s attempting to autostart as it’s supposed to), and exits.
docker container logs torizon-tradeshow-1
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: minimalegl, wayland, xcb, wayland-egl, linuxfb, minimal, eglfs, offscreen, vkkhrdisplay, vnc.
This system is not connected to an external network. It’s bizarre to me, as the docker-compose.yml files for the tcpclient & this one are effectively the same. I’ve attached the docker-compose.yml (I am aware publishing a port and then using network_mode: host does nothing).
docker-compose.yml (1.2 KB)
This repository is private, just as a heads up.
Thanks for the help.
Hello Tim,
that error message is an error with QT, are you using QT 5 or 6?
I can’t access the container image on tharperept/tradeshow,
but you can try to add this in the dockerfile.
ENV QT_QPA_PLATFORM="wayland"
or check if qt6-wayland
and qt6-wayland-dev
debian dependencies are installed.
we have a template for QML QT6 using Torizon IDE extension for VS Code, if you want to check.
Hi @allan.tx,
I appreciate the response. I’ll look into that. I’ve narrowed my issue down to (I believe anyways) a GPIO issue. I’m attempting to use libgpiod to handle my gpio pins. I’ve put the test container from your documentation onto the SoM, and I can find, and set all the respective gpio’s accordingly. I’m curious if I’ve missed a step when trying to create the release container image (note: it did work when I was in debug mode running it over the network from the Torizon IDE extension).
torizon-packages.json includes libgpiod2, and -dev in their respective locations. I’m allowing access to the gpiochip in question via the following command in my docker-compose.yml.
devices: - /dev/gpiochip2:/dev/gpiochip2
I’m linking the libraries in my CMakeLists.txt.
Any additional guidance would be great.
Solved the problem - it’s somewhere in my TcpReceiver class. Thanks, solved.
Hi Tim,
Are you using this GPIO sample as a base?
I added a briefly explanation about this in the README.md
section.
I’m all set on this at this point, I’ve clearly made an error somewhere on my end.
Cheers.
@allan.tx ,
I’m actually going to re-open this about the original issue. I added this environment variable to the dockerfile and pre-provisioned containers, etc. to no avail. I actually built this application off the QML QT6 template provided by the Torizon IDE extension.
And if it’s important, when i run docker-compose up
it does bring the UI up as expected.
Thanks,
Tim
Hi Tim,
I just tried running your app here and it’s working now. I can see the screen with the forms.
is the torizon-tcpclient-1
status still exit?
can you provide the logs?
docker container logs torizon-tcpclient-1
docker-compose.yml (974 Bytes)
Interesting.
On both applications (torizon-tcpclient-1 and torizon-tradeshow-1), on start up I get the same error
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: minimal, linuxfb, eglfs, minimalegl, xcb, wayland, vkkhrdisplay, offscreen, wayland-egl, vnc.
I can manually run docker-compose up
and the containers will start without issue. Additionally, I can run docker restart <container-id>
where container-id is the id of torizon-tcpclient-1
and it will bring the container up properly.
Thank you.
EDIT: It appears if I add restart: always
to my docker-compose.yml the issue is resolved for the most part. The above error still rings true, but the segment failure is now appended onto the logs, and the UI appears as expected. I’d say this is resolved within reason, as I now have a workaround.
Ok, sorry I understood the problem now.
The error occurs only when starting the compose on boot, but running docker compose up
, it works just fine.
I was able to reproduce this behavior on my setup. That’s really weird. I think the problem is the app is starting too soon and some dependencies are not fully initialized yet.
I think using restart: always
is good, so the app won’t be dead after a crash. But you can also add a short sleep before running the main app so the error don’t get logged.
I added this line to the tcpclient service and the app started just fine.
entrypoint: /bin/sh -c "sleep 0.5 && ./tcpclient"