I want my service to be able to be restarted remotely (by a TCP client which is not part of this question). I configured the service to restart on failure on the Recovery tab for my service. In my code I set the ServiceBase.ExitCode to a non-zero number, say 1. I did not use Environment.Exit to stop the service because it isn't necessary to terminate the process. When I test my service it stops correctly and the Windows System Log reports that my service has stopped with an error. It also names the error. But my service does not restart! When I instead use Environment.Exit(1) the Windows System Log reports that my service has stopped unexpectedly without naming the error. It then does restart the service as if it has failed (like it should).
My question is, why doesn't the service restart with just a non-zero exitcode? The service stops with an error but that isn't failing? Is Environment.Exit the only way to properly trigger a service restart on failure? I liked using the ExitCode better because the System Log is cleaner and more accurate that way.
Did you check the "Enable actions for stops with errors" checkbox on the Recovery tab?
From the technical documentation, the service's exit code is only consulted if that option is checked.
Related
I am having trouble getting the feature recovery on failure to work for my Windows Service Application. I set in up to restart the application on first failure. Then to test in I use this line of code
System.Environment.Exit(-1)
This causes the application to end okay but it doesn't restart.
It is reasonable to suppose that a service process exiting without setting the service status to stopped would constitute a failure. However, that isn't the case. (Perhaps for backwards compatibility; there might be too many third-party services that such a change would break.)
However, if the process exits as the result of an unhandled exception, that is considered a service failure and triggers the recovery options. So if you want to cause the service to fail, raise an exception (and don't catch it).
I have a (dead-letter) queue on my local machine called logging/logdeadletterservice.svc. I have a corresponding service running at appdev.me.com/logging/logdeadletterservice.svc to pull the messages from the queue and resubmit them. This works great so long as the worker process is running. However, once the worker process is shut down (or if it hasn't come up yet), the service no longer gets messages from the queue unless I browse to the SVC manually.
According to this post, NETWORK SERVICE needs permissions to peek the queue. I went ahead and added that permission, but the message was not pulled from the queue. I tried restarting the Net.Msmq Listener Adapter (which is, indeed, running under Network Service), but still no go.
Any ideas on what I'm doing wrong?
EDIT: I've tried running sc sidtype netmsmqactivator unrestricted and restarting the service, but no go. Switched it back to restricted (original) after it didn't resolve the issue.
EDIT2: Also tried running the Net.Msmq Listener Adapter as myself (which is the user under which the service is running), but no go.
Ended up using AppFabric and running the following commands against appcmd.exe to get the pool to be always available and always warmed up:
%windir%\system32\inetsrv\appcmd.exe set apppool "My Site" /startMode:AlwaysRunning
%windir%\system32\inetsrv\appcmd.exe set app /app.name:"My Site/My App" /serviceAutoStartEnabled:True /serviceAutoStartMode:All /serviceAutoStartProvider:Service
I have two windows services. One ('server') acts as a WCF host to which the other ('client') connects. So I have configured a dependency from client to server. Both are also set up to start automatically.
When I start these services by hand, everything works fine. When I stop both services and tell client to start, then server will be started before client and all is fine.
However, when I reboot the machine only server is started.
When I add a diagnostic listener I see it got a TimeoutException with the helpful message:
The HTTP request to 'http://[server address]' has exceeded the allotted timeout of 00:00:00. The time allotted to this operation may have been a portion of a longer timeout.
At some other SO question there was an answer that claims WCF is probably confused about what went wrong and therefore starts lying about the timeout.
Did I perhaps miss a dependency for either service? Does WCF require something that hasn't or is being started when client is trying to contact server?
I think you should check your client service. On startup windows services are starting while network devices are still being initialized. Services should be ready to start without network and without any network device. Usual approach is to keep periodic retries to establish connection. You can do little experiment on your machine by uninstalling all network adapters and trying to start up your services.
Additional quick workaround you can do is to setup recovery options on your service -- for example you can configure it to restart service on crash after some timeout -- you can do this through UI in services.msc or in command line using 'sc config' command.
Configuring the dependency between the two Windows Services is not necessarily sufficient to avoid there being a race condition: i.e. to avoid the client service calling the WCF service before the server's WCF channel stack is fully initialised.
The service dependency just ensures that the Windows Service Control Manager won't start the client service process before the server Windows Service has notified the SCM that it has started. Whether this is sufficient depends on how you write the server.
If the server service starts a new thread on which to initialize the WCF stack, your OnStart method is probably returning before the WCF stack is ready for clients. There is then a race condition as to whether the client's first call will succeed.
On the other hand, if the server service does not return from OnStart (and thus doesn't notify the SCM that it has started) until the channel stack is fully open, the dependency removes the race condition, but there is a different pitfall: you need to beware that the SCM's own timeout for starting the Windows service is not triggered while waiting for the WCF stack to initialise, as might well happen on a reboot if the WCF service depends on the network stack, for example. If the server's OnStart does not return within the SCM's timeout, the SCM will not try to start the dependent client service at all, because it does not receive the server's start notification. (There will be a message in the Windows event log from the SCM saying that the server service didn't start within the expected time.) You can extend the SCM timeout by calling ServiceBase.RequestAdditionalTime while the WCF service is being initialised.
Either way, the client service really ought to be written so that it doesn't fail completely if the first WCF call doesn't succeed.
You don't actually say what binding you are using. If client and server services are always running on the same machine, as you seem to indicate, then consider using the NetNamedPipeBinding: then your service won't be dependent on initialization of networking resources and startup should be quicker.
My Scenario:
I have a Client\server set up on my desktop. I have 3 WCF Services installed through VS command prompt. Everything works fine during the installation but when i actually want to start the services it gives the following message
"The service on local machine has
started and then stopped.Some Services
stop automatically if they have no
work to do,for example the performance
logs and alerts service"
Can any one guide me to the solution ?
The Windows service actually has to do something; otherwise, it will shutdown immediately and you'll get the error you're seeing. "Doing something" usually entails starting a thread in the OnStart() callback of the service. As #sgreeve provided in his comment, refer to the following question for a code example.
Windows Service Stops Automatically
It is also possible that the Windows service is throwing an exception when starting up. In this case, you'll probably want to debug the service to see exactly what is going on. Refer to the following question for how to do that.
Easier way to start debugging a windows service in C#
My application has 50 service endpoints (such as /mysite/myService.svc). It's hosted in IIS. Intermittently (once every two or three days) a service stops responding. It's never the same service that hangs. While a service is hung, some of the other services work fine and some other are also hung.
All clients (from different computers) get this error:
ServiceModel.CommunicationException
Message: An error occurred while receiving the HTTP response to
https://server/mysite/myservice1.svc.
This could be due to the service endpoint binding not using the HTTP
protocol. This could also be due to an HTTP request context being
aborted by the server (possibly due to the service shutting down).
See server logs for more details.
No exceptions are raised by the server when the client attempts to call the service that is hung. All I have is that error on the client side.
I have to manually recycle the application pool to fix the problem.
Do you know what could be the cause? How can I investigate this issue? I'm willing to take a memory dump of the worker process when a service is hung but I would not know what to search for in the dump.
Update (Aug 13 2009): I have almost ruled out the idea that the server runs out of connections (see comment in Shiraz Bhaiji's answer). I might have a new lead: I log all server-side exceptions in a log file. So in theory, when this occurs on the client, no exceptions are raised on the server; otherwise I'd have proof of that in my logs. But what if an error does occur on the server but is happening at a low level where exceptions are not routed to my exception handling code? I have posted this question about scenarios where low level exceptions cannot be handled. I'll keep you informed of the progress of my investigation.
Sounds like you are running out of connections.
By default WCF has a timeout and therefore holds a connection open for 10 mins.
When you recycle the app pool all connections are closed, and therefore things work again.
To fix it check your code to make sure that you close connections / dispose of proxies.
To resolve this, we set establishSecurityContext to False on the binding.
I have not come across this particular issue but would suggest to turn on tracing/message logging for the WCF service in the config for the service and/or the client app (if you have control over that). I've done this in the last few days for a service that I needed to troubleshoot.
The MSDN link here is a good starting point.
Also see the table in this post for the varying levels of trace detail you can configure. There are several levels which can go from exception only logging to full message details. It is quite quick to set this up in the app.config file.
To parse the log file output use the SvcTraceViewer.exe that comes with the Windows SDK, which if you have it installed should be located in this folder: C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin