5 Replies Latest reply on Feb 2, 2017 7:41 AM by Brett Chaborek

    Stopping Responder Windows Service

    Brett Chaborek

      When stopping the Responder Windows Service we receive the following warning in the Windows Event Log:


      2017-01-26 12:10:40,656 [36] WARN  Miner.Responder.WindowsService.Program [(null)] - Kill Miner.Responder.DataServices (17484). Process did not shut down in the allotted time (00:01:30)


      It doesn't seem to cause any issues on next startup, but I am just wondering if there is any reason that the processes do not shut down within the given time of 1:30 leading to them being killed, and if there is something that will allow for a more graceful shutdown?



      I believe during implementation, the value was set to 1 minute 30 seconds to allow more time for the data services to shut down, but it hasn't seemed to have any effect. Is there any harm to lowering the threshold for killing the services on shutdown? Where would this be set..  I imagine somewhere in one of the config files?


      We are on Responder 10.2.1a SP1 build 1552



        • Re: Stopping Responder Windows Service
          David Miller

          Are all your Responder clients already shutdown when you try to bring down the service?  Responder will take longer to shut down if the clients are still actively connected and it has to kill them.

          • Re: Stopping Responder Windows Service
            Shawn Leingang

            It really shouldn't be configured to be any higher than the default of 30s.  A restart command through Windows only allows two minutes to complete the shutdown and the startup of the processes and having it set so high leaves little time for the actual startup.  It's a termination command to make sure it does shut down in a timely manner.  On some systems, the processes don't self exit but are in a shutdown state and not accepting any more work either.  This just helps them along their way.  The counter doesn't start until the process has accepted the shutdown command so there is no data loss. 


            I'm not sure where this config is as it's not something recommended and we'll need to look into it.  Can you log a ticket with ESRI CA for reversing the configuration and we can research this further?