Re: C# Service Terminating Itself

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"Wessel Troost" <nothing@xxxxxxxxxxxx> wrote in message
news:op.suc2l7kpf3yrl7@xxxxxxxx
>> Note that above assumes you didn't modify the DACL for the service object
>> (something only administrator can do).
>>
> The service doesn't need SERVICE_START or SERVICE_STOP privileges to stop
> itself. It can just call SetServiceStatus(), which is allowed regardless
> of access privileges. The service can call this only to report its own
> status, something which every service must do.
>

Ok, I see your point, you aren't discussing services based on the FCL. The
framework (v1.x) lacks this level of control, that is you - can't call
SetServiceStatus at all, because they implemented the ServiceBase class to
follow (somewhat too strictly) the SCM interface protocol. That imposes a
problem when you need to abruptly shutdown a service without being requested
y the SCM.
Now, this is something that is taken care of in v2.0 through a method
ServiceBase.Stop(), which calls OnStop() followed by a call to
SetServiceStatus() with the SERVICE_STOPPED status set, followed by the
"Service stopped succesfuly" message written to the eventlog. When the
service is hosted, the AppDomain is unloaded before Stop() returns, then
it's up to the host to ExitProcess or do something else. If the service
isn't hosted, and there are no other active Services in the process, the
process exits through the normal CLR shutdown procedure, else the process
keeps running in the ServiceControlDispatcher.

Another change makes is the possible to extend the start and stop period, by
allowing to hint the SCM (START_PENDING etc...) when there are pending
requests.

>> Or in short Service applications must conform to the interface rules of
>> the
>> SCM, and this can only be guaranteed if both controller and service are
>> separate applications.
>>
> Earlier we agreed (and the OP said) that his service could stop itself, if
> it ran as local system?
>

Yes, but not as local service or network service, which are the prefered
accounts.

> There are many services that require local system privileges. Actually,
> one of the main reasons for writing a service used to be increased
> privileges.
>

I have to disagree, services should run according the principle of least
privilege, just like any other application in the system at least if you
care about security.
Too many services are running with system privileges, something that MSFT
also recognizes, and something they'll change in Longhorn (or Windows
VISTA).

>> of the process shutdown. You see no ExitProcess called ever.
>>
> Kind of a technicality really, but how do you think a userspace process
> signals to the OS that it wants to stop?
>
> When the Main() thread exits, the CLR will call ExitProcess().
>

That's what I meant with :
<and the CLR handles the remaining of the process shutdown.>
I know the CLR calls ExitProcess (it might even call TerminateProcess), what
I mean't was that user code (your code and the FCL) should never call
ExitProcess, and as the FCL never call's it, you won't see ExitProcess ever
called.


>> - You might disturb the SCM!
>
> The SCM can handle crashing services. In fact, I've killed tons of
> services during development using TerminateProcess(), which is arguably
> worse than ExitProcess(). The SCM never became disturbed.
>
During development, right. But, ever killed services on a production server
running MS cluster server with potentially 5000++ users logged on?
The SCM doesn't guarantee to handle crashing services, it's not designed to
handle it, you might have done it several times without a problem, but that
doesn't mean it's common practice, all depends on the type of service, it
might fail and disturb the SCM. In short "killing" services is a bad
practice, just run "net stop servicename" to stop them, if this fails you
have a bug in your code which must be solved before you can call this
program a 'Service'.


>> - you might have other services running in the process AND,
>> - your service might have dependent services running and these must be
>> stopped before your service stops.
>>
> I agree that a service should exit nicely in these circumstances.
>
Sure, and the CLR makes things even more constrained, there are a number of
OS services that should never be called from managed code (and IMO these
services shouldn't even been exposed to managed code at all), Thread.Abort
is just one of them, Thread.Resume and Thread.Interupt are even been removed
fom v2.0.

.
>> If the SERVICE_CONTROL_STOP request is not honored by a SERVICE_STOPPED,
>> the
>> SCM will wait "WaitToKillServiceTimeout" registry value before
>> terminating
>> the process.
>>
> My point was that the service can send a SERVICE_STOPPED without having
> received a SERVICE_CONTROL_STOP. The service process can exit afterwards
> (or not, if it has other things to do) and the SCM will know it has
> stopped.
>
Sure, but not in managed world (see above) where you don't have that kind of
flexibility you have when programming against the low level Win32 API's.
This is the price you pay for simplicity, you can (to) quicly build a
windows service using the framework (didn't you notice the recent Windows
Service boom), but I seriously doubt this is a good thing.



Willy.


.

Relevant Pages

  • Re: C# Service Terminating Itself
    ... >>> and then exits like a normal program with ExitProcess(). ... The other option is the SCM ... > calling TerminateProcess(), and the SCM doesn't do that, obviously. ... Service classes and finally exits Mainand the CLR handles the remaining ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C# Service Terminating Itself
    ... which is allowed regardless of access privileges. ... Earlier we agreed that his service could stop itself, if it ran as local system? ... services during development using TerminateProcess(), which is arguably worse than ExitProcess. ... The SCM never became disturbed. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C# Service Terminating Itself
    ... and then exits like a normal program with ExitProcess. ... ExitProcess from within a service would be disastrous for processes hosting ... The other option is the SCM calling TerminateProcess(), and the SCM doesn't do that, obviously. ... If there are multiple services in a process, the process would only call ExitProcess when all of its services are stopped. ...
    (microsoft.public.dotnet.languages.csharp)