Re: 100% [Waiting for headers]
On Sunday, June 24, 2012 05:52:16, lina wrote:
> On Sun, Jun 24, 2012 at 5:45 PM, Curt <curty@free.fr> wrote:
> > On 2012-06-24, lina <lina.lastname@gmail.com> wrote:
> >> Dselect reported me that my /var has saturated. Indeed, 100%.
> >>
> >> My question is that how to set to let me know earlier when the var
> >> reached 98%. Kinda of dangerous huh?
> >
> > My question would be why is /var being "saturated" in the first place.
>
> Ha ... I didn't realize I should have used aptitude autoclean before.
> Lots of .deb ball there.
>
> Dom guessed exactly right on another thread.
For those running Debian Stable boxes /var/cache/apt/archives/ only slowly
grows because upgrades are rare, so it generally takes several years for /var
to fill up, and this issue generally goes unnoticed.
However for those who run Debian Unstable, /var ends up filling up much, much
faster because instead of upgrades happening every two years, they happen
every single day, so /var tends to fill up in about ONE year. (Or at least
that's what my experience was.) Because of this I got into the habit of
running 'apt-get clean' after all package installs and upgrades, and there
turns out to be a downside to doing that.
It's convenient to be able to downgrade a newly broken package to a previous
version that's in the package cache. In aptitude this can be done by
highlighting a package and then pressing the 'v' key to show available
verisons of the package -- you can then press '+' on the previous version (if
there's a previous version still in the cache) and downgrade the package.
These options are only available if 'apt-get clean' has NOT been run, though
-- otherwise only the latest installed version is available.
So as a result it's best to run 'apt-get clean' occasionally rather than
constantly. :-P On Debian Stable where packages generally don't break it's
probably safe -- yet ironically it's on Debian Unstable where packages
occasionally do break is where one would want to clean out the package cache
most often.
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
Reply to: