I'm brand new to Azure. I'm trying to get a Cloud Service running with 3 web roles.
Last night I created the .cspkg and .cscfg files, exported the certificates and uploaded everything to Azure manager. The manager said my Cloud Service was successful, however for the last 10 hours when I click on "Cloud Services" in the manager it shows my service, but it says "Creating" with wait gif under "SERVICE STATUS".
Is it really still creating? Or did it fail? Is it possible to view more detailed information about the creation process and/or any log files?
Thanks,
Something "bad" has happened. Service Spin up time should be at most a few minutes.
I've seen it take up to 10-15 minutes depending on the hosting center and the number of scaled instances that need to come up but 10 hrs something has definitely gone wrong.
I would delete the service and start again. If you experience the same problem, have a look in your service start up code and make sure that there's no exceptions/infinite loops, other problems in there that might be causing problems.
It may miss any assembly references. If you included any assembly references(packages that are not part of .net) then please ensure that its copy to local attribute is set to true.
Related
I have a Azure App Service app that I'm trying to get deployed.
Today I ran into an issue where .NET informed me (via the yellow screen of death when I browse to the URL of my app) that I had a missing DLL (for the purposes of this question I don't think it really matters).
I used FileZilla to publish my changes in an attempt to do a manual deployment first and then work my way to automate it.
After so many attempts to fix it I later realized that the error message never changed. I did something more severe and renamed my bin folder into something completely different and the exact same error message would appear.
I've stopped the service, restarted it, and as mentioned, renamed folders, etc. and still the exact same error message persisted.
I also decided to open up the Azure Portal Console for my App Service app to browse a bit and to my amazement, nothing seemed to have reflected at all. The FTP shows one thing and the Console shows another.
Would anyone have any idea as to why this is happening?
I eventually got it to work and I will share what I tried.
I deleted the web app and created it again (I found this to be important the first time around). This was quite time consuming and did help but it wasn't long before the same problem happened again.
Then I finally found a solution that seems to give me consistent results:
I kept on editing the Web.config which seems to force a recompile and clear some sort of cache. So each time the web app stopped updating, I would make a slight change in the Web.config, upload it via FTP and the app finally updates.
If anyone has any more details on this, it would be greatly appreciated.
I have a standard Azure build -- one web role, one worker role. After the latest merge, it has decided that the roles are invalid. When I double click on the web role or worker role, or when I right click and choose "Properties", I get a grey screen saying "Invalid service definition or service configuration. Please see the Error List for more details". However, there is nothing at all in the Error List.
I have cross-compared the Settings elements and tried commenting out sections of the csdef and cscfg files, but nothing seems to bring the roles back to life. I have wasted half a day on this already. My question is not so much "What is wrong" -- more like, how on Earth are you supposed to find out what the error is when no information is given and successive blanking out of code draws a comprehensive blank?
I've run across this a couple of times (VS 2015 Enterprise). Simply closing and re-opening the solution resolved the issue.
In this case, nothing was wrong with the csdef and cscfg files. It was the way the wadcfgx files were linked to the roles.
I'm on a branch that is using Azure 2.5; the other branch is on a previous version of Azure, that uses the older version of diagnostics. By deleting the existing wadcfgx files and re-generating them, I was able to make the roles visible and editable again. Having different versions on different branches does, of course, open a very large can of worms, but we're stuck with that difficult situation for the time being.
Check if the VM Size specified in the configuration is Small or Extra Small as it doesn't support more than that on local emulator. In my case it was defaulted to Standard Size VM. I changed the size to Extra Small and it started working fine!
I just ran into this after adding a new Worker Role project to an existing cloud service with a few existing Worker Roles.
In my ServiceConfiguration.Cloud.cscfg, I had a <NetworkConfiguration> tag in between the old roles and the new role. This was the problem. I simply moved the <NetworkConfiguration> tag to the bottom as it was before (this tag is not in my ServiceConfiguration.Local.cscfg file, which might've been the problem).
Probably not the most common cause of this problem, but figured I'd post on the off chance someone has similar settings.
I 've found out that Azure websites (trial version) doesn't autostart my node sever process (it starts only when I load the url in the web browser); and that when there are no requests in a while, the process is killed.
I mean, when I git push my server, I would like it to start running immediately and continuously.
I read (here, for example) that this might have to do with the way iisnode manages azure websites, and that I can't do anything to change it. Is this the actual way Azure websites work? Is there any way I can deal with this?
Thanks in advance,
Bruno.
You've find the answer. There is no other answer.
The process termination because of inactivity comes from IIS - there is Idle Timeout setting. Which to my knowledge is not configurable in Azure Web Sites (at least not Free tier). Check out also this SO question and its answer to get better understanding on why you can't change this timeout on the FREE and STANDARD tiers.
And here is an interesting workaround to avoid this idle timeout. Actually if you use technique, you will also have kind-of "auto start", in terms that when your scheduler hits your site after a new deployment, it will "boot up".
This can get a little complicated, but if you don't want to use their 5-min ping service, you can keep these always on by doing the following:
Create an app setting on your website configuration tab within the portal:
WEBSITE_PRIVATE_EXTENSIONS and give it a value of 1
Create a text file named applicationhost.xdt and populate it with:
<?xml version="1.0"?><configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"><system.applicationHost><applicationPools><add name="DefaultAppPool" managedRuntimeVersion="v4.5" startMode="AlwaysRunning"><processModel identityType="ApplicationPoolIdentity" /></add></applicationPools></system.applicationHost></configuration>
ftp into your website and create a folder on the root directory called Site Extensions. (there should now be 3 folders in your root: LogFiles, site, & SiteExtensions)
Create another folder within 'Site Extensions', named ASPLimits
Upload the applicationhost.xdt into the ASPLimits folder
Restart your website using the portal
I'm currently working on an Azure project that works 100% locally with emulator resources. I'm now trying to deploy a worker role, but I'm running into an issue that I'm not sure how to troubleshoot.
Upon deploying the worker role in my Azure portal, the two instances continually loop through "recycling".
I can try to RDP into the role, but I only have about a minute to look around before the connection closes, I'm assuming due to the recycling.
After some searching it doesn't seem like this is a super common problem. Is there something trivial I'm overlooking that could be causing this issue? How would you go about troubleshooting this? Thank you for your time :)
In case of missing Reference you can troubleshoot this issue by:
Unzip your CSPKG file and then again unzip .CSSX file (just rename CSSX to zip) and match that everything references and static content is all there.. This way you can match what is on VM. Also in 2 minute windows when you RDP, try to look for Application event log for exception and get it because that would be the key to find the root cause.
IF you could see the exception in event log and look for the exception, you sure can find where it was generated. You can also use Intellitrace which might require you to redeploy the app.
Also there are ways were copying WinDBG and locking to the specific process you can debug it. I am not sure how much you would want to try but just copy the WinDBG to VM and use it would be enough (not sure how much experience you have with WinDBG though and how much time you would want to spent.)
Also been pestered by this role recycle issue numerous times. Here is the sequence of steps to debug persistent role recycles:
Debugging Azure Role Recycles
Enable Remote Access to your role - RDP login
Check eventvwr.msc (Windows Logs -> Application, App & Service Logs->Windows Azure)
Review the Azure text file logs across both C:\logs and c:\resources
Review custom logs in the Volume E: or F: for any custom role startup logging
Run AzureTools and attach to startup processes (download WinDBG, use Utils->Attach Debugger, select process - WaWorkerHost/WaIISHost, etc), use G to continue and watch debugger output for assemblies failing to load.
Installing Azure Debugging Tools via Powershell
PS> md c:\tools; Import-Module bitstransfer; Start-BitsTransfer http://dsazure.blob.core.windows.net/azuretools/AzureTools.exe c:\tools\AzureTools.exe; c:\tools\AzureTools.exe
If all items above fail - try using other tools in the AzureTools treasure trove - such as fusion logging, etc, this approach above will work!
WinDBG Sample Output - Failing to Locate Assembly (WaIISHost)
The most likely cause is that you have a missing assembly. One tactic to catch this is to wrap any startup processing in a master try/catch that manual logs the error to Azure storage.
If you added any referrences, check to make sure they're set to copylocal=true and that any external assets that were included in your service package were also set to be included.
From Avkash above:
Yes. this mean some issue in your Worker Role code is causing your Worker Role Host Process to crash.. If you look your fault stack you must see the function or the link from your code which generate this fault. IF you need help open a free Azure Support incident to Windows Azure Support team and they will help you.
Just a suggestion: Also Check the installable(if any)and any other references you use are 64bit.Azure VMs have 64bit OS. Once i was stuck up with this kind of problem due to 32/64 bit issues.
Are your worker roles exiting their work loop? A local recycle is very fast and you might not notice it, but spin-up time in the cloud can be long.
If the issue is caused by a startup batch file, I have stopped the loop by editing the batch file on the instance to include "exit /b 0" at the beginning. This will tell Azure that the startup was successful and you then have all the time you need to diagnose issues without the VM getting killed.
I just built a simple hello world windows azure service containing just one web role, I used visual studio 2008 and Windows azure tools for VS 1.2 I am pretty new to this and I have been trying to deploy an application all afternoon now. I'm in australia and deploying in the region Asia anywhere.
I have pretty much followed the info provided on MSDN and it says uploaded 95% then after about ten minutes the deployment disappears. I have tried using the old windows azure developer portal and 30minutes later I can not access the service and it's status is either busy or stopped.
I have the introductory offer for an extra small compute instance on the subscription I am deploying to. Can anyone with experience with windows azure elaborate on the subject of deploying apps and the status on my application, I am very keen to get into the platform and this issue has just about spoiled my weekend.
Most likely it is related to the UseDevelopmentStorage=true for a connection string. I have accidentally done this a couple of times myself and things just magically don't work and there is no explanation. Missing DLL's are usually a little harder to track down as the application may or may not start depending on where the failure happens. Trace logging and/or infrastructure logging is the best way to find out if the DLL is missing if you can get your application to run that far.
As pointed out already, the best place to start is making the simplest "Hello World!" you possibly can and start extending from there. Yes it will take you a while to make progress but the experiences you gain from this will be invaluable moving forward.
Two things to check before deployment
1. Change Roles' Connection Strings to point to Azure Storage instead of UseDevelopmentStorage
2. All References not belong to asp.net framework should be set to "Copy Local=True"
I would guess that the deployment is going successfully but that the role instances are not able to start. The most common causes of this are eithe referrences to development storage while deployed (UseDevelopmentStorage=true) or a referrence to an assembly with copylocal!=true.