Here’s an odd one… I am working on a Xojo Desktop application that incorporates the AloeExpress module. The application is a touch-screen app that runs on a Raspberry Pi. The code is working great. But… (and there’s always a but) I noticed that my application no longer autostarts when the Raspberry Pi boots-up.
I tried a whole range of things to try and isolate the problem. I also tried running the application on another Raspberry Pi with a freshly created Raspbian image. But no luck. I’ve never had a Xojo application fail to autostart before.
After many hours of trial and error I noticed a few things:
The Raspberry Pi was taking longer than normal to boot-up and display the Raspbian desktop.
If I tried to launch my application immediately after the Raspbian desktop appeared, the mouse-pointer would indicate busy for maybe 15 seconds and then nothing… the application wouldn’t start.
If I waited for 30 seconds or so after the Raspbian desktop appeared the application would start right up.
I tried to log the start-up events to see where the application was failing and found that no logging occurred. It appears that the application was dying before it even fully loaded. I built a very simple “hello world” desktop application and set it up to autostart and found that it started just fine (I wanted to see if my upgrade to Xojo 2018r4 might be the problem).
At this point I was getting desperate and started deconstructing my application until it would autostart. What I found surprised me. After several rounds of deconstruction I found that removing all references to AloeExpress allowed the application to autostart!
So, It looks to me as though something in the initialization of AloeExpress is looking for a service of some other dependency that doesn’t exist until quite a few seconds after the Raspbian desktop is visible.
I don’t want to resort to this, but I may have to create a “splash screen” that autostarts, waits for 30 seconds or so and then launches my application. But I’d really like to know what is failing to be found or initialized during the start-up of my application. If I knew what it was I could simply wait for that resource to be ready before initializing AloeExpress.
The Raspberry Pi is a great little computer but it certainly has its fair share of idiosyncrasies.
Do you have any thoughts on this?
Dead sd card? Or the size may be too small of the sd card perhaps?
Another possibility is wait for network that may somehow be blocking the application. How is it auto-started? Using systemd?
It really does seem like my application is failing because some resource it needs isn’t yet available when it autostarts.
I’m not using systemd. To autostart my desktop application I’ve placed a “myappname.desktop” file into the “/home/pi/.config/autostart/” folder. This seems to be the standard way to autostart a GUI desktop application and it has worked in every case before this one.
Did you change versions of Xojo recently?
I did upgrade to Xojo2018r4 recently but my simple “Hello World” app autostarts without any issues, so I went looking elsewhere for the problem. Only when I removed AloeExpress from the equation did my app autostart successfully like it used to. AloeExpress works wonderfully but it seems to be looking for a resource that isn’t available until shortly after the desktop appears.
Have you tried older versions of Xojo? That would help us figure out if it’s an internal or external problem.
I’ll see what I can do. I have Xojo 2017r1 but AloeExpress doesn’t run under that version of Xojo on the Raspberry Pi because of AloeExpress’s need for the XojoScript module. The only way I could get AloeExpress to run under Xojo 2017r1 on my Raspberry Pi was to remove all references to XojoScript from AloeExpress. That’s one of the reasons I upgraded to Xojo 2018r4. I didn’t want to have to carve up AloeExpress just to use it.
Have you tried running the web app in the command line or with ldd to see if there are any unsatisfied dependencies?
You might want try running Aloe Express on a different port, or checking to see if the port you are currently using is already in use.
Also, there’s an alternative version of Aloe Express called “Aloe Micro” that you might want to try. It’s a streamlined version of Aloe Express that’s designed specifically for APIs and microservices. It removes support for things like WebSockets, XojoScript, etc. It was released last as part of Temper (a Web API for the FileMaker platform). Temper’s source code is fully accessible and distributed under an MIT License. You can download it here: https://temperapi.com
Depending on what you’re using Aloe Express for, Aloe Micro could be a drop-in replacement for it. And it’s possible that it will help you resolve the issue that you’re running into.
[quote=425880:@Greg O’Lone]Have you tried running the web app in the command line or with ldd to see if there are any unsatisfied dependencies?
During the debugging process I have been running the application from a terminal window so that system.debuglog() messages I have scattered around the code will be visible. But so far only my messages have appeared, nothing out of the ordinary.
I don’t know anything about the “ldd appname” command. But I’ll look at it.
I’m using the default AloeExpress port (8080) but I’ll try a different port just to make sure I’ve ticked that box. And I’ll also look at Aloe Micro.