On Thu, 30 Dec 2021 at 18:21, Fred <fred.fredex at gmail.com> wrote: > Is it safe to just remove files from /var/cache on a running system, or is > there a correct procedure for doing that? > > Mine has hit over 3 gigs, making it one of the larger directories in /, > which is running low on space. I've hit all the low-hanging fruit I can > find and now I come to things like /var/cache, and I don't know what to do > about such. > > 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! > > Fred > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos > -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren