Hi, to me this sounds like you are describing the legacy functionality,: snap will refresh when the app is not open and when a refresh is triggered according to manual intervention or the every six hours timer (as long as the application is not open at that moment. For me it very unlikely that the computer is on and the browser is not open.
This is pre 2.59 behaviour and it sucks. It works for sure, if you play ball. But it is not what I am referring to.
I am talking about updating triggered when the application is closed. This is how it is described here:
“Snap users will be happy to know that we have implemented new functionality in snapd to streamline the refresh experience for all desktop snaps. With this change, snaps will now download and pre-initialise an update (when available) in the background then wait for the app to close- or the system to reboot- before switching to the new version. This means users can apply updates immediately by closing the application, and those updates will be applied more quickly than before, minimising disruption.”
I think it worked for me one time, for some previous firefox update. When I saw the announcement of new snapd, I also saw that I had firefox update pending, then I manually ran snap refresh snapd (probably to version 2.59.1), and then firefox updated on close. But I’m not sure now if my memory is correct
Thanks everyone for highlighting the current confusion/frustration. Will do my best to work with everyone to clarify intended behaviour and potentially identify bugs if any.
Just to add, I’m seeing the same problem in the latest/candidate channel. The new update functionality was working fine for firefox on snapd 2.59.1 and stopped working around the time snapd was updated to 2.59.2. Not sure if that is coincidental though, as other snaps (e.g. slack) are updating as expected on 2.59.2 with the new functionality. The issue seems to be limited to firefox.
Hi. I think this is happening because firefox is leaving processes hanging in its cgroup scope which means snapd can’t detect it has closed and refresh it (see: "Close the app to avoid disruptions" for a closed app). If this happens again, you can test that theory by running systemctl status and checking if there’s still a cgroup scope for the snap. As a short-term solution, killing the leftover processes under the cgroup will allow snapd to proceed with the refresh.
Is there a way I can test this on demand, rather than just waiting for the next Firefox update? I know I can revert to a prior snap version, but does this then block automatic updates (it wouldn’t make sense for a user to manually revert a snap and then have snap just update it again, so I am not confident that this would work, I hope there is some other way)
It is working for me now, at least on the three desktops where the snap is beta channel. There has not yet been a stable update, so I don’t know in that case.
Based on feedback from miguel above, I noticed some strange messages in the journalctl -e about the firefox extension KDE Plasma Integration, something do with sockets. My firefox installs are synced so I get a common set of extensions, and sometimes I use KDE Plasma, although all the four installs I am talking about here are Ubuntu (gnome). I removed that extension and did a firefox refresh on all the desktops. ON each desktop the update to 114.0b7 worked. Immediately after exiting Firefox, snap changes shows the update starting and it takes around 10 seconds or so (I did not time this).
I reinstalled the KDE Plasma Integration extension to see if the problem can be reproduced. I tried to trigger this by reverting to a prior version, but it was inconclusive because I did not get the notification to update, that is, snap did not notice there as an update, or ignored it. So I will wait for a “natural” update to 114.0b8
@elcste I think even with the latest changes to the refresh process it is expected that you can NOT successfully run “snap refresh firefox” as long as firefox is running.
i think it just should do an automatic refresh when you close firefox. And before already download the necessary files - not sure if there is a UI/log for that.
There has always been a problem with phased updates of snaps where the metadata is updated ahead of the payload and the actual package itself is not yet available due to phasing … have you tried simply leaving it alone and not trying to force a manual update ?
… i bet it will just DTRT once the actual payload for the updated metadata is available, it might just take a bit … the store should take a look if they can not hold back the meta info update until actual payload is available …
To be clear, the expected behaviour of this feature is that automatic (as in, initiated by snapd) refreshes that are blocked by running snaps are retried after pre-downloading the snap files and notifying the user to close the snap. The expected behaviour for manual refreshes is still the same. If a manual refresh is blocked by a running snap, it still has to be manually retried.
Ah, that makes sense – I was going by an earlier comment. Is there documentation to reference somewhere?
For most snaps that will work fine. But a few, like Firefox Beta that has been the main one mentioned in this thread, there can be an update every day or two during part of the cycle, and you usually do want to upgrade immediately and still take advantage of the reduced downtime of this feature. So to make this feature most helpful for these snaps, I’d suggest their should be a way to manually trigger the background download.
There is a documentation page about deferred updates but it hasn’t been updated to reflect the new behaviour. We’ll try to update that soon.
About the manual triggering of a background download, I think there are plans for work on a two-part refresh (first a download, then the update of the snap in separate steps) which I think would fit that use case. One would be able to download the snap first, then close the snap and manually refresh the snap with less downtime. As far as I know, that work is planned for later in the year.
thanks for that claryfication. What is still not clear to me though: does “retrying refresh” after pre-downloading the files imply that restarting a snap will always start with the newer version or is there still some ~cron-based refresh time involved?
The refresh retry should start almost immediately after you close the snap, although it’s technically possible to restart it so fast that you prevent the refresh from going through. During the refresh process, the snap becomes unavailable to run for a bit and then becomes available again once its refreshed. Since version 2.59.2, snapd also creates a notification stating that the snap was refreshed so at that point it’s definitely the new version that is running.
I have intermittently seen this problem reoccur, although it works at other times.
When I have the problem, there is no cgroup or process hanging around.
However, I always notice that snap changes does not report a pre-download of the update whenever the auto update does not happen. Whenever the update works, snap changes shows that snap has pre-downloaded the update.
