[Tfug] disk usage mystery..

JD Rogers rogersjd at gmail.com
Tue Apr 3 13:55:37 MST 2012


John, nice find. Thanks for passing it along. I finally read through
those bug reports.

I'm still not sure if my issue is related because I don't have
anything of size in /tmp and /tmp is a tmpfs mount in ram anyway. I
even tried rebooting and "never opening a gnome terminal" until the
disk filled, so it doesn't seem to matter. Even weirder, the disk was
full a couple times in the past week and then suddenly my space
returned without restarting x and killing pulseaudio, so clearly
something can occasionally release the used space, but I haven't made
any progress in narrowing down what. In the last week, the disk usage
even hovers at 500MG for a day or so before suddenly spiking and
filling the remaining GB. Its almost like whatever is broken is slowly
healing. :-)

I'm tempted to give up, move on, and just wait another few months
until I buy a new laptop and then do a fresh install. But I'd love to
at least be able to track down the culprit and file a bug report.
Frustrating.

Hope you have better luck with CTRL-End.

On Sun, Mar 25, 2012 at 9:23 AM, John Gruenenfelder
<jetpackjohn at gmail.com> wrote:
> I've got an update for you that may help in tracking down the ultimate
> culprit of your file system filling bug...
>
> While scouring the Internet with Google to find a solution to the
> problem that libvte derived terminals (roxterm, gnome-terminal, etc.)
> are treating End and CTRL-End as the same key (End), I found a bug
> report stating that gnome-terminal (again, via libvte) was constantly
> writing to /tmp.  Remembering your plight, I took a look.
>
> Some of the suggestions in the following bug report threads may help:
>
> https://bugs.launchpad.net/ubuntu/+source/vte/+bug/865082
> https://bugzilla.gnome.org/show_bug.cgi?id=631685
>
> In short, one of the temp files libvte stores in /tmp contains the
> entire scroll-back buffer and it is writing to it constantly.  Like
> most transient temp files, it is opened for read/write access and then
> deleted from the file system (but remains open as long as the creating
> process is alive).  Given how much sensitive information can
> potentially be displayed in a terminal, I certainly hope they've got
> the security concerns nailed down.  As somebody who does not use a
> stupendously large buffer size, I naturally assumed that it was stored
> in RAM.  For that matter, even for a giant buffer I still would have
> assumed that it was kept in memory.
>
> Anyway, the second link above suggests a very useful way for
> monitoring file system access.  You can use the kernel's inotify
> system and a simple Python command to have all of this information
> streamed to a terminal or file:
>
>  python -mpyinotify /tmp
>
> You will need Python's inotify bindings (in Debian, this is the
> python-pyinotify package).  It's fairly easy to read and even
> colorized.  Obviously, don't run this in a terminal that will be
> hammering /tmp.  Regular xterm will work fine.  Similarly, if you dump
> the output to a file, make sure you are not storing that file in the
> same place you are monitoring.  By default, this seems to recursively
> monitor the path you specify.  I created some directories a couple of
> levels deep and touched a file inside and Python was still notifying
> me of the access.
>
> I hope this makes solving your problem a little easier.
>
>
> P.S. I still haven't found a solution to my End=CTRL-End problem with
> libvte.  It works fine with xterm, though.  I map CTRL-Home/End to
> jump to the beginning/end of a buffer in EMACS so it's not a show
> stopper, just annoying.  The devs are at least aware of it, via an
> Ubuntu bug report, but the last activity was a year and a half ago...
> :(
>
>
> --
> --John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
> Try Weasel Reader for Palm OS  --  http://weaselreader.org
> "This is the most fun I've had without being drenched in the blood
> of my enemies!"
>         --Sam of Sam & Max
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org



More information about the tfug mailing list