I spent almost an entire work day debugging and hacking around the wrong permissions on the /data/data/com.mozilla.SUTAgentAndroid/files directory. This was owned by root not app_XX which caused sutagent to not be able to write sutagent.ini and update.info to the files directory. we should add this to the verify.py script and any other sanity checking scripts where we ensure we can write to a file/directory/filesystem.
(In reply to Joel Maher (:jmaher) from comment #0) > I spent almost an entire work day debugging and hacking around the wrong > permissions on the /data/data/com.mozilla.SUTAgentAndroid/files directory. > This was owned by root not app_XX which caused sutagent to not be able to > write sutagent.ini and update.info to the files directory. > > we should add this to the verify.py script and any other sanity checking > scripts where we ensure we can write to a file/directory/filesystem. Indeed, in fact I would argue there should be three tests to validate everything is as expected: 1. The directory exists. 2. You can push a file into said location. 3. You can pull the file back from said location. We want to make sure that not only is the directory not owned by root, but that it is owned by the correct user. The above would ensure this.
I love the concept of this bug, my concern is spending too much time in verify.py as it exists now, since it runs at least once on every tegra job, and at most twice (talos jobs). Is there a way to *check* this permission simply, and *fix* this permission simply? If not, is it likely we can do a Will's suggested checks without delaying running of the real test/job in a bad/annoying way? What actual dmSUT.* commands would have to be run to both verify and fix this? (Using the current -- old dmSUT we have on releng foopies) ---- OR ---- is this verify planned to be for SUTAgent itself, seperately.
we could just do this: test = 'foo' target = '/data/data/com.mozilla.SUTAgentAndroid/files/test.txt' dm.push(target, len(test), test) data = dm.pullFile(target) if data == test: #ok dm.removeFile(target) else: raise hell()
I haven't seen this since my initial panda board debugging. Are we interested in doing this?
(In reply to Joel Maher (:jmaher) from comment #4) > I haven't seen this since my initial panda board debugging. Are we > interested in doing this? I'm not positive about this, but my guess is that the work done in bug 795456 should make problems like these much easier to spot. Maybe we should just WONTFIX this for now and come back to it later if it still turns out to be a problem.
ok, this has not been seen on tegras and only for a single instance on the pandas.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.