Alt Text
A screenshot of a file manager preview window for my ~/.cache folder, which takes up 164.3 GiB and has 246,049 files and 15,126 folders. The folder was first created about 1.75 years ago with my system
You don’t have to clean your ~/.cache every now and then. You have to figure out which program eats so much space there, ensure that it is not misconfigured and file a bugreport.
So OP’s headline should be saying instead:
Reminder to CHECK your ~/.cache folder every now and thenCheck? Why?
% du -sh ~/.cache 1,6G /home/bizdelnick/.cacheI don’t remember if I ever cleaned it up. Probably a couple years ago when I moved my old HDD to new PC with freshly installed OS. It does not grow accidentally. Only in some very rare cases. As well as some other dirs under
~andvar. If it is a critical system, set up monitoring of free filesystem space. If not, you will notice if it becomes full (I can’t remember when this happened to me last time, maybe ~15 years ago when some log file started to grow because of endless error messages).Because some users experienced accidential grows like OP had 160 Gbyte. So general advice for linux users can be stated as: Check your ~/.cache every now and then
Critical systems/servers shall better be monitored as you suggest.
Some users experienced accidential growth of /var/log. Some users experienced accidential growth of /var/cache. Some users experienced accidential growth of /var/lib. Some users experienced accidential growth of ~/.xsession-errors. Shall I continue?
Does every user need to begin his day checking all that places? No, he does not. It is waste of time. Such situations are extremely rare. If you are paranoid, check
dfto see if you have enough free space, and only if it unpredictably shrinked begin to ivestigate which directory has grown.I don’t get your point. Why should somebody do this every day?
As the experience from other users in this thread, it seems not extremely rare to have an overgrown ~/.cache/ folder. So checking it from time to time is a good advice. If we all do this for a time, and create bug tickets for software which is not cleaning up. Then this problem will hopefully go away with future software releases.
Why should somebody do this every day?
Why should somebody do this ever?
As the experience from other users in this thread, it seems not extremely rare to have an overgrown ~/.cache/ folder.
It is the first thread about overgrown
~/.cachedirectory I see since I use Linux (~16 years or so). But, as I wrote above, this sometimes (rarely) happens with log files and some other directories. Checking each of them is a waste of time, if not automated, checking just one or few of them makes sense only if you are testing some app and looking for files it creates.
That’s not very cache money of you
Even better: mount ~/.cache as ramfs. It will also speed up some apps significantly.
I always felt that there should be some user directory like
/tmp/which will be wiped regularly./run/ contains such a directory
/tmp and /var/tmp are writable to regular users on most distributions
Because of excessive RAM I symlink
~/.cacheto/tmp. Additionally installingzramswaphelps for this scenario.Benefits are faster access, automatc purging between reboots and no wear to the NMVe drive.
Yes, this is a single user scenario.
Isn’t most of what’s in there just filters downloaded from the internet? Python packages, browser cache, etc? Your system confirms you to redownloading everything all the time, no?
This seems like a filename conflict waiting to happen. Why not just mount a tmpfs there?
Like I said it’s a cheap solution for a single user system. Ofc tmpfs would be better but has to be done for every user again
You: It’s a single user system
Also you: Tmpfs would have to be done for every userAnd a /tmp/ symlink would have to be created for every user too, so I don’t get your point
Tmpfs is just as easy as making a symlink, but without the filename conflicts between files in ~/.config/ and /tmp/. You just need to add a line to /etc/fstab
Once I get more than 16GB of ram I’ll definitely try that
I don’t think I’ve ever seen .cache get bigger than 10GB
It looks like yay was storing AUR build files there, that folder took up about 160 of the 164GiB
You can use
yay -Scto clean the cache. It’ll also ask you if you want to clean the pacman cache, which I’m assuming you also haven’t cleaned (check the size of/var/cache/pacman).One would just need to modify the pacman cache hook for yay. I’m too lazy tho.
If it is true, it is a bug in yay. Cashe should not grow without limit.
Your Distro should normally do that for you.
Advising for this means people will delete random cache and download stuff always.
Are multiple files in there? If yes you could add a script that only deletes files of certain age.
I’m not aware of any distro that automatically clears a user’s .cache in their home directories. Maybe you’re thinking of /var/cache?
No way. If i clean up my .cache directory my precious cached with sccache rust deps would be very upset. >:[
Question, could you have cron/crontab do it monthly or something? Do it monthly meaning delete everything in ~/.cache every month or so?
You could have a cronjob run something like
find /home/user/.cache -type f -atime +30 -delete, which would find files that haven’t been accessed in the last 30 days and delete them. Make sure your home partition is not mounted with thenoatimeoption though.Don’t. You don’t need to clean it unless cache of some buggy program grows uncontrollable.
I just found this today, I don’t really know anything about cron jobs but this will probably incentive me to learn lol
Did you happen to see which subdirectory was using up this much space? I don’t think I’ve ever seen .cache go above 10GB, so this may be a bug in a piece of software you use.
Running
ncduon it would’ve been cool to see.
Looks like yay is storing every previous binary for AUR bin packages (also excuse the unreadable terminal theme, it doesn’t play very well with a lot of TUI apps unless they support custom theming)
You should run
yay -Scfrom time to time. This cleans a) your pacman cache (which is normally done by executingpacman -Sc) b) your AUR build cache, which is what’s taking up 160GB. But this one seems rather unusual, I use paru (which also has the commandparu -Sc), so I can’t really tell if this is normal with yay.The command also asks you for every directory if you want to delete it or not, so it’s completely save to run that command.
Something I noticed was that it was mostly the binary packages that were taking up so much space, it may be because of how yay stores the programs (does it use git?), the ones that were compiled from source code usually took up the least amount of space, while the binary programs were the ones taking up tens of gigabytes
Indeed, yay utilizes the AUR, which essentially serves as a Git repository for each package. These repositories typically include a PKGBUILD file and a .SRCINFO file, along with possible additional files like patches, desktop, or service files.
For example, take a look at IntelliJ Ultimate: [https://aur.archlinux.org/cgit/aur.git/tree/?h=intellij-idea-ultimate-edition]. It contains the .SRCINFO and PKGBUILD, as well as a .desktop file. These files themselves do not occupy much space.
The PKGBUILD specifies the sources for dependencies. For instance:
source=("https://download.jetbrains.com/idea/ideaIU-$pkgver.tar.gz" "jetbrains-idea.desktop")The PKGBUILD is essentially a Bash script with predefined functions and variables. You can learn more about it here: [https://wiki.archlinux.org/title/PKGBUILD].
This script primarily downloads and extracts the tar file. In this specific case, it only relocates the files to their intended installation locations, like moving the desktop file to /usr/share/applications.
With such packages, there’s a possibility of wasting significant space since the tar file is downloaded and possibly retained in the cache.
However, other packages, especially those compiled from source, usually involve Git clones. These clones bring the Git repository into a subdirectory of the already cloned AUR package Git repo. Some might also have source tarballs. These types of packages generally do not consume much space in the cache, as they are often just text files, like C source code or Python scripts. These packages frequently rely on external libraries and packages, which are not included in this package’s cache.
While binary packages often bundle all necessary libraries and other components in their source tarballs.
The AUR cache is mostly beneficial if you’re rebuilding the same version or can reuse components from a previous version. For example, a package might depend on a large, static file that doesn’t change often.
In Paru, I’ve enabled the “CleanAfter” option to prevent my cache from overflowing. Given my relatively fast internet speed, redownloading large files isn’t a major concern for me.
Wow, I’ve never seen something like this.
Is it" allowed"? I mean, there are quotas for user homes.
Haven’t deleted it yet actually, looks like most of it is from yay
Just mount it into your RAM
You can also setup a cron job to periodically clean oldest files for you.
Example: @weekly find ~/.cache -type f -mtime +7 -delete
This will delete everything older than 7 days inside your cache folder.
I guess you could also Mount a tmpfs to that directory
seems like a bug in one of rhe programs you’re using.
modt software automatically manages it’s cache…
are you using build caching tools such as Mozilla sccache? These tend to create 20gb+ cache directories, especially if used with debug buildsdu -sh ~/.cache/* | sort -hncdu ~/.cache/
Bleachbit is good for clearing up some space
And deleting emails
Even Hillery knows that one.
Come on!
/s
Is it safe to clear
~/.cache/mozilla/while Firefox is running?No.
Maybe not while it’s running, but .cache is intended to be temporary files only so expecting files to permanently be there should be treated as a bug
I just map both the user cache and the /tmp directory to a RAM drive. I allocated 4 GB but in practice it never gets even close to that much, and Linux seems to not be reserving the entire 4 GB at boot so I would assume how much RAM is used depends on how much is actually in your cache.
It also defers cache and tempfile related problems to turning it off and on again.
This particular folder caches many things from various package managers. Won’t hurt to clear, but will fill up again. Maybe consider not using caches when engaging such things.
Package managers don’t use this directory as well as any other subdirectory of user’s home.
Could have fooled me, because it’s certainly the default for things like brew, flatpak, mpm, and pip. Looks like npm and maven use it on certain Debian based distros as well. I’m betting more of the immutable distros use that directory as well vs something in /var/cache.
Ah, sorry, I thought about system package managers like apt, dnf, zypper etc.
How?
Depends on the package manager. Check options for whatever you’re running.
