NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Launching startup.rtxe from terminal or linux window manager

I have a question that I've been trying to track down an answer to in the KB and NI forums, but I might not be phrasing it correctly. This is my first experience with a cRIO Linux RT target with a monitor connection to serve as a local HMI.

I have a cRIO-9036 with a monitor plugged into the mini DisplayPort. I've built a startup executable, and when I reboot the cRIO I see it boot into the XFCE and run the executable with an interactive front panel. Very cool!

Let's say I close the RTEXE. How can I launch it again without rebooting the cRIO?

Here's what I've tried:

I dug around in the filesystem and found a bunch of NI startup scripts in /etc/init.d/. I've tried running each of those that I can find that are obviously written by NI (I think each filename starts with NI) to no avail. I started reading them all to understand what they do, and I eventually copied something from one of the scripts and tried this in console:

cd /usr/local/natinst/labview

exec ./lvrt liblvrt-ui.so

That launches and runs my startup.rtexe, but none of the shared variables are connected. Obviously the actual startup script must be kicking off some other processes that I'm missing with my simple attempt above.

I know someone at NI could probably just point me at the correct "top-level" script to run and I could make a shortcut to it on the desktop. I have an open ticket with NI and the AE told me that "We do not support Linux OS, so I do not know what these commands might be.". She did provide programming advice for making the RTEXE uncloseable which is technically correct but sort of misses what I'm interested in.

Thanks!

Jared

0 Kudos
Message 1 of 10
(6,255 Views)

A startup.exe will run when LabVIEW starts, so restarting LabVEW should do it.

Try running /etc/init.d/nilvrt stop then /etc/init.d/nilvrt start.

Message 2 of 10
(4,654 Views)

Sounds like a reasonable option - I'll try this in a couple days when I get my cRIO back from the panel shop and come back to confirm the solution for future people who might stumble on this.

0 Kudos
Message 3 of 10
(4,654 Views)

One important stumbling block to note:

jaredforshey wrote:

I know someone at NI could probably just point me at the correct "top-level" script to run and I could make a shortcut to it on the desktop.

The scripts noted normally cannot be run by the lvuser underpriviledged user (a security measure), and the UI is launched as that user. Since it is a script, you cannot simply use the "set the SUID bit" trick to allow the script to run as admin/root even when it is launched by lvuser (think of this loosely as the Windows User Access Control functionality).

"Can't I just run the UI as admin?" That's a bad idea, security-wise and further, NI has not tested that.

There are some options to arrive at your desired goal, but they are a bit more involved (installing and configuring sudo and having the desktop presence prepend sudo to calling the scripts, creating a wrapper binary that calls the scripts as a binary cna have teh SUID bit set, creating a service that is launched on boot that watches for some interaction from the user to relaunch LabVIEW, etc.)

Message 4 of 10
(4,654 Views)

That's a great point - I didn't realize that about the user privileges. It might be that relaunching it simply isn't worth the trouble.

Thanks!

Message was edited by: jaredforshey (typo)

0 Kudos
Message 5 of 10
(4,654 Views)

I always just "killall lvrt". The wrapper will auto relaunch it as the correct user.

0 Kudos
Message 6 of 10
(4,654 Views)

DAQjr wrote:

I always just "killall lvrt". The wrapper will auto relaunch it as the correct user.

You have to be careful. The wrapper will prevent the startup application from launching if it's killed off too many times (this is to prevent a startup app that continually crashes from preventing LV from connecting to the target) in a single boot.

Additionally, this too requires permissions to kill the lvrt application.

0 Kudos
Message 7 of 10
(4,654 Views)

jaredforshey wrote:

That's a great point - I didn't realize that about the user privileges. It might be that relaunching it simply isn't worth the trouble.

Thanks!

Message was edited by: jaredforshey (typo)

I would say, unless there's a good reason to support relaunching the app, it's probably more trouble than it's worth (since "Accidentally closing the UI" can be prevented, it's not enough of a reason).

You'd learn quite a bit about the underlying Linux system in coming to the solution, however, so maybe when deadlines aren't tight you could come back to the original solution

0 Kudos
Message 8 of 10
(4,654 Views)

BradM wrote:

DAQjr wrote:

I always just "killall lvrt". The wrapper will auto relaunch it as the correct user.

You have to be careful. The wrapper will prevent the startup application from launching if it's killed off too many times (this is to prevent a startup app that continually crashes from preventing LV from connecting to the target) in a single boot.

Additionally, this too requires permissions to kill the lvrt application.

I do it on my target as lvuser - since lvrt is running as lvuser, lvuser can kill it.

Also if you set

[STARTUP]

YouOnlyLiveTwice=FALSE

in your /etc/natinst/share/ni-rt.ini file then you can disable the behavior you described about being killed off too many times. That's what we do.

0 Kudos
Message 9 of 10
(4,654 Views)

DAQjr wrote:

BradM wrote:

Additionally, this too requires permissions to kill the lvrt application.

I do it on my target as lvuser - since lvrt is running as lvuser, lvuser can kill it.

Ah, I'd forgotten that. Thanks.

Also if you set

[STARTUP]

YouOnlyLiveTwice=FALSE

in your /etc/natinst/share/ni-rt.ini file then you can disable the behavior you described about being killed off too many times. That's what we do.

We want to discourage customers from directly editing the ini file, but in a pinch it works.

0 Kudos
Message 10 of 10
(4,654 Views)