DSC and service restarts

This topic contains 4 replies, has 3 voices, and was last updated by  Tore Groneng 4 years, 1 month ago.

  • Author
  • #14671

    Michael McClaren

    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?

  • #14672

    Don Jones

    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.

  • #14673

    Don Jones

    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.

  • #14674

    Michael McClaren

    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
    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

  • #14685

    Tore Groneng


    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?



You must be logged in to reply to this topic.