I have a release process that includes a step where I deploy a windows service. Every time I run a deployment, I find that this step fails to purge the service install directory because files are still in use. If I retry the step, it works fine second time around. I’m fairly sure that this is because the service takes a relatively long time to stop. I can see that the stop action is requested by the tentacle in the AfterPreDeploy.ps1 script that the service install step executes.
I assume that the depoyment step is not waiting for the service state to change from “stopping” to “stopped” before trying to update it. Is it possible currently to set a wait period in the deployment, or to change the step so that it checks that the service state is “Stopped” rather than “Stopping” before attempting to overwrite the service files?
If it’s not, can that be added please?
AfterPreDeploy.ps1 scripts use the
PowerShell command which to my understanding does not wait until it completes before returning.
I have created a ticket to update these scripts so that the deployment waits until the service has stopped (or failed) before continuing.
In the meantime you should be able to create a work around by adding a deployment script to sleep for some appropriate period of time. e.g.
Give this a go and let me know if this temporarily gets around the problem. Hopefully you can get these deployments back to a success every time.
Thanks for bringing this to our attention! Ill be sure to keep you updated as the fix progresses.
After some further investigation it looks like
Stop-Service actually does wait untill the service state is
You can continue to use the previously described sleep mechanism to wait for the service to stop or use the following script
$service = 'MyService’
Start-Sleep -Milliseconds 200
until ((Get-Service $service).status -eq ‘Stopped’)
however I would like to know more about why your deployment in particular is failing. Could you please provide some of the task logs around this deployment as well as details around the typical stopping time of the service in question.
Thanks for this Robert - I’ll try setting up a script to work around this.
I suspect that the issue that I’m seeing with this service is related to the fact that it’s doing a lot of asynchronous task work - the developer who wrote it has also written a bunch of logging code, and in fact the install step fails because an assembly used to log messages to the database is actually in use, so I think now that perhaps the service receives a stop request, fires off a final “I’m shutting down” log message asynchronously, and stops. Bcause there is a short delay while it writes to the database, the background thread is still active, while the log message is written out…
Anyway, I’ll look at some script options for this install instead.
Thanks for the update, that makes a lot more sense. Let me know if you experience any further issues around these service deployments.