I trying to Deploy a moderated size project in cloud as Service,
it giving me a fatal error , i am not able to figure out what the mean of error and cause is
Azure Deployment Stack Trace :
Role instances recycled for a certain amount of times during an update or upgrade operation.
This indicates that the new version of your service or the configuration settings you provided
when configuring the service prevent role instances from running.
The most likely reason for this is that your code throws an unhandled exception.
Please consider fixing your service or changing your configuration settings so that
role instances do not throw unhandled exceptions.
Then start another update or upgrade operation. Until you start another update or upgrade
operation, Windows Azure will continue trying to update your service to the new version or
configuration you provided
For this kind of deployment error, you better try to run your application first in the Azure Compute Emulator and then deploy in the Cloud. So you can get the unhandled exception information, also don't forget have try catch in your code.
Related
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.
I have asp.net core web app that has been running fine in an Azure app service for the past couple of years. I have regularly published new versions of the app using the "Publish" feature in Visual Studio 2019, and have never received the 503 error while the app service is running. I recently set up a multi-stage release pipeline for the app in Azure DevOps. The first stage of the pipeline deploys the build to an Azure app service that we use as a test environment. The second stage has an approval condition set up on it and after the approval is completed, it deploys the build to the app service in our production environment.
This is my first deployment using the pipeline. For the past couple weeks, I've deployed builds through the first stage of the pipeline and tested the app service with no problems. When we approved the build for Stage 2, the pipeline completed successfully (with no errors in the logs) and the build was deployed to our production environment. However, when I try to access the app service I receive a "503 Service Unavailable" error.
I have tried restarting the app service (several times), and compared the configurations between our test and production environments, but did not find any significant differences between the them. I compared the pipeline stages and the only difference I saw was the app services they deployed to.
Unable to resolve the issue, I ended up setting the "WEBSITE_RUN_FROM_PACKAGE" setting to "0" and published the app from Visual Studio, instead of using the pipeline. This was done only as a temporary work-around, so our users would not experience an extended outage while I work to resolve the pipeline issue.
So, now I need to figure out what is causing the 503 error when I deploy through the pipeline. If anyone has some suggestions on how I can fix the issue, or point me in the direction of what to look for, I would greatly appreciate the help.
In attempting to create an Azure Container Service (AKS) cluster using the same account information for which I can create a cluster via the portal, I am getting the following error:
ERROR in generic_views: 500 Internal Server Error: Creating cluster
7f3b1ed3-1996-4558-97d1-1672d87d56e1 failed with following reason:
CloudError(\"The client '09ad439c-5569-4e9b-8b23-3311d6837a21' with
object id '09ad439c-5569-4e9b-8b23-3311d6837a21' does not have
authorization to perform action
'Microsoft.ContainerService/managedClusters/write' over scope
'/subscriptions/21a6a032-5d60-45a6-ae51-c5f0c4007995/resourceGroups/MC_BruceContainerGroup_BruceCluster1_eastus/providers/Microsoft.ContainerService/managedClusters/7f3b1ed3-1996-4558-97d1-1672d87d56e1'.\",)
I tried adding (IAM) permissions for Azure Container Services to the RG used, and to the APP, but it didn't work. What do you think could be causing this error?
I actually resolved this issue by adding Access Control (IAM) permissions for ALL Azure Applications to the subscription... I am not sure adding which one resolved the issue, but I suspect it was the Azure Container Service.
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).
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