12 thoughts on - How To Clear Out /var/cache?

• The FHS specification says that applications using /var/cache should expect those data to disappear anytime, so under a strict interpretation it should be safe to remove everything. Practically, though, I don’t know that I’d trust every application to adhere to that, so it might be worth looking at what applications are the biggest users of the directory and making targeted deletions or even application-specific tools to remove the data
  (i.e. “yum clean all”).

• –Have you run KDirStat to find the disk pigs? I regularly use its Windows derivative, WinDirStat.

  <http://kdirstat.sourceforge.net/>
  <https://windirstat.net/>

  I wish there was a web-based version for headless servers without X
  libraries.

• Skylar: that’s more or less what I’ve been doing, looking for huge things in /.

  Kenneth: the latest version of kdirstat appears to now be named qdirstat, no kde bits required. it is certainly a handy way to quickly find the disk space sinks. Thanks for the pointer.

  but I still don’t know the proper way to clear out a lot of this stuff. I
  certainly don’t want to hose my system.

  It is C7, up to date, and it has been running for at least five years with partitions as they are set now: / is 50 gigs. had a popup message this morning telling me that / was nearly full. found it with 2 gigs free. sounds as if something has been slowly eating away at the space. I could use gparted to rearrange things, making / bigger, but as it has been going for five years, it strikes me that it more likely needs a lot of garbage collection to be done. I’ve manually cleaned up some detritus, it now reports 3.7G free which should hold me for a little while.

  So, can anyone advise me on what is and what is not safe to whack/delete from the root partition?

  Thanks!

  Fred

• My next step, on finding a candidate pig, would be to use “rpm -qf” to identify which package owns the pig, and then look at how to clean that package’s junk and reduce its growth.

• Il Ven 31 Dic 2021, 03:39 Fred ha scritto:
  [snip]

  If you go into /var/cache and run du -sh *
  you should see which subdirectories take more space and so on going through their subdirectories… to pinpoint the main specific component responsible of the space occupation..

  With the * in the command above you don’t catch elements (files or directories) beginning with a . but I don’t think there are normally this kind of objects… Just in case you can run a ll -a to be sure of that.. Hih, Gianluca

• It almost always filled up with leftover cruft from yum… Run “yum clean all” should clear up a large chunk of your space.

  Jim

• The first step is to find out what is using it. It is probably dnf but could be other utilities which are trying and failing to do something. I
  start off with

  “`
  $ sudo -i
  # cd /var/cache
  # du -sch | sort -h
  0 ./PackageKit
  0 ./app-info
  0 ./bpf
  0 ./fwupd
  0 ./httpd
  0 ./krb5rcache
  0 ./libX11
  0 ./libvirt
  0 ./private
  0 ./realmd
  36K ./ldconfig
  1.7M ./man
  29M ./dnf
  31M total

  while on a different system:
  4.0K ./abrt-di
  4.0K ./bpf
  4.0K ./foomatic
  4.0K ./krb5rcache
  4.0K ./private
  4.0K ./realmd
  8.0K ./httpd
  8.0K ./libX11
  8.0K ./powertop
  96K ./ldconfig
  300K ./ibus
  520K ./libvirt
  3.5M ./man
  4.2M ./fwupd
  38M ./app-info
  59M ./cups
  213M ./PackageKit
  332M ./dnf
  2.1G ./mock
  2.7G total

  “`

  As others have noted, dnf is probably the most used tool here, but it could be mock or some other utility (I had cups because I misconfigured something once)

  dnf is a tricky tool because sometimes a command will create a
  ‘not-so-temporary’ cached tree which can’t be cleaned because `dnf clean all` doesn’t know it. What I do is a `dnf clean all` and then go into
  /var/cache/dnf and see what else might be still there. In my case I found a large trove of packages from when I had enabled testing at one point and then turned it off before doing a clean. I normally just delete all the directories and do a `dnf update` to see if it reports errors.

  Hope this helps.

  Thanks in advance!

• well, I removed all the files in the tree under /var/cache/yum/x86_64/7 but left all the directories empty. that got rid of a couple gigs of stuff.

  among the remains, the only other big one remaining is:

  2.3G abrt-di

  which I won’t mess with for now.

  I’ve got 4.2G free, now, so that should run me for quite a while.

  Thanks to all of you for your tips!

  Fred

• –That directory is owned by the abrt-addon-ccpp package, which is involved with crash dump analysis. So I’d guess it’s full of dumps from programs that crashed.

• For the record .. I remove things manually from /var/cache/yum/ all the time (or /var/cache/dnf/ ). It has never caused me any issues.

  I have not removed anything else manually from /var/cache/

• +1

  Valeri

  —
  ++++++++++++++++++++++++++++++++++++++++
  Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
  ++++++++++++++++++++++++++++++++++++++++

• I regularly run “yum clean all” as yum tends to cache lots of stuff which isn’t really necessary once you have done your patching.

  Michael Lightfoot Delivery Engineer Sliced Tech Canberra, Australia

  —–Original Message—