Add update manager for snapstore

When to wait for functionality for updating snap applications?

Reason for the importance of this task:

When updating snap programs automatically, especially if applications larger than 500mb and with a low connection speed are installed, the Internet is terribly slow and this takes a lot of time. I immediately did not even understand what was happening, since there were no notifications. This is very bad.

the snap really need an update management manager.

1 Like

What is missing with what’s on offer today? You can control the times during which things update, and the bandwidth they use to do so. What else?

To limit bandwidth used: snap set system refresh.rate-limit 100kB should limit it to 100kB/s.

To limit updates, for example to once a day every day, between 10pm and 6am on weekdays or any time during the weekend, snap set system refresh.timer mon-fri,22:00-6:00,,sat-sun.

There’s more info in

For desktop users, it’d certainly be nice to have an indicator which lets you know there are updates available, perhaps with options to defer for some specified time 1h / 8h / 1d / 1w. It could also have a ‘do now’ button. Perhaps a little blob which indicates green/yellow/red the state that there are no updates, some updates to do, or being processed.

Pretty simple stuff, but would give visibility to the user what’s going on.


agreed! that would be nice. It’d take a little bit of poking the api and some nice GUI work… and the latter is beyond my ken. Maybe @robert.ancell knows whether there are plans for this?

That’s what I’m talking about, I can configure everything as it should, but not everyone can figure it out, many people who came from windows don’t understand anything about this.

It would also be great to be able to check the list of available updates as it was before in ubuntu 16.04 in ubuntu software for debian packages. It was a very convenient thing, it is a pity that in 18.04 and later it stopped working.

1 Like

Back in the early discussions of snaps on desktop the idea was that updating would be somewhat hidden from the user. GNOME Software has a mechanism for showing updates, but we don’t have that connected for snaps and we’re not using that mechanism for updates in Ubuntu (using the existing update-manager instead). So if this was a feature we wanted it would be added to update-manager. @mpt do you have any thoughts on that?

Hidden from the user, this is certainly good, but it is not always convenient, for example situation that I described above. It seems to me that all the same, the gui of adjusting the behavior of updates to snap applications will be only a plus, including the setting to update in the background, ask or not update at all.

And one more question
what about your upcoming snap store not written based on gnome. will there be the ability to view updates? (as on andoid)

as a little sidenote for this discussion, a 500MB application will only download 500MB when it gets installed.

snaps update via binary deltas so you will always only get the changed bits, not the full app during an update … i.e. if the changes in an app make up 2MB your update is only 2MB, not more … along with the refresh-rate limit this should really not eat your bandwith …

True, I honestly also hoped for this functionality.
but the pc did not turn on for a long time, and when it started, it started to update, and I could not do anything but leave it for several hours. If at first there would be an update request as with deb packages, I would not have such a problem.

That’s quite a claim. What bug are you referring to?

Software Updater exists primarily because apt updates are deficient for PCs:

  1. Some updates require restarting the system, and some things may not work until you do.
  2. Things can break if a machine shuts down during an update.
  3. A complex app (like Firefox) might stop working properly if updated while it’s running.
  4. You can’t undo an update (because maintainer scripts can do anything).
  5. Updates are connection-insensitive — they don’t care whether you’re on a metered or slow connection (or even none at all, spewing errors rather than pausing).

For all these reasons, we need to prompt you explicitly to start updates, and let you opt out of individual updates if you’re doing something important in a particular app. (I assume Gnome Software’s Updates panel exists for similar reasons.)

Some of these reasons don’t apply to snaps:

  1. Snap updates never require restarting the system.
  2. Things don’t break if you shut down during a snap update.
  3. Snap apps don’t break if they’re running during an update (and eventually we’ll prompt you to relaunch if you’ve kept using an old version for ages).
  4. Still a problem: updates aren’t undoable (in the GUI, only in the CLI).
  5. Still a problem: updates aren’t connection-sensitive in practice — only in the CLI, only if you know about rate_limit despite its absence from the documentation, and (since it would be pointless to rate-limit all the time) only if you remember to start and stop it each time, which you probably won’t.

Snap updates are automatic because that greatly improves security and reliability for the installed base, and these five problems are assumed solved or solvable. So, how do we solve the last two?

Providing connection-sensitivity wouldn’t involve changes in Software Updater, just in Software & Updates Settings. (And possibly in snapd too, if its rate-limiting is oblivious to whether anything else is using the connection.)

Providing undoability probably does involve changes to Software Updater. Years ago, before snaps, I suggested it should have menus that included an “Updates History” item. I never got as far as designing that view, but that would be the obvious place to select which update you wanted to undo.

That’s a decent idea, but I’d much prefer deferring to be automatic than manual. Is there a use case for deferring, that could not be handled by a combination of settings for “defer whenever I’m on a metered connection” and “defer/trickle whenever I’m using my connection for something else”?

FWIW “defer when on metered” is already possible: you need to set the connection to metered (in network manager), and then snap set system refresh.metered=hold.

Defer because combinations of ‘I am {giving a presentation demonstrating the software|testing the software|} and I don’t want it changing mid way through’

1 Like

Again FWIW from the terminal that’s snap refresh --hold=<duration> (coming soon).


ok, thank you all for your help.
I would like to see all the features that the snap CLI has in the GUI so that each user can intuitively solve their problems.

I wonder if you’re witnessing IO starvation rather than a network over-use? On one of my systems with a magnetic hard drive, I can hear it chugging away during some large snap upgrades. That is more likely to affect the usability of other processes on the system than network usage.

1 Like

yes, but only on older computers

Hi @mpt @ogra @robert.ancell @chipaca @popey

I just ran into problems in Firefox when updating (due to the fact that this happened in the background without my knowledge).
After updating, the old working Firefox stopped working correctly. Not a single button worked except the main menu.

At the same time, the processor of the system was very heavily loaded. This makes it very difficult to work, I ask you to add update management either in SnapStore or in the update manager.
It is very important. I don’t want something to interrupt my work. And if I work in Blender and render 2 hours of video? I don’t want to do anything because of a failure.

After closing Firefox, I opened it again and saw that a new version had appeared.
I recorded the video as evidence.

I ask you to solve such problems and give the user the opportunity to reject the proposed updates, as was done with deb. It is important that all functions with updates are in the graphical interface.

Firefox 69 (i try click on tabs, bud it is not work )
After restart all is work:

this is handled by

once firefox (or blender) uses it, there will be a download, but switching to the new version will only happen after you closed the app …

Ok, fair enough. Testing/demoing a particular app version is pretty niche, so maybe not an indicator menu, but maybe a “Pause all updates for today” button somewhere.

I seem to have confused the debian and snap version. This problem happened in the Debian version. sorry for the extra noise.