Alright, let me walk you through something I fiddled with recently – messing with the snap cache, specifically trying to figure out if I could schedule its cleanup. It wasn’t quite what I expected, to be honest.
Figuring Out the Space Hog
So, my machine started groaning about disk space. You know how it is. First thing I usually blame are logs or maybe downloads I forgot about. But this time, after poking around, I started suspecting snaps. I use a few of them, they’re convenient sometimes, but I’d heard they can leave stuff behind.
I did a quick check, something like digging into the /var/lib/snapd/ directory. Can’t recall the exact command, maybe `du`? Anyway, I saw a chunk of space being used. My first thought was “cache”. Everything caches stuff these days, right? So, I figured, there must be a cache I can clear out regularly.
Looking for the Magic Button
My immediate reaction was to find a command. Like snap clear-cache or something obvious. I opened up the terminal, typed snap --help, scrolled through the options. Nothing like a straightforward “clear cache” command popped out. That was the first surprise. I expected something simple.
I searched online a bit, saw people talking about snap cache, but it often led back to discussions about old versions of snaps being kept around. Not exactly a temporary cache like a browser might have.
The Real Culprit: Old Snap Versions
This is where it clicked. Snaps keep older versions installed. You update a snap, the old one sticks around for a bit just in case you need to roll back. Clever, maybe, but also space-consuming if you don’t watch it.
I found this command: snap list --all. And bam! There they were. Multiple versions of the same snap, listed with revision numbers, some marked as “disabled”.
- Checked which snaps had old versions.
- Saw how much space they might be taking up collectively.
You can apparently remove these old ones manually using their revision number, like sudo snap remove package_name --revision=123. Doing that one by one? No thanks. That’s tedious.
So, About That Schedule…
My original idea was to set up a schedule, maybe a cron job, to run a cache-clearing command weekly. Something like:
0 3 0 sudo snap clear-all-the-junk
But since there wasn’t a simple command like that, and the real issue seemed to be old revisions, the whole scheduling idea started to feel wrong.
Then I read more and found out that snapd actually handles this itself. It’s designed to automatically remove old revisions after a while. By default, it usually keeps the currently active one and one or two older ones. The system is supposed to manage this automatically. You can even control how many it keeps using a system setting (sudo snap set system *=N where N is the number, like 2 or 3).
What I Ended Up Doing
Honestly? Not much. Once I understood that snapd has its own internal schedule for cleaning up old versions, trying to force it with a manual cron job felt unnecessary, maybe even risky if I messed something up.
I checked my retention setting (I think the default is 2 or 3 versions). It seemed reasonable. The automatic cleanup was probably already happening.
So, my grand plan to create a “snap spotlight cache schedule” kind of fizzled out. It turned into more of a learning experience. Learned that the ‘cache’ issue was mostly about old package versions, and that the system is built to handle it. Sometimes the best solution is just letting the system do its thing.
I guess I just keep an eye on the snap list --all output occasionally if I get paranoid about disk space again. But no scheduled tasks for me on this one. Just wasn’t needed.
