Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Windows dart2js bots fill up C: drive - with IE auto crash recovery files. #17961

Closed
whesse opened this issue Apr 2, 2014 · 5 comments
Closed

Windows dart2js bots fill up C: drive - with IE auto crash recovery files. #17961

whesse opened this issue Apr 2, 2014 · 5 comments
Labels
area-infrastructure Use area-infrastructure for SDK infrastructure issues, like continuous integration bot changes. browser-ie os-windows P3 A lower priority bug or feature request type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@whesse
Copy link
Member

whesse commented Apr 2, 2014

The dart2js-full-windows slaves are running out of space on the C: drive because crashes of IE leave a copy of the open tab information for IE's automatic crash recovery.

The directory C:\Users\chrome-bot\AppData\Local\Microsoft\Internet Explorer\Recovery\Active (or High\Active) contains tens of thousands of these files, some of which are > 1 MB.

We discovered this on vm195-m3, because for some reason it has a 45 GB C drive, instead of the 60 GB C drive on the other slaves.

Automatic crash recovery can be disabled in the IE options, but it still writes these files to the directory. The only way I found on the Internet to stop this is to use ACLs to make the directory unwritable:

icacls "%UserProfile%\AppData\Local\Microsoft\Internet Explorer\Recovery" /deny *S-1-1-0:(OI)(WD,AD) /t

http://social.technet.microsoft.com/Forums/ie/en-US/370124c3-3ae2-40b1-85d3-64f3d9a89df3/delete-internet-explorer-recovery-dat-files?forum=ieitprocurrentver

I'm currently deleting these files, which should give us about 3 months before it happens again.
@ricowind
Copy link
Contributor

ricowind commented Apr 2, 2014

Can we just clean this out in our annotated steps?

@ricowind
Copy link
Contributor

ricowind commented Apr 2, 2014

Actually, you could even clear it out in the browser controller

@whesse
Copy link
Member Author

whesse commented Apr 2, 2014

I'm not sure that we want the browser controller to touch the IE cache of anyone who runs it, in this way. We could clean it in annotated steps, but the ACL change seems to work, and is more exactly what we want on the buildbots. Do we have any buildbot setup scripts, or is everything in the buildbot scripts, so that it runs on every run of the slave?

@ricowind
Copy link
Contributor

ricowind commented Apr 2, 2014

I totally agree that you don't want to just delete peoples caches, but the most obvious place to put functionality like this is in the browser browser controller.
You can see how we solved this for safari - you can reuse the flag

@whesse whesse added Type-Defect P3 A lower priority bug or feature request area-infrastructure Use area-infrastructure for SDK infrastructure issues, like continuous integration bot changes. os-windows browser-ie labels Apr 2, 2014
@kevmoo kevmoo added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed triaged labels Mar 1, 2016
@bkonyi
Copy link
Contributor

bkonyi commented Jun 28, 2018

Is this still an issue @whesse? Assuming it isn't for now, feel free to reopen.

@bkonyi bkonyi closed this as completed Jun 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area-infrastructure Use area-infrastructure for SDK infrastructure issues, like continuous integration bot changes. browser-ie os-windows P3 A lower priority bug or feature request type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kevmoo @whesse @ricowind @bkonyi