NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Replace startup.rtexe while it is running on Linux targets?

Solved!
Go to solution

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 1 of 13
(2,584 Views)
Solution
Accepted by topic author RVallieu

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.

Message 2 of 13
(2,573 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 3 of 13
(2,566 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 4 of 13
(2,489 Views)
Solution
Accepted by topic author RVallieu

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

Message 5 of 13
(2,483 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 6 of 13
(2,480 Views)

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

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 7 of 13
(2,479 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 8 of 13
(2,474 Views)

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

0 Kudos
Message 9 of 13
(2,471 Views)
Solution
Accepted by topic author RVallieu

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 10 of 13
(2,468 Views)