Improving deployed executable startup/reboot/longevity reliability

[Peter_B · Accepted solution]

I'm happy to report I finally solved the problem whereby the labview.service failed to start after a cold reboot (power cycle) about 1 time in 3.

It turns out that the service was starting too early despite my prior claim (with supposed evidence) it was starting late enough.  That start list in my last post with labview.service at the 4.027s mark was obtained after a warm reboot of the RPi, not a cold reboot.    In subsequent testing I discovered it tended to start at about 1.1 seconds post boot and then 10-12 other services would start after it.  So I added directives to the labview.start file to ensure it started after a bunch of other services I reasoned it might depend upon (as they started after it).

I tested it 10 times in a row and it and my startup.rtexe app launched without fail.each time.  given it would fail 1 in 3 times the chance of 10 no fails in a row is 1.7% so I'm pretty confident.  I will double check this by reversing the change to see it fails again, but I'd be surprised if it doesn't fail. 

Other possible ways I could have debugged this was to see if it was due to some fiddling I might have done (by starting from a fresh Raspbian image) , or by re-installing the lvrte again, or by inserting the directive

ExecStartPre=/bin/sleep 7

in the labview.service file just prior to the line

ExecStartPre=/usr/sbin/schroot-lv-start.sh

and reduced the sleep time until it fell over then looked at what services started after it then enforced a dependency using the After= or Requires= directives.  Using a delay is for debugging only as other services will come and go over time and a delay is not a robust solution.

At [1] I show the changes I made to enforce the labview.service to start after presumed dependencies.  I can't rule out this was caused by some fiddling I did at some point during my learning or development.  I guess if others have the same problem then we might see a pattern and if it is an issue then NI could address it in their preferred way.

Thanks again to Rolf and Andy for taking an interest, I hope this helps someone else one day.

[1]

type:

sudo systemctl edit --full labview.service

then in the [Unit] section of that file, add the lines from # below...  to # above...

[Unit]
Description=LabVIEW 2021 chroot run-time daemon
After=network.target
# below directives added by user to eliminate startup mount error
After=raspi-config.service
After=udisks2.service
After=ModemManager.service
After=schroot.service
After=NetworkManager.service
After=avahi-daemon.service
After=systemd-modules-load.service
After=hciuart.service
#above directives added by user to eliminate startup mount error

[Peter_B · Accepted solution]

For the record I can confirm that I am able to eliminate the SEGMENTATION FAULT error (which I call the RPi's labview.service BSOD equivalant !).  The cause was simultaenously opening and or closing more than one instance of the LINX Reference (obtained with "Open Local.vi").  

As this thread conflated two separate issues, this one plus a startup timing issue of the labview.service, I have marked two posts as Accepted Solutions.