[Tfug] disk usage mystery..
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
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.
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:
> 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:
More information about the tfug