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.
