[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