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
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
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 try something like:
$HOME/.config/systemd/user/clean-user-cache.service
[Unit] Description=Clear cache After=network.target [Service] Type=oneshot ExecStart=/usr/bin/rm -r %h/.cache/* %h/.cache/.* [Install] WantedBy=default.target$HOME/.config/systemd/user/clean-user-cache.timer
[Unit] Description=Clear user's cache every month [Timer] # Runs on midnight on the first day of the month OnCalendar=monthly # Wait a random time between 0 and 10 minutes before invocation. This prevents your FS getting hammered if you deploy this script for multiple users that all log on after a reboot. RandomizedDelaySec=10min # Enable persistence to run the command even if the machine wasn't on at the time the timer was supposed to trigger Persistent=trueTo enable the monthly timer:
$ systemctl --user daemon-reload$ systemctl --user enable clean-user-cache.timerTo clean the cache once, right now:
$ systemctl --user start clean-user-cache.serviceTo see the output of the service (and past executions, if they happened recently):
$ journalctl --user -u clean-user-cache.serviceThis relies on a systemd user service (better not do
rms as root, just in case) so you need to log in for it to work. You could also use a system service withUser=andGroup=in case you’re removing the cache on a server you rarely ever log into.This is the good shit I miss from reddit. Thank you for posting a systemd service config, I’m going to implement this.
Thanks for this! I’ve been meaning to start getting into learning more about systemd and making services, this is super detailed and gives me a pretty good starting point!
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)
Wow, I’ve never seen something like this.
Is it" allowed"? I mean, there are quotas for user homes.
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.
Haven’t deleted it yet actually, looks like most of it is from yay
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.Just mount it into your RAM