>>That might work but seems (perhaps of necessity) a little convoluted. Haven't looked closely but there are a couple of properties on ServiceBase that might help:
>>The RequestAdditionalTime() method in the OnStop() might have some effect.
>>There's also a CanShutDown property which will cause the OnShutdown event to fire - although I'm not sure what you can do with it.
>>
>>There's also a registry setting which can increase the time the SCM will wait for a service to shutdown. See WaitToKillServiceTimeout.
>>
>>But, at the end of the day, you should still program so that the service can shut down safely and coherently in a short period of time.
>
>That's exactly that. We just cannot afford one single situation that one of our services will be in a middle of a process and subject to a brut force termination caused by a reboot.

Well a reboot (i.e. a shutdown) is not a 'brute force termination' - it's either initiated by a user who is logged on with sufficient privileges or maybe something like a UPS during a power failure. In either case it should be assumed that there is a valid reason for the action and your service should be designed to shut itself down safely in a short period of time - failure to do so can place the state of other services at risk.

Look at it from another perspective : what you want would equally allow a rogue service to prevent shutdown indefinitely until someone pulled the plug :-}

I'd look at tweaking the service kill time registry setting and maybe experiment with the RequestAdditionalTime method. But it should surely be possible to design a service capable of shutting down gracefully within 20 seconds ?

FWIW, there's a low level flowchart here of the communication between the SCM and a service: http://msdn.microsoft.com/en-us/library/windows/desktop/ee126211(v=vs.85).aspx


>Initially, I thought that the service design would have been a little smarter than that. For example, CanShutDown with the event apply. So, I thought that in there we can let it know what we acknowledge the request for termination or activate a property or an event that will interact with the user, but by the usage of the OS. In that case, it would have been possible to let the user know. I had assumed this is what most of the services are doing. I face that situation a lot. Whenever I need to restart the server, I will sometimes receive a message and then it goes off by itself. The restart now continues its restart procedure. But, I would then assume that all those situations are bound to the usage of Local System Account.
>
>I just cannot understand the restriction in the OS that the usage of another account cannot benefit of the interaction. To me, this is also related to the OS infrastructure and something could have been done for that up to where we are today in the OS.
>
>It seems quite obvious that many enterprise product requires one or multiple services to run on a domain account, so to benefit of NAS resources, the network and so on. I just do not understand why we have to go from Montreal to Florida by doing a detour up to Vancouver.
>
>So far, the safest way is a slave service to check it out. But, that is an additional project I would like to avoid to support. Despite the fact that it would be generic and wouldn't change after, it is still one additional project that we have to add in our infrastructure which it wasn't planned.
>
>I have found so far that very limited environment have this need, or not at all, assuming that they would like to have the support but prefer to do as we do now by adding procedures to the network team that any restart of a server requires intervention from the tech team to shut down manually specific services which would then be started manually by them on startup.

Isn't shutting down the service 'manually' the same (from the services POV) as just shutting down the system ?