I’m not really the best person to answer that, but I’d put a guess on that the store may be throttling downloads temporarily to prevent resource exhaustion, but there could be other explanations such as you might be following a short lived branch such as hypothetically latest/stable/ubuntu-22.04 Whether this one specifically exists, I’m unsure; but some snaps baked into the Ubuntu releases tend to have the pattern of using a branch release specific to the distributions release, which later realigns with latest/stable but at any given point might actually be slightly different to it.
Try
sudo snap refresh --channel latest/stable snapd
In the general case however, I’d expect it would update itself as expected eventually
I’m concerned that with the default enabling this, users not manually enabling the feature now don’t know what to do. The notification tells them to close Firefox. So they do. Then what? By default, the snap isn’t refreshed, and they restart Firefox without it having been updated.
People who enabled the experimental feature might be expected to understand how to refresh a snap manually. But that’s not something your everyday user on defaults could be expected to know.
What is the intended UX here?
Are they expected to wait with Firefox closed (but with the desktop session running) for up to six hours for the default refresh schedule to take effect? Or are they expected to refresh the snap manually?
More importantly, how are they expected to know what they’re expected to do?
Came here to comment about the new Snap refresh behaviour but this sums up my thoughts. I for one was somewhat blindsided by the new change, and since I manage a fleet of Ubuntu (20.04 LTS) machines (the users of which are not all Linux-literate), I too would love to know what is the intended workflow for updating snaps now?
If I understood correctly, previously snaps would simply refresh, and if they were ‘busy’, would remain open with the old version until you closed the app. This was a pretty simple workflow, which even basic users could understand (or weren’t even aware of).
But now you’re prompted to close the app, with no further information.
I think the worst part is that I simply had no idea this feature was heading my way.
I appreciate there are use-cases for this, but to me at least, the implementation is not ready for full roll-out.
Not a snap dev, so I can’t comment on future plans; however the snap will eventually update regardless, with the same behaviour as it used to. When the 14 days runs out, if there’s still not been an opportunity to refresh, it will happen even with the app running.
No further information, no way of know if it was updated (unless you ran snap refresh).
Earlier this week, my Firefox (stable channel) was prompted to close because of pending update. To my surprise, I still find it asking to be updated, and it was still on v100 all this time. It wasn’t until I ran snap refresh that I discovered that the cause was the geckodriver alias already being used by my Firefox beta parallel install.
That’s 90% of people who weren’t delayed two weeks, they were delayed enough to ensure the app wasn’t running whilst updated, which is hugely better than what would happen before (app instability).
There’ll almost certainly be some users who do end up hitting the fallback of refreshing while the app runs anyway, but it’s still a better position for most people than before.
And I totally agree that there could be improvements in the UX (e.g, triggering the refresh when the app is closed, scheduling updates during shutdown, improving the notification to have “Update Now”, etc), but from the publisher side of things, I personally think this is a much better position for the snap ecosystem to be in than without it, and hopefully more improvements will come later.
If I understood correctly, previously snaps would simply refresh, and if they were ‘busy’, would remain open with the old version until you closed the app. This was a pretty simple workflow, which even basic users could understand (or weren’t even aware of).
The previous behavior could lead to data loss, in some scenarios (I believe Chrome was a fairly common victim of it, but there are others). When a snap is updated while still running, snapd could create a folder under user’s home for the new version - under ~/snap/awesome_snap/77 , for instance, with current version being 76. Users could, then, keep using old version and making changes, only to find out that some data has “vanished”, because next time they open the app, the new folder will be used (and changes were in the old one). I think this was one of the motivations for implementing this feature (a big one, if I may guess).
In theory. I still don’t really know how it’s supposed to work.
I’ve been observing it all week and waited for the countdown timer on my Thunderbird refresh to expire. It triggered the refresh despite the app being open, but then the refresh continually fails.
> 51 Error 3 days ago, at 14:32 BST 3 days ago, at 14:33 BST Auto-refresh snap "thunderbird"
> 52 Error 2 days ago, at 15:29 BST 2 days ago, at 15:29 BST Auto-refresh snap "thunderbird"
> 53 Error today at 10:15 BST today at 10:15 BST Auto-refresh snap "thunderbird"
So I’m not sure if the error is expected because Thunderbird is still active, or if it’s just broken. Either way, my Thunderbird hasn’t updated yet with the new behaviour.
Is there any way we can have snaps on Ubuntu CORE update during the shutdown process of the PC? So it does not interrupt the business while the snap is in use or during bootup?
If the issue is primarily due to differences between the ‘current’ and ‘previous’ versions, maybe the data could simply be rsynced from ‘previous’ to ‘current’ when the new version is first run.
Then we would just need some logical check to see if it’s the first time the ‘current’ version is being run, and trigger the rsync.
Then there would be no need to delay snap updates.
Another use case is when something is running as a daemon in background. I am facing this weird issue with deja-dup, where deja-dup-monitor is running constantly, thus preventing the snap from updating (I presume). The effect: notifications about pending update every day, now I am with 6 days left. I have restarted the OS multiple times, still no update. I don’t think having to find a pid of the process and killing it manually is the solution for end user. Notifications for 14 days every day are also not a pleasant experience. So, I would very much welcome some improvements in the area, maybe force updates on shutdown, or add a button to this notification dialog which will close every running process (owned by particular snap) and force update.
Refresh app awareness has been (temporarily!) disabled by default again as of the snapd 2.56.3 release (which should be rolling out in the next few weeks), this revert the behaviour to the previous experience where the “pending snap update” notifications didn’t exist, until improvements in the UX and some specific issues with certain snaps (e.g, LXD) are resolved.
Refresh app awareness is back by default in 2.57; the known bugs effecting reliability of refreshes for certain applications have been fixed. The UX with the “snap update pending” notifications is the same as before and hasn’t been refined since 2.55, but of course, this doesn’t preclude future improvements!
Looking at the current state of the snapd snap, 2.56.3 from the previous post didn’t make it into the stable channel and so for the majority of people, refresh app awareness likely never actually got disabled, even temporarily.
This completely fails the “mom test” - my mother has no clue what this notification means and what to do about and it shows up all the time.
I think it’s back the to the drawing boards and work out another approach, this is not the way and it honestly completely breaks the whole Ubuntu user experience - this is serious.
I think that showing a notification “There are updates pending - click here to update” would be more sane, and when clicking the notification a window would show that lists all the applications that has an update available and a close/kill/update button + a way to “mass close/kill/update” all applications on the list.
There should absolutely be no terminal commands involved … this is not mom friendly.
Do Canonical employees really go to the terminal every time this notification shows up, to update installed Snaps?!
