Is it possible to stop a plugin from an sbcExecutable

droftarts

Ian

chrishamm

@stuartofmt That's right, the plugin service(s) monitor the PID and that is reflected using the object model. Partially stopped means that the plugin is either stopped in DWC or on the SBC. What are you trying to achieve using the stopPlugin call?

stuartofmt

@chrishamm said in Is it possible to stop a plugin from an sbcExecutable:

@stuartofmt That's right, the plugin service(s) monitor the PID and that is reflected using the object model. Partially stopped means that the plugin is either stopped in DWC or on the SBC. What are you trying to achieve using the stopPlugin call?

I am trying to achieve the same user experience as occurs when the plugin is stopped from DWC. In other words, the status goes from started to stopped.

I expected the http call /machine/stopPlugin to do this but instead, in the DWC UI, it shows as partially started, which is confusing for a user.

Its as if the /machine/stopPlugin is sending SIGTERM to the executable but not updating other information to indicate that the plugin itself has been stopped.

The bottom line is that the /machine/stopPlugin http call should behave the same way as the "stop" button in DWC.

chrishamm

@stuartofmt You cannot unload DWC plugins instantly (unless you refresh the UI which isn't always safe, e.g. while editing a file), so this is hard to implement.

stuartofmt

@chrishamm said in Is it possible to stop a plugin from an sbcExecutable:

@stuartofmt You cannot unload DWC plugins instantly (unless you refresh the UI which isn't always safe, e.g. while editing a file), so this is hard to implement.

I'm not sure I understand why. It works as expected when the stop button in DWC (for the plugin) is clicked.

Should not the /machine/stopPlugin http call behave in the same manner? I'm not sending the htttp call from the plugin UI. I'm sending it from the executable.
In my case the .vue file is really only presenting an iFrame as the executable is creating the UI for the plugin.

chrishamm

@stuartofmt When you press Stop Plugin in DWC, the SBC plugin is stopped and the DWC plugin is removed from the list of enabled DWC plugins, however it is NOT unloaded instantly. The /machine/stopPlugin is just responsible for managing the plugin state on the SBC. Perhaps better monitor the SBC plugin PID in your Vue plugin and change the UI accordingly?

stuartofmt

@chrishamm said in Is it possible to stop a plugin from an sbcExecutable:

the SBC plugin is stopped and the DWC plugin is removed from the list of enabled DWC plugins

I think we may be at cross purposes, especially, the SBC plugin is stopped and the DWC plugin is removed from the list of enabled DWC plugins. It's also sending a SIGTERM to the Executable (correct?).
So why not implement all this as the stopPlugin http rest call ?

The interactions currently look like this:

The issue is not (or at least does not seem to be) that there is a delay in unloading the plugin. Even after several browser refreshes, it still shows as partially started but if I then click stop, it does change the status to stopped.

stuartofmt

@chrishamm
I guess the real missing link for me is "What is the intended use case for stopPlugin?" or does it behave differently if called from the plugin (.vue) itself?

Earlier you mentioned When you press Stop Plugin in DWC, the SBC plugin is stopped and the DWC plugin is removed from the list of enabled DWC plugins is this something DWC does but for which there is no rest API?

chrishamm

@stuartofmt There is no REST API call to disable DWC plugins, that's handled by DWC itself. If you need to disable a plugin on the SBC and in DWC for some reason, it's best to call the stopPlugin action via the DWC Vuex store because that does both (even though, as I said, the corresponding DWC plugin remains loaded until the session is refreshed because it is not possible to unload existing JS chunks safely).

stuartofmt

@chrishamm said in Is it possible to stop a plugin from an sbcExecutable:

@stuartofmt There is no REST API call to disable DWC plugins, that's handled by DWC itself. If you need to disable a plugin on the SBC and in DWC for some reason, it's best to call the stopPlugin action via the DWC Vuex store because that does both (even though, as I said, the corresponding DWC plugin remains loaded until the session is refreshed because it is not possible to unload existing JS chunks safely).

Thanks - I am testing a two-way solution. The sbc Executable can send a /machine/stopPlugin (which will effectively terminate itself.
I'm doing this because I assume the plugin service does not poll / monitor the sbcExecutable pid. Does it?

In any case - I have the plugin poll the pid of the sbc executable. If it goes to -1 then it will terminate the plugin and cause a browser refresh with window.location.href = <DWC Ip>/Settings/Plugins";
This seems to work fine. Are there downsides to the refresh?

One last question - in my javascript ignorance, I'm getting the pid using this code.

const allplugins = store.state.machine.model.plugins;
for (let [key, value] of allplugins) {
    if (key == "DuetLapse3"){
        console.log('Pid = ' + value.pid);
	    if (value.pid > 0){
	        return true
		};
};

The for loop is a bit inefficient but I cauld not figure out how to directly get the object that describes the DuetLapse3 plugin. Is there a more direct way?

chrishamm

@stuartofmt That isn't right, the plugin service keeps track of the PID and that PID is also distributed across the OM. If you terminate your plugin the regular way, the plugin PID will change to -1. That's the main motivation behind the PID, else you wouldn't be able to see the plugin state in DWC.

Refreshing isn't always safe as I said, because you may be entering data or editing a file when the plugin stops (in theory). So I would advise against refreshing the page when the SBC plugin is stopped.

You could probably create a computed property and just access store.state.machine.model.plugins.DuetLapse3?.pid and check if that is not undefined and not -1 to figure out if your plugin is loaded and running.

stuartofmt

@chrishamm
Thanks for the pointers. Due to the somewhat unique nature of my plugin, I've ended up with a combination of your suggestions and my own clumbsiness. Still, its working fine, not refreshing the page, and showing as "stopped" after a manual refresh

I'll releas this version sometime today.