Closed Bug 1494048 Opened 3 years ago Closed 3 years ago
Remove Mozilla directory in Program
Data from the test image
I am currently working on moving our update directory to C:\ProgramData\Mozilla (Bug 1458314). Unfortunately, when testing, this directory already exists and has permissions that prevent it from being written to or deleted by Firefox. I believe that this is a result of an old build of Firefox that used to use this directory. This directory needs to be removed from the image so that update tests can create and write to it.
Hey Kendall, any ideas who we would rout this work to? This is blocking some update work since it causes test failures.
:grenade, can you have a look? would be good to verify that nothing recent is in there, and know where it's being created if not in builds/tests.
Flags: needinfo?(klibby) → needinfo?(rthijssen)
We've confirmed this directory was an old Maintenance Service logging folder. We can blow this away or update the perms on it, whatever works best and simplest.
(In reply to Kendall Libby [:fubar] from comment #2) > :grenade, can you have a look? sure. > would be good to verify that nothing recent is in there, i ran this task to check the last modified date for the contents of this folder: https://tools.taskcluster.net/groups/Us-aXnVET6WYUPWoAXVVRg/tasks/Us-aXnVET6WYUPWoAXVVRg/runs/0/logs/public%2Flogs%2Flive.log the task shows that the folder contains a single log file whose last modified date coincides with the time of the ami creation. the log file is named: C:\ProgramData\Mozilla\logs\maintenanceservice-install.log, and it contains some messages indicating the service was successfully installed. > and know where it's being created if not in builds/tests. it's created by the installer for the mozilla maintenance service which we install during creation of the ami here: https://github.com/mozilla-releng/OpenCloudConfig/blob/fb0c0f3/userdata/Manifest/gecko-t-win10-64.json#L852-L875 i recall from around the time that we added this installation, that if the mozilla maintenance service is not installed, some tests fail. there is some context in bug 1067756. i don't know if it is still the case that the service is required, but we only added it to green up tests that were failing at the time that we migrated tests from buildbot to taskcluster. (In reply to Jim Mathies [:jimm] from comment #3) > We've confirmed this directory was an old Maintenance Service logging > folder. We can blow this away or update the perms on it, whatever works best > and simplest. if we want to blow it away, we'd have to do some validation test runs on staging workers to see if other tests start failing if we do so. my hunch is it will cause problems. if we just want to update the permissions, i think that should be a pretty harmless change and would look like the attached pr. if you want to go this route, just give me a heads up in the review and i will make it so.
Comment on attachment 9012047 [details] [review] GitHub Pull Request This looks good to me. Thanks for your help with this.
Attachment #9012047 - Flags: feedback?(ksteuber) → feedback+
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
on hardware the icacls command is failing after the first run. this does not occur on ec2 instances. perhaps we need a validation to check if the permissions have already been applied...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
problem in comment 7 turned out to be caused by the maintenance service installer being downloaded from github rather than tooltool. unsurprisingly, the call to github was returning the error message: "remote server returned an error: (429) Too Many Requests." i've updated the manifests with the sha512 hash for the artifact which causes occ to source the file from tooltool. https://github.com/mozilla-releng/OpenCloudConfig/commit/e9cfd9fec435b32792ad4398243f70d04a0c38e0
Status: REOPENED → RESOLVED
Closed: 3 years ago → 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.