Contents ofAzure worker role e:\approot folder disappearing on instance reboot

Question

When a Windows Azure worker role instance is rebooted from within the Azure portal, are the contents of the e:\approot folder deleted? I have an elevated startup task which checks for the existence of a file in this folder before adding some registry settings. This has worked in the past but is now failing because the file it expects to find is no longer there following a portal-induced reboot. If I perform a 'shutdown' command from within the startup task, the instance reboots but the contents of e:\approot are unaffected.

Answer 1

I don't believe the conent of e:\approot will "disappear". The original content I mean.

This is the location where your role code is located, so it is not being deleted in any way, otherwise your role will not work at all. It might be reinitiated on every reboot, however I really doubt that is true.

If you use startup task to check for something you manually add, I suggest that you use a Local Storage Resource. Keep anything that is not part of your original package deployment in a Local Resource. You have the option to keep the content of this folder(s) (or clean it) upon role "recycle".

If your startup task is checking for some contents of your role code/package to be there, I suggest that you implement some wait logic in the cmd/batch file you are using. And also mark the startup task as "background" type, so it does not block the instance startup. As I said, e:\approot cannot be empty, because this is where your code resides! The content might come there later, but for sure it will not stay empty.

Answer 2

Answer is that when the Reboot button is clicked on the Azure portal, the contents of the AppRoot folder are deleted and the package redeployed.

To test, deploy something (anything...) to an Azure instance. RDP onto the instance and create a file (test.txt) in the AppRoot folder (this will be on the E: or F: drive).

Click the Reboot button on the portal. Wait for restart, then RDP onto the instance again - test.txt no longer exists.

Note that if you RDP onto the instance and choose Restart from the Windows UI, then test.txt is not deleted.

Answer 3

As others have already said, the contents of the drive are not lost on reboot. What has most likely happened is that you are hardcoding "e:\approot" in your startup task. You should not do this. I would hazard a guess that when you reboot, the drive has moved to f:\ or some other drive. I have seen this quite a bit.

Instead, you should reference %ROLEROOT% environment variable. That will point to the correct drive and path (e.g. "%ROLEROOT%\AppRoot") on reboot regardless of where the drive actually gets moved to.

Answer 4

You can't count on local changes surviving (or not surviving) updates or restarts - changes may persist or may be lost.

Your code should be designed to account for that, period. You can store temporary data locally to resume faster, but that data persisting is not guaranteed, so you should have that data in some durable storage like SQL Azure or Azure Storage.

The behavior you see might be caused by installing software updates. I'm not sure that's how it works, but imagine Azure infrastructure decides to roll on Windows updates on some of your instances VMs. Installing updates can take long, so Azure will just stop your instance, then start another (already updated) clean VM and deploy and start your role instance there. If that happens all local changes will of course be lost - your instance will be started on a fresh clean VM and your current VM will be discarded. That's just a speculation, but I imagine it's quite realistic.