-
-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent /var/tmp/flatpak-cache from piling up #1119
Comments
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:
|
Ok, so 3) is not correct. What was dropped was partial download of individual files, not reuse of old staging directories for pull. |
@alexlarsson well redownloads of Firefox Nightly always start from scratch… |
@alexlarsson hehehehe. Sure, I’ll give you an update once it lands in Fedora. |
@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?). |
If the pull failed due to lack of free space error, it is not recommended to hold onto partial caches (in repo/tmp) which can leave the disk-space full. Low-level free disk space error reporing is not reliable so we alternatively check for free space using fstatfs(). Hence, we keep partial caches only if free space is above a certain threshold. flatpak#1119
If the pull failed due to lack of free space error, it is not recommended to hold onto partial caches (in repo/tmp) which can leave the disk-space full. Low-level free disk space error reporing is not reliable so we alternatively check for free space using fstatfs(). Hence, we keep partial caches only if free space is above a certain threshold. flatpak#1119
Could you provide us with a workaround in order to manually clean-up the /var/tmp/flatpak-cache* files? |
Workaround using systemd, based on these instructions: Create a .service file called clear_flatpak_cache.service in /lib/systemd/system with this config:
Run it once: Enable it to run on boot: 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. |
Ooh, at least check if the flatpak executable is running or you could run into nasty corruptions. |
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? |
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. |
I'd appreciate it if a developer could chime in. I'd like to know if this is being worked on or not? |
Mine is 60GB. Only detect it when getting out of disk space error then using |
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?
|
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 |
The equivalent on Debian is:
|
No one is clearing those directories so they pile up and can take a significant amount of disk space. Resolves: flatpak#1119 Signed-off-by: Alberto Garcia <berto@igalia.com>
No one is clearing those directories so they pile up and can take a significant amount of disk space. Resolves: #1119 Signed-off-by: Alberto Garcia <berto@igalia.com>
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. |
@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 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. |
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.) |
The flatpak system helper triggering age based cleanup on exit wouldn’t be a bad idea. |
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. |
If it cares about access time it should probably check the subdirs rather than the toplevel. Like |
No one is clearing those directories so they pile up and can take a significant amount of disk space. Resolves: flatpak#1119 Signed-off-by: Alberto Garcia <berto@igalia.com> (cherry picked from commit 14d735b)
It can swell to quite big sizes, which isn’t good for a low-maintenance system.
The text was updated successfully, but these errors were encountered: