Thanks, I await your testing of my pull request. On Thu, Jan 21, 2016 at 07:13:47AM +0200, Tony Anderson wrote: > Hi, James > > It would seem the correct solution is to have Sugar implement > the procedure specified in the 'low level activity'. The instance folder > should be cleared when the activity quits. If an activity needs longer > persistence, it can put the file in the data folder and then manage it. > > The issue is storage. An XO-1 has 1GB total. When the available storage > falls below 50MB, the "Journal is Full" modal dialog is shown (a non > sequitor since the > Journal may not be the culprit). Sugar provides no tools to the user to > determine the cause of the problem or to deal with it. In my experience, > deployments reflash losing all Journal data. > > Tony > > On 01/21/2016 02:19 AM, James Cameron wrote: > >We can't know what is wrong, because the logs aren't available, but my > >guess is one or more downloads were started, and the total for the day > >reached 1.2 Gb. That's all it takes. > > > >Downloads in progress are invisible to a user of Browse, so it is an > >easy mistake to make. > > > >For data shared between instances, we must use the data directory, not > >the instance or tmp directories, so any activity that does as you say > >must be fixed. > > > >I've done some tests. > > > >During download, instance directory has a file .goutputstream-* which > >will be cleared by _cleanup_temp_files in webactivity.py if Browse is > >started the day after the files were modified. Browse does not remove > >these files on the day. The code you refer to is only used when > >Browse is still running, and only for the destination path files, not > >the gio files referred to in #3973. > > > >Browse correctly uses data directory for places.db and gecko > >certificates and cookies. > > > >So the scenario that Tony describes is likely to cause the problem. > > > >Also, it won't be fixed by stopping and starting Browse. > > > >But it will be fixed by my patch in combination with stopping and > >starting Browse. > > > >On Wed, Jan 20, 2016 at 09:47:37AM -0300, Gonzalo Odiard wrote: > >>A few issues: > >>* Browse already have a mechanism to remove the temporary downloaded files, > >>we need to know what is wrong [1]. > >>* Temporary directories are shared between instances, if we remove temporary > >>directories > >>at activity start or stop, we need check if there are other instances of the > >>activity running. > >> > >>Gonzalo > >> > >>[1] [1]https://github.com/sugarlabs/browse-activity/blob/master/ > >>downloadmanager.py#L289 > >> > >>On Wed, Jan 20, 2016 at 6:38 AM, James Cameron <[2]qu...@laptop.org> wrote: > >> > >> G'day Sam, > >> > >> The pull request I've made will handle a preserved .sugar directory on > >> upgrade by deleting the directories the next time an activity is > >> started, as well as when an activity is closed or crashes. > >> > >> Implemented in the shell, or sugar-launch, or activity to activity > >> start, on behalf of the activity being started. > >> > >> That's option 2 and 4 from my previous post. > >> > >> Are there any activities that improperly depend on retaining data in > >> these directories? > >> On Wed, Jan 20, 2016 at 08:23:33PM +1100, Sam P. wrote: > >> > Thanks for the good analysis James! > >> > > >> > I don't think that deleting on startup is an optimal idea. It is > >> > counter-intuitive that the user must open every activity on their > >> computer when > >> > they want to reclaim space. It is also bad in the case of > >> infrequently > >> used > >> > activities. > >> > > >> > I think that a multi-pronged approach would be better. As you > >> noted, the > >> > activity clearing their tmp and instance folders themselves is > >> optimal > >> (option > >> > 3). I agree with this, as it takes load out of the shell process and > >> means > >> > that the filesystem space is reclaimed a quick as possible. > >> > > >> > However, to deal with the issue of crashing or non-sugar3 > >> activities, we > >> could > >> > also delete ALL tmp and instance folders during the shutdown process > >> (after > >> > stopping all activities is successful). In the best case, this > >> should be > >> as > >> > quick as running ls on all of the folders (which is quick right?). > >> It > >> also > >> > helps users who are upgrading their system and preserving their > >> .sugar > >> > directory. The shell does also not need to be responsive during > >> shutdown. > >> > > >> > Thanks, > >> > Sam > >> > > >> > On Wed, Jan 20, 2016 at 1:50 PM, James Cameron > >> <[1][3]qu...@laptop.org> > >> wrote: > >> > > >> > The API documentation was wrong, and has been edited. > >> > > >> > [2][4]https://wiki.sugarlabs.org/go/Development_Team/ > >> Low-level_Activity_API > >> > > >> > Rainbow did delete instance and tmp. Sugar did not. > >> > > >> > Rainbow has not been in OLPC OS for some time. > >> (/etc/olpc-security > >> > must exist, /usr/bin/rainbow-run must be executable). > >> > > >> > Rainbow is not in other builds that use Sugar. > >> > > >> > Sugar activities that were coded for Rainbow, and against this > >> > documentation, will leave an instance and tmp directory on the > >> > system. Every activity. > >> > > >> > Sugar must delete both directories. > >> > > >> > The next question is when? > >> > > >> > 0. on reinstall of OLPC OS, or reboot of SoaS, > >> > > >> > This is what we do at the moment. > >> > > >> > 1. on Sugar start, > >> > > >> > cleanup_temporary_files in sugar:src/jarabe/main.py might be > >> extended, > >> > so that Sugar starts up and deletes the directories. > >> > > >> > Disadvantage is a small delay during Sugar start, the need to > >> iterate > >> > over the bundle ids, and which list of bundles to use. > >> > > >> > 2. on activity start, > >> > > >> > The activity factory module function get_environment() in > >> > sugar-toolkit-gtk3:src/sugar3/activity/activityfactory.py > >> > might be extended to delete first, before making the directories. > >> > > >> > Disadvantage is a small delay during activity start. > >> > > >> > 3. on activity close > >> > > >> > In the Activity class method _complete_close() in > >> > src/sugar3/activity/activity.py we might delete the directories > >> as > >> the > >> > activity is closing. > >> > > >> > Disadvantage is that an activity that crashes won't delete the > >> > directories. > >> > > >> > Advantage is that any waste will be cleaned as soon as possible. > >> > > >> > 4. on activity close in shell > >> > > >> > Disadvantage is that Sugar may be momentarily unresponsive when > >> an > >> > activity closes or crashes. > >> > > >> > Can we work toward a consensus? > >> > > >> > My preference is on activity start, since that is the last time > >> it > >> > must be done to be consistent with the design intent. Are you > >> > registered on github? > >> > > >> > On Tue, Jan 19, 2016 at 01:47:23AM +0200, Tony Anderson wrote: > >> > > At a workshop I am giving in Rwanda, an XO got 'Journal Full'. > >> It > >> > > turns out that the Browse instance folder was using 1.2GB of > >> store. > >> > > > >> > > The low-level API says: > >> > > > >> > > $SUGAR_ACTIVITY_ROOT/instance/ > >> > > This directory is used similar to a /var/tmp directory, > >> being > >> > > backed by flash rather than by RAM. It is unique per instance. > >> It > >> is > >> > > used for transfer to and from the datastore (see keeping and > >> > > resuming). This directory is deleted when the activity exits > >> > > (specifically, as soon as all children of the activity's first > >> > > process die) > >> > > > >> > > However, apparently in 0.106 this directory is not being > >> deleted. > >> > > > >> > > Tony > >> > > >> > -- > >> > James Cameron > >> > [3][5]http://quozl.netrek.org/ > >> > _______________________________________________ > >> > Sugar-devel mailing list > >> > [4][6]Sugar-devel@lists.sugarlabs.org > >> > [5][7]http://lists.sugarlabs.org/listinfo/sugar-devel > >> > > >> > References: > >> > > >> > [1] mailto:[8]qu...@laptop.org > >> > [2] [9]https://wiki.sugarlabs.org/go/Development_Team/ > >> Low-level_Activity_API > >> > [3] [10]http://quozl.netrek.org/ > >> > [4] mailto:[11]Sugar-devel@lists.sugarlabs.org > >> > [5] [12]http://lists.sugarlabs.org/listinfo/sugar-devel > >> > >> > _______________________________________________ > >> > Sugar-devel mailing list > >> > [13]Sugar-devel@lists.sugarlabs.org > >> > [14]http://lists.sugarlabs.org/listinfo/sugar-devel > >> > >> -- > >> James Cameron > >> [15]http://quozl.netrek.org/ > >> _______________________________________________ > >> Sugar-devel mailing list > >> [16]Sugar-devel@lists.sugarlabs.org > >> [17]http://lists.sugarlabs.org/listinfo/sugar-devel > >> > >>-- > >>Gonzalo Odiard > >> > >>References: > >> > >>[1] > >>https://github.com/sugarlabs/browse-activity/blob/master/downloadmanager.py#L289 > >>[2] mailto:qu...@laptop.org > >>[3] mailto:qu...@laptop.org > >>[4] https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API > >>[5] http://quozl.netrek.org/ > >>[6] mailto:Sugar-devel@lists.sugarlabs.org > >>[7] http://lists.sugarlabs.org/listinfo/sugar-devel > >>[8] mailto:qu...@laptop.org > >>[9] https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API > >>[10] http://quozl.netrek.org/ > >>[11] mailto:Sugar-devel@lists.sugarlabs.org > >>[12] http://lists.sugarlabs.org/listinfo/sugar-devel > >>[13] mailto:Sugar-devel@lists.sugarlabs.org > >>[14] http://lists.sugarlabs.org/listinfo/sugar-devel > >>[15] http://quozl.netrek.org/ > >>[16] mailto:Sugar-devel@lists.sugarlabs.org > >>[17] http://lists.sugarlabs.org/listinfo/sugar-devel > >>_______________________________________________ > >>Sugar-devel mailing list > >>Sugar-devel@lists.sugarlabs.org > >>http://lists.sugarlabs.org/listinfo/sugar-devel > > > > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel
-- James Cameron http://quozl.netrek.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel