Graceful shutdown prior to package update

[TurboPhil]

Are there any best practices for handling upgrading packages on clients via Systemlink, when the executable in the package is actively running?

From our discussions with NI so far, it seems the best option is to create a "pre-uninstall" action for each package that runs some sort of script or executable that can communicate with the running process to request it to shut down prior to deploying the updated version. That is obviously unwieldy for several reasons:

• It's extra configuration that needs to happen in every package build specification to include that "pre-uninstall" action (and make sure the executable/script that it calls is included in the *.lvproj and package build spec)
• There is no standardization in terms of the inter-process communicaiton for requesting the process sht itself down.
• There is no mechanism for the main process to respond to the shutdown request (such as to defer or deny it) that would bubble those messages back up to the web UI that initiated the shutdown attempt.

Has anyone come up with a good solution for this, or are there planned updates on the horizon that might improve shutdowns/upgrades via Systemlink web ui?

[JoshuaP]

SystemLink doesn't provide anything out of the box for shutting down processes on Windows for several of the reasons that you mentioned.  I'm not aware of any standard methods for doing it on Windows.

Now, Linux RT is a different story since all RT startup applications have the same name and there is a single service that manages them.  We stop the running LVRT exe anytime we deploy an updated RT application and then start it back up after the install is finished.  This is done with some pre-uninstall and post-install custom scripts that are automatically added when you build an RT package that includes a startup application.

If anyone knows of a standard way of doing this on Windows for any application we could consider doing something similar, but I haven't found anything that works universally.  

[TurboPhil]

In my mind, I would envision something like this as a generalizable approach:

• Open a TCP listener socket on the Systemlink Client to which deployed executables can connect
• Create a LabVIEW API that can easily be dropped into a packaged application that allows it to open a TCP connection to the Systemlink client running on localhost
• Then, the Systemlink Server would only need to interact with the Client, as it already does, and the Client could then behave as a router to route messages to and from the individual running processes that it has launched on that machine.
• The API should include basic messages like shutdown requests, and perhaps pings and/or status update requests.
• When we initiate an update via the main Systemlink Server web ui, it should start by attempting to send a message to the currently-running version, by way of the Systemlink Client. It should also be able to receive and display response messages, in case the application needs to defer or reject the shutdown request (i.e. if it is not in a state in which is it safe to shut down).

I would think such an API wouldn't be too terribly hard to put together. It would probably need to be OO-based, so it could be extended to cover more complicated use cases. But I think it would be pretty doable, and by using something simple and low-level like TCP, it should be OS-agnostic. And by leveraging the existing SystemlinkClient as an intermediate router, it would avoid complications like port conflicts when multiple processes are deployed to a given host.