You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Starting the service in this manner makes it difficult for the exe stub to track if the PowerShell service-script is still running. So here's the idea: why not removing the SCMStart/SCMStop parameters altogether, and directly call the PowerShell service-script from the exe stub?
This would make possible the implementation of an option to restart the PS script if it fails - which would turn the exe stub into a monitoring service.
I'd also like to know what you think about this idea of a service restarting the PS script.
The text was updated successfully, but these errors were encountered:
Aorimn
changed the title
[PSService] Question on
[PSService] Question on PSService implementation
Apr 3, 2018
The PS script, when run with the SCMStart parameter, will start a new PowerShell session for the same script
When you invoke the PSService.ps1 script yourself, it runs with your own identity, in your session.
The service runs as a different user, in a different context from yours. This is why the exe stub starts a second instance of the script.
why not removing the SCMStart/SCMStop parameters altogether, and directly call the PowerShell service-script from the exe stub?
This is exactly how this works now.
I'd also like to know what you think about this idea of a service restarting the PS script.
If we can make something simple, why not?
Note that theoretically the Service Control Manager already does that automatically. I've not made any test to verify if this works or not though.
In the current implementation of PSService.ps1, the exe stub serves as the real service. When the service is started, this stub starts the PS script with the
SCMStart
parameter.The PS script, when run with the
SCMStart
parameter, will start a new PowerShell session for the same script but with theService
parameter (let's call this one the PowerShell service-script), then return.I've looked at your article but didn't find an explanation on why this part is implemented this way.
Starting the service in this manner makes it difficult for the exe stub to track if the PowerShell service-script is still running. So here's the idea: why not removing the SCMStart/SCMStop parameters altogether, and directly call the PowerShell service-script from the exe stub?
This would make possible the implementation of an option to restart the PS script if it fails - which would turn the exe stub into a monitoring service.
I'd also like to know what you think about this idea of a service restarting the PS script.
The text was updated successfully, but these errors were encountered: