[SOLVED] too many unsuccessful flatpak updates lingered in this directory. It sorted itself out after rebooting the system.
var capacity 11.1 GiB, var usage 10.6 GiB
why would var have such a restraint? reminds me of overly complex tutorials tricking people into elaborate partitioning schemes
/var is often where processes dump a lot of data (logs, databases, etc), and subpartitioning of /var sets a cap so that when too much data is dumped there, the application crashes instead of the whole system. /var/log is often recommended to be subpartitioned separately as well, so that logging can still go on if the application data fills up and crashes.
These kinds of overruns can be intentional DOS attacks, also, so the subpartitioning is often a security recommendation. NIST 800-171 requires separate partitions for /var, /var/log, /var/log/audit, and /var/tmp
apt-get cleanwill clear the apt cache and should give you enough temporary storage headroom on /var to do things, but if you’re bumping up on this limit often, you’ll need to reconfigure your storage.Uninstall all the flatpak packages that are installed as system wide packages and install them as user packages, that way flatpak will use your /home partition. I had the same problem.
du -hsc /varCheck the sheets to see which directories are taking up your space.
Usually var gets full of old log files. So maybe delete some of those. Apt-cache is also a suspect
Well, what’s using your /var?
You can use baobab or ncdu to try to figure out what’s filling it up.
dd if=/dev/zero of=/var
But really, remove what you don’t use and/or stop using flatpak.
Wouldn’t that just make a file full of zeros?
I think the proper (joke) command here would be
rm -rf /var/*
It would probably fail unless var was a block device actually. It wouldn’t turn a directory in to a file.
