[Sugar-devel] activity instance directory
James Cameron
quozl at laptop.org
Thu Jan 21 00:24:29 EST 2016
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]quozl at 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]quozl at 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 at lists.sugarlabs.org
> >> > [5][7]http://lists.sugarlabs.org/listinfo/sugar-devel
> >> >
> >> > References:
> >> >
> >> > [1] mailto:[8]quozl at 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 at lists.sugarlabs.org
> >> > [5] [12]http://lists.sugarlabs.org/listinfo/sugar-devel
> >>
> >> > _______________________________________________
> >> > Sugar-devel mailing list
> >> > [13]Sugar-devel at 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 at 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:quozl at laptop.org
> >>[3] mailto:quozl at laptop.org
> >>[4] https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
> >>[5] http://quozl.netrek.org/
> >>[6] mailto:Sugar-devel at lists.sugarlabs.org
> >>[7] http://lists.sugarlabs.org/listinfo/sugar-devel
> >>[8] mailto:quozl at laptop.org
> >>[9] https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
> >>[10] http://quozl.netrek.org/
> >>[11] mailto:Sugar-devel at lists.sugarlabs.org
> >>[12] http://lists.sugarlabs.org/listinfo/sugar-devel
> >>[13] mailto:Sugar-devel at lists.sugarlabs.org
> >>[14] http://lists.sugarlabs.org/listinfo/sugar-devel
> >>[15] http://quozl.netrek.org/
> >>[16] mailto:Sugar-devel at lists.sugarlabs.org
> >>[17] http://lists.sugarlabs.org/listinfo/sugar-devel
> >>_______________________________________________
> >>Sugar-devel mailing list
> >>Sugar-devel at lists.sugarlabs.org
> >>http://lists.sugarlabs.org/listinfo/sugar-devel
> >
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
--
James Cameron
http://quozl.netrek.org/
More information about the Sugar-devel
mailing list