trinity-users@lists.pearsoncomputing.net

Message: previous - next
Month: March 2018

Re: [trinity-users] my vanishing root partition

From: Nick Koretsky <nick_koretsky@...>
Date: Tue, 20 Mar 2018 06:31:52 +0200
On Mon, 19 Mar 2018 20:52:44 -0700
William Morder <doctor_contendo@...> wrote:

> 
> > > > Well, i mean does reboot reclaim that lost space? You see one of a
> > > > possible reason for a "vanished" space are open deleted files. If
> > > > some daemon misbehave with cache or imporper log rotations, etc...  
> > >
> > > It does reclaim some of the lost space, yes - hence one reason for
> > > rebooting, when I run out of space - but there is still a creeping
> > > issue of space disappearing in increments of a couple mb at a time.  
> >
> > Well, than you have two different issues at hand. Two deal with a space
> > that is reclaimed by reboot, run (when some space already gone)
> >   lsof -nP +L1
> > and look for anything suspicious here.   
> All entries are marked as deleted. I could give you the whole list, but
> it is very long, and besides I am trying not to give out my user name,
> and other specific details. Anything I ought to look for, if all items
> are already marked as deleted? 
> 

This command list "deleted" files which are not yet actually deleted, only
references to them  are removed. They are still opened by some program and
will use disk space until program closes them. Strictly speaking there
should be no such files at all, but bad programing practices and simple
errors exists, so actual situation is not as rosy. Browsers, especially
chrome, are notorious for this shit, but the files they used should mostly
be in /home or /run  Look for any files that are located on root in this
list. BTW, i have just run this command on my machine and palemoon have
are 80MB deleted file in /temp open.... as an example of possible things.


> > Also, if /tmp is on real disk (not 
> > tmpfs), it is also a primal suspect for a space that is reclaimed by
> > reboot.
> >  
> I did look in /tmp, but there is nothing much there; although the
> presence of a systemd entry does bother me - but maybe this is by design. 
> 
> > For an issue with a long term lost space, the only thing i cab suggest
> > it to setup a cron to run something like
> >  du -xcbd2 / > $(date +\%j%H)  
> 
> Running the cron job now. 
> 

Oops send previous without message without finishing. Accumulate output
from this cron job (at hourly interval) for a few days, than diff them to
pinpoint where and when directory sizes are growing.

-- 
  Nick Koretsky (nick.koretsky@...)