So the issue that I have is that some of the files that we need to keep in hand are configuration files that are only read when the service starts. For instance, php on IIS. The php.ini file is read once when the service starts. So here is the scenario, a change is made to the php.ini and this is not correct, when DSC runs its next pass it changes the file back to what it should be however this is not reflected in IIS as the running config has not changed. The service needs to be restarted.
I have tried this in a script provider
iisreset /stop
copy the files
iisreset /start
however this does not work, I have also substituted stop-service and start-service however these do not work either.
The question is, Does DSC provide a method to stop a service if the file is locked, or restart a service to reflect the change of a configuration file?
There’s nothing explicitly built-in, no. If Stop-Service isn’t working, then the service itself isn’t responding to control messages - short of outright killing the process, I’m not sure anything could be done about that.
But I’m not sure you’re entirely correct. PHP, for example, re-reads php.ini each time a new worker process is started to service the web site’s application pool. You’d really just have to tell IIS to recycle all the WP’s. A lot less intrusive than stopping all of IIS. At least, that’s how it works on several of my servers.
But… no, there’s nothing native in DSC that would do this for you.
Yeah, I think I’d built a custom resource for this instead of using the File resource. Check the file, fix it if need be, and IF it was changed/fixed, dump the worker processes for the designated website. I mean, you COULD just use Stop-Process to kill all w32p.exe processes - but you’ll terminate any requests they’re handling right then. Gracefully recycling the app pool might be preferable. Depends on your situation, I suppose.
I can agree that recycling the app pool is more graceful, it was more an issue with the large number of app pools that are involved.
At any rate this is what I actually used to do this.
SetScript = {
stop-service w3svc
$repo = ‘path to the good files’
$target = ‘path to the files that we need to fix’
$scan = gci $repo -recurse | ?{!$_.PSISContainer}
foreach($object in $scan)
{
$clip = ($repo -replace(“^.\“,”“))
$name = ($object.fullname -replace(”^.$clip\”,“”))
$destination = $target+""+$name
if(test-path $destination){
copy-item $object.FullName $destination
}
else
{
new-item $destination -ItemType file -force
copy-item $object.FullName $destination
}
}
start-service w3svc
}
The files get copied no problem, and if this is run in a normal shell it works exactly as expected. Once this is deployed to the pull server however, it no longer works and the service does not cycle. I am not sure that there is a difference once this hits the MOF and how this is implemented. There is also no difference between stop-service and iisreset /stop
Could you execute the start-dscconfiguration with the -wait and -verbose switces set and show us the output? Also a good idea to include some write-verbose in your script resource to follow what is happening in your script. Also what does you TestScript look like?