We have this problem with the C++ application - let’s call it “WebConfig”. It uses Qt and Wt.
When I reboot the system, the web is unavailable for 2 minutes. After that, it works normally.
When I restart the app after those 2 minutes, it runs OK right away.
The app has all the libraries it needs.
I checked right after the reboot, if it’s running. Process “WebConfig” is running fine.
There are no suspicious logs from the app.
Do you have any advice on how to fix this?
Colibri iMX6DL 512 MB V1.1B
Linux version 4.14.117-dirty (gcc version 8.2.0 (GCC))
Wt app compiled with tdx-x11 2.6.4 SDK
Hi @dx7 ,
Just to be sure I understand everything correctly here.
As I understand there’s two cases:
Boot → App starts → Web unavailable → 2minutes pass → Web available
App running → Restart App → Web available immediately
Out of curiosity what happens when you restart the app during these first 2 minutes? Is it also available immediately? Or are these 2 minutes uptime a “hard” requirement for the connection to work?
Case 1 and 2 are correct.
When I restart the app during those 2 minutes, the web is still unavailable. 2 minutes pass and the web works. It’s strange because other network services (ssh, sftp) are available right after the reboot with no problems.
Thank you for your reply
There is one more thing I should’ve mentioned.
The iMX6DL module is running “TDX X11 2.6-snapshot-20220328 (thud)” distribution.
Hello @dx7 ,
Have you tried with other applications to rule out any possible issues with yours?
I would also suggest using Wireshark to capture the traffic and check if that gives a clue.
Were you able to solve your issue? Do you need more help on our side?
We tried several apps and the behavior is the same.
We also captured the traffic with Wireshark.
BUT…we were able to get some logs from the app and it seems like the problem is with the internal wthttp server of Wt. For some reason, after the reboot wthttp server takes almost 2 minutes to start. Here’s the log:
[2023-Mar-24 09:52:11.937] 514 - [info] "config: reading Wt config file: ./wt_config.xml (location = './ConfigIMX')"
[2023-Mar-24 09:52:11.941] 514 - [info] "WServer/wthttp: initializing built-in wthttpd"
[2023-Mar-24 09:53:58.429] 514 - [info] "wthttp: started server: http://0.0.0.0:80"
When I restart the app after those 2 minutes, wthttp server starts right away:
[2023-Mar-24 09:54:47.708] 544 - [info] "config: reading Wt config file: ./wt_config.xml (location = './ConfigIMX')"
[2023-Mar-24 09:54:47.709] 544 - [info] "WServer/wthttp: initializing built-in wthttpd"
[2023-Mar-24 09:54:47.718] 544 - [info] "wthttp: started server: http://0.0.0.0:80"
I already wrote on Wt forum, but no answer so far.
Hi @dx7 !
Seems like your question is really related to the application development and the frameworks you are using.
If this is the case, I would recommend you seek help in forums or mailing lists where people are experienced with the tools you are having a hard time with.
Nevertheless, I would like to ask why you are using old versions
Quickly looking around, there are newer versions for everything:
- Linux 5.4 (Toradex BSP 5 and TorizonCore 5) and 6.1 (BSP 6 and TorizonCore 6)
- Qt 5.15 (IIRC)
- Wt 4.9.1 (Wt: Wt documentation.)
I would recommend you try newer versions. There is the possibility that you are facing some old bug that was fixed already fixed.
By the way, maybe you would like to take a look at TorizonCore, which helps you to simplify the development process: Torizon - Simplifying the Development and Operation of Linux IoT Devices
So I got some news, in case anyone’s interested.
In dmesg we noticed this entry:
[ 124.382484] random: crng init done
[ 124.390444] random: 7 urandom warning(s) missed due to ratelimiting
This is what we found out about that:
These messages are the result of a bug that exhausts the entropy pool on your system.
This can cause delays in how quickly sshd (and maybe other services) become(s) available after boot.
So, we tried to compile Wt 4.9.1 and we disabled “ENABLE_SSL” option (ccmake), since we don’t use ssl.
And it works. The Wt app now starts after the reboot as it’s supposed to.
We’re not totally sure if disabling the “ENABLE_SSL” option is the thing that helped, but this is what we’ve done so far.
Hi @dx7 !
Thanks a lot for coming back to share your findings! That’s great for the Community
Could you please also mark your message as the solution? It is also important