As I figured - rtexe is not launchable directly from xinetd - looks like I might need to utilize the /etc/init.d/lvrt-wrapper script directly, providing the appropriate args, and running as lvuser.
I'm not sure then what xinetd will be communicating with for STDIN/STDOUT...
Yyyyeah, I was kinda wondering if you already had that part in the can, because if you didn't, you are probably in for a world of hurt. (You've already kinda taken your life in your own hands here so I didn't bring it up before.)
Yes, AFAIK, if you replicate the su command line present in lvrt-daemon that is used to run lvrt-wrapper, the app should come up the way you expect.
The bad news is that because LabVIEW RT has no conceptualization of a multiprocess deployment (or complete separation of configurations between application and RTEXE), the RT protocol will only be accessible for the duration of a single xinetd-spawned instance. (!) You might be able to weasel your way out of that one with some pretty insane chrooting.
That's actually fine - I only need it to run one instance when the connection is detected.
I'm just really doubtful of the connection to the RTEXE at this point from xinetd with the way it has to launch through bash script - I am not a Linux expert as you can tell.
I might just have to resort to just using TCP Listen on that port and having the other developers change the client code to use sockets directly
Found this thread - I have it starting LabVIEW, but not showing my Embedded UI. Need to figure that out.
It seems when I was experimenting with making the bash file launch the LabVIEW rtexe that my
file got messed up as SSHD is not enabled and I can not access the enable SSH field in MAX.
I found the problem with nirtcfg by trying to run ./sshd start in /etc/init.d but the return is that /usr/local/natinst/bin/nirtcfg command not found.
Looking at the file there is only 1 line and it is "21416" - so that definitely doesn't seem correct.
Would it be possible for someone to shoot me over what the nirtcfg file should be?
Can’t you just force the controller into safe mode from the console and copy nirtcfg off of that? I’m pretty sure that will work.
I'll have to try /etc/init.d/nisetbootmode force-safemode && reboot to change the flag I think, because the MAX connection is not letting me set safemode.