Trying to publish a webjob from Visual Studio 2013, but I'm getting the following error in the output window:
Error 14 An error occurred while creating the WebJob schedule: BadRequest: The condition specified by the ETag is not satisfied.
The job is being published as an "on demand" type instead of "scheduled".
Ideas?
I'm one of the program managers on the product and this feature in VS is important to me so I'd like to help you work through this. Any chance, is your code available so we could attempt a repro of the error you're seeing?
Redeploy the Web Site into a different region, it seems the region EAST-US2 does not support WebJobs.
I deployed it into South Central Us and it works fine there.
The following screenshot taken from the Azure Portal shows the regions that can be used to create scheduled jobs:
Not sure if it has much to do with this, but I was experiencing the same issue for a Webjob being published in the Australia East region.
I was trying to publish a scheduled job, but was getting the error:
Error 14 An error occurred while creating the WebJob schedule: BadRequest: The condition specified by the ETag is not satisfied.
I did notice some restrictions on the webjobs in the free tier (see here -
http://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/ )
While it doesn't say that scheduled jobs were excluded from the free tier I had suspicions it would have been (it makes sense for scheduled to be excluded from this tier from a MS point of view).
To fix, I simply changed the website tier to Standard, and I've been able to successfully deploy my job.
Hope that helps someone.
Related
Out of the blue my App service (asp.net core app) is down and nothing helps (e.g. restarting). Not my field of knowledge I have to say. Few noticeable things:
First it throwed 502.
Cannot even access kudu (advanced tools) on https://.scm.azurewebsites.net/ (also 502)
In Diagnose and solve problems and Web App Restarted I have found this:
In Diagnose and solve problems and Web App Down I have found:
2021-10-04T21:19:50.239475918Z Failed to get size of file [/home/site/wwwroot/BlazorApp.Server.deps.json]
2021-10-04T21:19:50.239515518Z Error initializing the dependency resolver: An error occurred while parsing: /home/site/wwwroot/BlazorApp.Server.deps.json
And also this console output:
2021-10-04T20:42:04.875817259Z Running oryx create-script -appPath /home/site/wwwroot -output /opt/startup/startup.sh -defaultAppFilePath /defaulthome/hostingstart/hostingstart.dll -bindPort 8080 -userStartupCommand 'dotnet BlazorApp.Server.dll'
2021-10-04T20:42:04.934145638Z Cound not find build manifest file at '/home/site/wwwroot/oryx-manifest.toml'
2021-10-04T20:42:04.941038071Z Could not find operation ID in manifest. Generating an operation id...
2021-10-04T20:42:04.941048571Z Build Operation ID: 1728b184-ac6f-47b3-a5fa-2ca5f55543ac
2021-10-04T20:42:12.944327812Z
2021-10-04T20:42:12.944356612Z Agent extension
2021-10-04T20:42:19.058804845Z Before if loop >> DotNet Runtime Writing output script to '/opt/startup/startup.sh'
2021-10-04T20:42:25.687081462Z Running user provided startup command...
2021-10-04T20:43:02.238418373Z Failed to get size of file [/home/site/wwwroot/BlazorApp.Server.deps.json]
2021-10-04T20:43:02.238447773Z Error initializing the dependency resolver: An error occurred while parsing: /home/site/wwwroot/BlazorApp.Server.deps.json
Well, thank you for any help you provide!
Edit:
It is located in North Europe. Pay-as-you-go is my subscription. Graph about container crashes is added to the question.
Edit2:
The issue solved by itself after few hour. Is it possible to be related to that facebook outage?
To benefit the community posting our discussion from comments section.
"The issue solved by itself after few hour."
Firstly, apologies for the inconvenience with this issue. Glad to know the issue was resolved. Thanks for the update.
Review the Azure Service Health for any reported issues on your subscription.
Also, review Azure Resource Health and Azure Status.
Azure Service Health provides personalized alerts and guidance when Azure service issues affect you. It can notify you, help you understand the impact of issues, and keep you updated as the issue resolves. It can also help you prepare for planned maintenance and changes that could affect the availability of your resources.
Azure Resource Health helps you diagnose and get support for service problems that affect your Azure resources. It reports on the current and past health of your resources.
Azure status page is a global view of the health of all Azure services in all regions. Reports on service problems that affect a broad set of Azure customers.
You may post your question on Microsoft Q&A forum to receive swift help on such issues from our Microsoft SMEs/MVPs and the Microsoft Q&A community or file a support ticket for any urgent help.
Thanks for your patience.
After performing numerous deployments of some software to Azure, I'm hitting a strange problem which is stopping the deployment from working. (I am doing all these deployments in this case by using Visual Studio's Package command, and then using the Azure portal's Upload button.)
The portal initially says it has successfully started the deployment:
It also says it is creating the staging deployment:
(ignore timestamp, screenshot is from another attempt):
But that's all. It never proceeds to show the instance, going through various states and finally running, as has always happened before. There are no further notifications and no error messages. (Even after 24hrs, for the avoidance of doubt.)
[2
You can also look at the Deployments log for a Resource Group in the Azure Portal by going to that Resource Group > Deployments. All deployments, successful and failed, should be listed there. If you click a failed deployment there should be a note at the top that says Failed. Click here for details. This often gives some more details to why the deployment failed.
Microsofts documentation for this: Troubleshoot common Azure deployment errors with Azure Resource Manager
This held us up for several days. Incredible as it sounds, there's apparently a major bug in the "new portal" that stops the error reporting from working, resulting in a silent failure instead of an explanatory message or logging. In our case we had simply hit our limit of 20 cores in the Azure subscription, but the portal wasn't letting on.
As soon as we deleted a service we didn't need any more, the deployment worked as normal.
The cause was discovered by pure chance, when someone else tried to create a new cloud service just at the time this problem was occurring. A UI message informed them the new service could not be created due to hitting the limit.
The lack of an equivalent message when updating an existing service is is a jaw-dropping defect in the "new portal". Very sadly we are well used to MS error messages being unhelpful, and often even very misleading, but with this silent failure MS seem to have excelled even themselves as far as standards of error reporting go.
EDIT: the old portal helpfully reports core utilization on the dashboard:
Unfortunately that doesn't seem to work on the new portal.
Of far greater significance, though, is that the OLD portal DOES report the deployment failure, rather than failing silently as the "new portal" does:
...which leads to:
So the moral of the tale seems to be: if you have an unexplained deployment problem, use the old portal (https://manage.windowsazure.com). You will probably then find the cause straight away, as the old portal actually reports the failure reason instead of just failing silently as the "new portal" does.
I'm trying to get diagnostics to work on my Azure Web Worker Role. I start out with the stock Web Worker Role solution by selecting 'New Project/Azure Cloud Service'. If I de-select the 'Enable Diagnostics' on the properties Worker Role, then I can successfully deploy the stock web role. It doesn't do much, but it deploys and appears to run. If I select the 'Enable Diagnostics', the deploy fails with:
9:27:34 PM - Applying Diagnostics extension.
9:27:37 PM - Value cannot be null.
Parameter name: s
I've tried various combinations for the 'Configure...' choices but get the same error. This appears on two machines now, so the chances that it's some sort of corruption are slim.
Anyone have a clue what's going on or have a simple, working example of emitting and reading diagnostic messages?
I got a different answer from MS support: “Our Product Team has rolled back the changes.”
I test it, and now I can publish with the diagnostic enabled without problem.
I got an answer from the support : it's an identified backend issue and the tech team is working on it with the highest priority.
As a workaround, disable diagnostics :
I made a web job for my azure website. It works when I click "Run Once" in the azure website web jobs tab but it doesn't work when I set it at determinate time every day.
The web job is marked as success but the it does nothing. I was checking the web jobs logs and it seems that there were five attempts but all of them shows: Http Action - Request to host '******.scm.azurewebsites.net' failed: The job is missing basic auth fields. I have the AzureWebJobsDashboard and AzureWebJobsStorage in the website config, the web job config and in the azure connection string config, I added them everywhere hoping for a fix but it didn’t work.
It was working fine yesterday but today I made a small change, when I uploaded the new version it didn’t work at the time it was set. The change was a new column in a sql query. Has anyone gotten this error? Thank you in advance for your help.
Loading the web job using the azure web page and then configuring the schedule solved the problem. I don´t know why my deploy from visual studio is not working with schedule when it worked fine 2 days ago.
Where exactly are you finding that "missing basic auth fields" error message? What type of scheduled job are you using? I suspect Azure Scheduler. Are you finding this error in the Azure Scheduler logs?
If you're in the Basic or Standard pricing tier, since you're using the WebJobs SDK, there is a simpler schedule mechanism that you can use. See TimerTrigger here.
I have an azure webjob that was deployed few days ago and it seems that it was working normally. Since this morning, if I'm trying to access the azure webjob through the new portal, I'm getting a strange error message: Error loading part...
Does someone knows how this can be "debugged"?
Thank you
Evdin
Many of the Azure users are facing this issue due to migration from Old portal to New portal. As the new portal is still in preview it's better to use old portal if you face any issue in new portal.Also, raise a support ticket to inform microsoft so that they can work on your problem.
I have been experiencing numerous problems with the Azure portal today. First and foremost continous deployment stopped working so, I've been unable to update my web apps.
But I'm also getting: "Error loading part..." in several other areas. I can only recommend creating some buzz, so Azure is alerted to the issues.
If you see these type of errors in IE you can press F12 to see the errors.
Chrome/Firefox can also show HTTP message details.
I am also seeing errors in the new portal.
I was trying to see azure website and I saw "error loading part" errors.
Microsoft_Azure_Billing] 9:30:19 AM MsPortalFx.Base.Diagnostics.ErrorReporter 2 message: Access is denied.
[WebsitesExtension] 9:30:19 AM MsPortalFx.Base.Diagnostics.ErrorReporter 2 message: Access is denied.
New portal is in preview but is no longer optional as many of the services are only available in the new portal. Azure support should be informed to make them aware of this issue.
It seems that the issue is now fixed but I see another strange issue now - the webjob that I described above is showing as "running on demand" in the new portal (I didn't set it up like this) and is showing as "running every six hours" in the old portal (this is how I set it up)... So it seems that everything is screwed overthere...
Thank you for your responses and your help.
Evdin