Prevent /var/tmp/flatpak-cache from piling up

[jurf]

It can swell to quite big sizes, which isn’t good for a low-maintenance system.

[alexlarsson]

So, the way this works now is that we allocate a new /var/tmp/flatpak-cache* directory the first, time, but we also set a /run/user/$uid symlink to ti so we can find it again and reuse it the next time (until reboot obviously). This reuse allow us to implement restarting a download in case the first pull is partial.

Also, on success the data downloaded to tihs directory will be cleared.

There are three issues with this:

1. If we reboot, the data will never be cleared
2. If we fail, but don't retry, the data will never be cleared
3. I think in ostree mastert the reuse-old-partial-download feature was removed. If that is true, then the whole reuse thing is useless and we should drop the symlink, etc.

[alexlarsson]

Ok, so 3) is not correct. What was dropped was partial download of individual files, not reuse of old staging directories for pull.

[jurf]

@alexlarsson well redownloads of Firefox Nightly always start from scratch…

[alexlarsson]

@jurf Can you try latest flatpak (0.10.0), i fixed this embarrasing issue: ec8efa4

[jurf]

@alexlarsson hehehehe. Sure, I’ll give you an update once it lands in Fedora.

[jurf]

@alexlarsson ok, partial downloads work again in 0.10.0 (now updating the Firefox Flatpak is only almost impossible! :D). But the directories still pile up (at least the old ones weren’t deleted – maybe check their age on calling update?).

[stepnjump]

Could you provide us with a workaround in order to manually clean-up the /var/tmp/flatpak-cache* files?
I'm already up to 4 GB. Just can't determine which ones of them I can rm -rf and those I can't.... Or can they ALL be removed????

[ohgfj]

Workaround using systemd, based on these instructions:

Create a .service file called clear_flatpak_cache.service in /lib/systemd/system with this config:

[Unit]
Description=Flatpak cache clearer

[Service]
ExecStart=bash -c "! pgrep -x flatpak && rm -r /var/tmp/flatpak-cache-*"

[Install]
WantedBy=multi-user.target

Run it once:
sudo systemctl start clear_flatpak_cache

Enable it to run on boot:
sudo systemctl enable clear_flatpak_cache

This will clear any leftover flatpak cache directories on startup.

Edit: changed command to check that flatpak isn't running before deleting the flatpak cache directories.

[jurf]

Ooh, at least check if the flatpak executable is running or you could run into nasty corruptions.

[RalphCorderoy]

Over three years later, users who aren't even aware Flatpak is part of their system are puzzled by warnings about /var/tmp filling up when they think they've done nothing which should use more disk space. Does this project have labels or milestones which should be assigned to this issue so it doesn't languish?

[hanaral]

Not sure who is project lead, but GitHub says the top contrib is @alexlarsson , so could you please have a look at this? elementary OS wants to use the Flatpak system as the main packaging format. Since elementary targets casual users, issues like this have no ifs or buts.

[Nichtraucher]

I'd appreciate it if a developer could chime in. I'd like to know if this is being worked on or not?

[rEphEOn]

this is not cool. Nothing showed up after typing "flatpak list". Also, the cache didn't clean up after removing flatpak from apt.

[lephuongbg]

Mine is 60GB. Only detect it when getting out of disk space error then using ncdu to check for the culprit.

[bertogg]

systemd-tmpfiles allows removing directories at boot time (or after a certain time if they have not been used), wouldn't something like that be enough?

$ cat /etc/tmpfiles.d/flatpak.conf
R! /var/tmp/flatpak-cache-*

[fewaltix]

The problem still persists. My tmp-folder is at 40GB with five flatpak packages installed. This is really not ideal and should be quite easy to fix, even if it is a workaround like @bertogg's.

@bertogg's solution adapted for OpenSuse would be
$ sudo echo "R /var/lib/flatpak/repo/tmp/flatpak-cache-*" > /usr/lib/tmpfiles.d/flatpak.conf

[rpavlik]

The equivalent on Debian is:

echo "R! /var/tmp/flatpak-cache-*" | sudo tee /etc/tmpfiles.d/flatpak.conf

[RalphCorderoy]

I understand the 'fix' is to clear the cache on boot. This isn't sufficient when machines can have uptimes of over a year. A proper fix is still required, e.g. one which introduces pruning to the cache to keep it under a maximum configured size.

[TingPing]

@RalphCorderoy Can you elaborate why the directory is filling up for you?

It is only a staging directory for in-progress downloads. Once a download completes and is committed it gets deleted.

So in practice a user could use flatpak for a year and have no data there. On my system I had like 40 empty directories, annoying but not a problem.

They will only have data in them if an operation fails or is interrupted, after which you rerun the operation and it reuses that data.

If you find a problem please open a new issue.

[RalphCorderoy]

Hi @TingPing, if what you say is correct then I'm surprised earlier commentators had 40 GiB, 60 GiB, etc. cache directories. If it's only for in-progress downloads then could systemd clean files older than a week instead of waiting for a reboot?

(I don't have a problem today.)

[TingPing]

The flatpak system helper triggering age based cleanup on exit wouldn’t be a bad idea.

[bertogg]

If it's only for in-progress downloads then could systemd clean files older than a week instead of waiting for a reboot?

From what I understood (#5380) this is not working in this case.

To be clear: I didn't have time to test this scenario. I proposed cleaning the directories on reboot because it's a no-brainer solution and at least we should be doing that, but I'm of course open to additional improvements.

[TingPing]

From what I understood (#5380) this is not working in this case.

If it cares about access time it should probably check the subdirs rather than the toplevel. Like /var/tmp/flatpak-cache-AAAAAA/org.example.App/ might be stale.