01-15-2018 02:11 PM
I had posted this question over on the LabVIEW board, but realized this might be the better location.
I have a need to replace the startup.rtexe file with a new startup.rtexe file while the original startup.rtexe executable is running. It seems like this is possible on Linux targets (I am new to Linux myself) but I need to somehow unlink the application running in memory from the file on disk first.
Is this possible in LabVIEW RT?
I don't have network connection to the targets as they are deployed in the field and will be transferring the files via CAN and Serial most likely and then attempting to replace the startup.rtexe when the copy is verified.
Solved! Go to Solution.
01-15-2018 02:40 PM
Hi Ryan,
The startup app (or "rtexe") on disk is opened and loaded into LabVIEW RT's runtime on startup. The way that Linux works when it comes to files on a filesystem, you can certainly replace a file that's already opened by a program, and that program will continue to "see" the original file as it opened it¹. This means that you can replace the startup application while it is running and it will not impact the running application, it will only impact future launches of the LabVIEW RT runtime (done on reboot).
¹This does not hold true if you modify a file, e.g. change its contents. Some programs, most notably the deprecated FTP server that can be installed to targets, will open-truncate-write files instead of the unlink-create approach. The former may cause issues with startup apps, the latter will not.
01-15-2018 03:03 PM
Thanks, I wasn't sure about being able to replace the running RTEXE startup file while the EXE was running - this makes the job that much easier at least!
I appreciate the quick answer.
01-18-2018 01:26 PM
Well - now I have an issue with LVRT not having file permissions to do delete or rm using the System Exec in the /home/lvuser/natinst/ folder.
I can't use the regular file Delete (Error 😎 or the RM command (no permission). Set Persmissions.vi is not allowed to change the permission from within LabVIEW because of the lvuser level of access.
01-18-2018 02:50 PM
Hmm, that doesn't seem right. Are you attempting to remove the startup app from the startup app itself? I mean, that should work as well. What is the permission? Did you move/copy/etc. the .rtexe file using an "admin" login (ssh or serial console)? Checking on a target that I have handy, I see the ownership/permissions of the .rtexe file is
lvuser@Pretendo64:~$ ls -l /home/lvuser/natinst/bin/startup.rtexe
-rw-rw-r-- 1 lvuser ni 30984 Jul 26 14:50 /home/lvuser/natinst/bin/startup.rtexe
RW for lvuser (the user running the LV RT runtime engine), which means you should be able to remove the .rtexe from G
01-18-2018 03:18 PM - edited 01-18-2018 04:06 PM
It was just installed through the Project and yes, I am attempting through LabVIEW - but right now not the RT EXE itself, running Front Panel interactive (which I thought should still be lvuser level access).
I did download a backup and then upload into the folder we're going to load the new RTEXE into that will be used to update the system - used the web Remote File Browser for that - so the ownership of the file to mv will probably be an issue.
01-18-2018 03:34 PM
Hmmm
admin@PEMS-Simulator:~# ls -l /home/lvuser/natinst/bin/startup.rtexe
-rw-r--r-- 1 admin administ 30366488 Nov 14 15:00 /home/lvuser/natinst/bin/startup.rtexe
01-18-2018 04:03 PM
ok well if they are supposed to be lvuser and ni group as the owners of the files and folders in the /home/lvuser then something got changed (maybe from me poking around via Web Interface.
I shelled in and changed the the owner to lvuser:ni recursively on /home/lvuser so now my settings match yours. I will try again with my code to see if it can RM and MV my files through LabVIEW System Exec in my program now.
01-18-2018 04:08 PM
Yeah, the permissions from what I showed was from a normal deployment of a built application from the project. Depending on how you intend on delivering the updated apps, you may need to make some adjustments to allow for that. Permissions and ownership help with security, and as is often the case, this costs a little bit of ease and/or convenience
01-18-2018 04:18 PM - edited 01-18-2018 04:42 PM
After changing the permissions back to lvuser and group ni for /home/lvuser the code was able to do the delete/move.
Thanks for the prod to check the ownership, I'll keep that in mind from now on when dealing with files on Linux RT and accessing through the Web Browser.
We'll be using the LV code to upload the files to the targets - so permissions should be ok in the actual systems.