With automatic snapshots feature landed and to be released with 2.39, snapd now creates a snapshot of the snap data and configuration automatically on snap remove and keeps it around for 31 days by default. It has been observed that because of that some snaps are now slow to remove if they create lots of data (one example is multipass snap, with 2GB+ of data).
While the feature can be disabled with snap set core snapshots.automatic.retention=no, it acts as a global flag. Therefore after a short discussion about the issue it has been proposed that remove command grows a new flag that disables automatic snapshot when removing the given snap only, e.g:
snap remove --purge myfatsnap
Any thoughs/suggestions about the new flag are welcome and if there is no disagreement, Iāll implement it soon.
Thanks for this, I was just about to ask for just such a thing. The snap remove now takes too long for my tastes due to it creating a snapshot for the data.
One quick comment on this older item. Is this behaviour in the documents? I went searching for this as someone pointed out that a user would never know this behavior by default.
EDIT Found it. In the snapshot portion of the docs. I think itās pretty deep in there for an average user though.
Edit 2 Iām taking a Mulligan on this one. It is in the getting started guide as well
Thanks for flagging this (cc @bashfulrobot). Itās an option that should definitely be more discoverable. Iāve added it to the Getting started guide, and Iāve also added some hopefully better navigation on that page to help see what information it includes. Iāll add some quick details on snapshots too.
No problem. It just came up as I was having a friendly discussion with a user who tends to be a little negative towards the tech.
I would suggest that things that are critical to a users data may even warrant some visibility within the cli tool --help command. Maybe even under the āremoveā button in gnome software.
The reality is, there are users who will not go search out the docs, or maybe even be a new user to Linux who may not realise where to go and look. So putting the data sensitive info into a spot that is maybe a little more intuitive - could be a good thing? ĀÆ_(ć)_/ĀÆ
I know that might be a stretch goal, or require other teams, but I am just spit-balling here.
Incidentally, the cli (snap remove --help) was updated just a few days ago with https://github.com/snapcore/snapd/pull/8782 (will become available with snapd 2.46 I suppose).
Btw, I couldnāt remove lxd at all due to this automatic snapshot thing. It tried to do something for several hours and then failed. Iām glad Google took me here and --purge was an acceptable solution to a problem that shouldnāt exist.
Right, there are some extreme cases (lxd, multipassā¦) where it would probably make sense to ask/warn about potentially huge snapshot (not doing automatic snapshots by default because of extreme cases isnāt a good idea IMHO; for users wanting that there is always āsnapshots.automatic.retention=noā config option mentioned earlier).
FWTW, there are some other improvements in the works such as not attempting an automatic snapshot if disk space is low and doesnāt guarantee successful operation.
this snapshot feature is a horrible thing, on servers this is ok (probably, but maybe not, what if it contains terrabytes of BLOBs or something) but for common users it is nightmare!
I in UI just clicked remove for Steam app and it just hangs forever, tried aborting it - nothing!
And about hour or two of my struggle led me here where I learned that when I remove an app it creates backup for it - seriously? - I want it to be removed! just removed! NOT TO CREATE A SNAPSHOT OF ABOUT HALF OF TERRABYTE!!! F*ck That is exactly why Linux has the reputation of being hard! No regard of user experience, I should not figure out all the internals of how things work - I have enough of that when I am at work.
Agree with soltysss. This is bizarre, unexpected, and unwanted behaviour. Tried to remove the docker snap, and was taking forever. Cancelling and using --purge worked, but probably shouldnāt be necessary?
I have never expected removing software to create some kind of snapshot or backup, interested in where the idea came up that this is required? Is it because snaps are possibly (erroneously) saving user data inside the snap, and you donāt want to accidentally blast that?
Snaps are saving user data in your homedir and in their dedicated writable directories under /var ā¦
If you take a look at how Debian packages work, they leave this content untouched if you remove and not purge a package, so of you re-install a package it will find all the old dataā¦ But this also means your disk will fill up over time if you do not generally purge on removal, so this is not different to any other packaging system out there.
Snaps simply keep a compressed backup of that data around to lower the footprint for that dataā¦ But the compression comes at a time cost for packages that have rather large amounts of data to compress like i.e. docker or lxd imagesā¦
You can list all backed up data with the snap saved command and there are multiple other commands around snapshots to deal with them.
Would you rather lose all your data when removing a package ?
so this is not different to any other packaging system out there.
I mean, itās different in that it takes seconds to sudo apt remove a package, and as other users said, potentially hours to sudo snap remove a package, so thereās thatā¦
Would you rather lose all your data when removing a package ?
I would expect that no user data would ever exist āinsideā the snap, and that the entire snap would be destroyed upon a remove command.
Nothing exists inside the snap beyond what has been originally installed, snaps are read-only filesystem images ā¦ like ISOs, nothing can save anything inside themā¦
The snapshots only happen for actual user data that was written to the two writable directories under /var that a snap owns or the snap/ directory in your home.
The same happened to me with thunderbird, only wanted to remove the package an it hangs for hours, since I have a lot of accounts to manage.
21GiB of data, which snap tried to compress. -_-
Since it was not possible to cancel, I had to kill it via shell.
What a mess!
anguschandler is completely right, apt for example does not do this!
Would you rather lose all your data when removing a package ?
No, when doing snap remove, I expect it to keep the data as is and doing nothing with it or at least ask if I want to compress the existing data!
Not simply starting compressing gigabytes of user data, without any way to prevent this or let the user decide if he wants the data to be compressed.
Or in case of soltysss compressing terabytes of games or gamedata.
Most traditional package managers such as APT (Debian/Ubuntu), DNF/YUM (Fedora/RHEL), or Pacman (Arch) have a different behavior:
APT: Retains configuration files by default, but does not automatically delete or compress them.
DNF/YUM: Similar behavior to APT.
Pacman: Normally removes all files, including configuration files, unless special options are used.
Flatpak, another modern package manager, has a similar sandboxing concept to Snap, but handles configuration data differently. It retains configuration data but does not automatically compress it.
AppImage is another format, but it has no central package management and therefore does not offer automatic handling of configuration data.
As far as I know, Snap is the only common Linux package manager that automatically compresses configuration data without prompting when a package is removed. This function is part of the Snap concept in order to be able to restore the configuration if the package is reinstalled later.
