Re: C# Service Terminating Itself

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Inline


"Wessel Troost" <nothing@xxxxxxxxxxxx> wrote in message
news:op.sue1gnpwf3yrl7@xxxxxxxx
>> Ok, I see your point, you aren't discussing services based on the FCL.
> Yeah. At some point I wrote "We can agree to disagree about wether a C++
> ATL service could.", and you replied "Sorry but I have to disagree.", so
> I went on talking non-FCL after that.
>
>> 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.
>
> Agreed, my point was that if you really need higher privileges, a service
> used to be the way to do it.
>
That doesn't mean it should run as SYSTEM, create a local service account
and grant the privileges he needs and enable the privilege in code, but
please don't put your service in the TCB, at least not on XP or higher. I
know W2K needs this to call LogonUser, but higher OS'ses don't need this
privilege any longer. Note also that on W2K3 and XP SP2, you cannot call
CreateProcessWithLogonW when running as Localsystem.

>> 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.
>>
> Yeah.
>
>> During development, right. But, ever killed services on a production
>> server running MS cluster server with potentially 5000++ users logged on?
>>
> Haha, not 5000++ no, but over 100, sure. If your alternative is a reboot,
> killing a service is the lower-impact option.
>
What's the difference 100 or 5000, killing a service that might crash other
services, or in the case of cluster server might crash the cluster service,
is defenately worse than a reboot of a single node.

>> have a bug in your code which must be solved before you can call this
>> program a 'Service'.
>>
> I hope you're not saying that a 'Service' has to be bug-free. Terms like
> "bug free program", "first-time right development", "fixed requirements"
> are the telltale signs of a newbie project leader :)
>
No, I'm in this business for 35 years now, I know that software is bug-free
until the first bug shows up. I say that it's clearly a bug when you can't
stop a service. and it's the kind of bug you should correct before the bugs
in the 'service' code, unless they are closely related. I've seen to many
services that run correctly otherwise but had problems to stop or didn't do
the right thing when stopping (process that keep running when the service
was stopped). One of the popular answers I heard was "services are designed
to run" not to stop.
I agree that not all services can/should be bullet proof, but at least when
they fail they should fail in a correct way, or to put it differently - they
should be as failsafe as possible (asp.net is one example of a fails safe
hosted service).
Especially business critical services that run on large boxes or in a
cluster should be designed such that they are fully controlled from the
outside, that is from the cluster manager (note that you shouldn't even use
the Services applet in a cluster case). They should also be designed to
correctly report their status when asked for, and they should be prepared to
fail over when they don't reply on the status requests.


> Certainly a C++ service can be expected to crash the hard way. One of the
> nice things about .NET is that it's very stable in the crashing
> department. I've never seen a pure .NET program segfault.
>

Define a pure .NET program, never used PInvoke to call into native code and
have your arguments defined or the calling convention incorrectly? Sure the
message wouldn't look like a segfault, but a silently dying thread or
"execution engine error" leaving no trace in your logfile and he! its' a
service, so no user message on the destop either. Note that this is another
major problem in .NET, too much PInvoke using the wrong calling convention,
or passing incorrect types. This kind of error doesn't show up at the first
call (thanks to the hacks in the CLR that try to correct the calling
convention mistakes in user code), but it shows up only after hours or days
maybe, not a pretty face when this happens to a service and certainly not
easy to debug.

>> 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.
>>
> Hmm, what's bad about simple services? They can start automaticcaly
> after an "automatic update reboot". That's pretty nice for a background
> program.
>
A lot of them shouldn't run as a service but as a scheduled task, and don't
forget that the number of services are restricted in Windows (OS version
dependent). That's why I called it a "service boom", in my daily consultancy
job for a large company it became one of the most irritating questions to
ask - how many services are you running by now. The answers go leke; huh..
don't know, it doesn't matter it runs in the background at a lower
priortity; or the service is only actively running once a day for a couple
of minutes.

> It also looks more professional. System operators prefer Services to a
> simple Forms/Console application that does exactly the same thing.
>
Sure, and they want the service to have a UI too ;-). which is just another
problem source since the intro of .NET. (not .NET fault though).

Greetings,
Willy.


.

Relevant Pages

  • Re: OpenVMS - When downtime is not an option
    ... application bug to provide access to protected data and/or provides ... elevated rights on the system, does sit matter if it is an application ... privilege (certainly not including the parsing functions that these bugs ... Server* design flaw, not a Windows flaw. ...
    (comp.os.vms)
  • Re: OpenVMS - When downtime is not an option
    ... Clearly, that would be an OS bug (or at least a serious design flaw, if indeed it were intentional rather than inadvertent) - *if* it had been the case in this instance. ... If Exchange Server was designed such that it had to execute in a privileged environment, rather than designed modularly such that at most a few critical parts of it might require privilege and the rest could run unprivileged, that was an *Exchange Server* design flaw, not a Windows flaw. ...
    (comp.os.vms)
  • Re: Missing Files After Panic/Fsck?
    ... > If this happens then it's a bug and you should complain to the ... > cluster vendor. ... I'm not disputing it's a bug: I'm just wondering whether it can ... happen in current cluster systems. ...
    (comp.unix.solaris)
  • Re: Missing Files After Panic/Fsck?
    ... > If this happens then it's a bug and you should complain to the ... > cluster vendor. ... I'm not disputing it's a bug: I'm just wondering whether it can ... happen in current cluster systems. ...
    (comp.sys.sun.admin)
  • Re: How to upgrade to SP2 on active/active
    ... SS2K5 RTM had a bug in that the tools were not deployed to all cluster ... However, starting with SP1 and later, this bug was fixed in that the patches ... 2- Log on node 1 and install the SP2 on the two instances ... 4- Reboot node 1 ...
    (microsoft.public.sqlserver.clustering)