Not on demand, but you could try Firefox nightly (edge channel) since it does update pretty much everyday.
I think it works if you close Firefox and then click the OK button from snap notification.
It did work for me today and atleast one time before.
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
1 Like
FWIW still not working for me:
$ snap refresh --list
Name Version Rev Size Publisher Notes
firefox 114.0b8-1 2713 255MB mozilla✓ -
$ snap refresh firefox
error: cannot refresh "firefox": snap "firefox" has running apps (firefox),
pids:
342532,342776,342804,342823,342875,343670,343672,380409,380468,380516,380
549,380552,380858,380862,380916,380954,380996,381032,381072,381297,381309
,381370,381402,381454,381490,381531,381566,381638,381681,381761,381858,38
1975
@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.
Please correct me if i am wrong
Seems like not working for me (snapd 2.59.2, U22.04). I just saw update is pending, so it’s good opportunity to perform a test.
$ snap refresh --list
Name Version Rev Size Publisher Notes
firefox 113.0.2-1 2710 254MB mozilla✓ -
With running firefox, snap refresh produces expected result:
$ sudo snap refresh firefox
error: cannot refresh "firefox": snap "firefox" has running apps (firefox), pids:
338004,338170,338193,338298,338423,339292,339295,347140,347243,350759,350839,351390,351486,351590
Closing firefox, no processes running as far as I can tell:
$ systemctl status | grep firefox
│ │ │ │ └─351733 grep --color=auto firefox
Launching firefox again, version did not change:
$ snap info firefox
tracking: latest/stable
refresh-date: 10 days ago, at 11:55 CEST
channels:
latest/stable: 113.0.2-1 2023-05-23 (2710) 254MB -
latest/candidate: 113.0.2-1 2023-05-22 (2710) 254MB -
latest/beta: 114.0b8-1 2023-05-24 (2713) 255MB -
latest/edge: 115.0a1 2023-05-25 (2721) 262MB -
esr/stable: 102.11.0esr-2 2023-05-09 (2642) 186MB -
esr/candidate: 102.11.0esr-2 2023-05-04 (2642) 186MB -
esr/beta: ↑
esr/edge: ↑
installed: 113.0.1-1 (2667) 253MB -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.
1 Like
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.
3 Likes
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?
that sounds good
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.
1 Like
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.
snap changes does not report a pre-download of the update whenever the auto update does not happen
Can you expand on this? Does that mean that sometimes you get a notification to close a snap but, when you do, the refresh isn’t triggered and there’s no pre-download entry in output of snap changes?
that seems unlikely when you put it like that. I will watch and report here. It would be a lot easier if I knew a good way of triggering the update process.
Right, i confirm this. I am using kubuntu 23.04 at the moment. Firefox snap (stable) is 113. I got the notification about a snap update. But after I closed firefox, nothing happens. There is no cg or processes open.
tim@ElecGear:~$ snap changes
ID Status Spawn Ready Summary
13 Done yesterday at 19:24 AEST yesterday at 19:25 AEST Install "authy" snap
14 Done yesterday at 19:24 AEST yesterday at 19:24 AEST Auto-refresh snap "core22"
15 Done yesterday at 19:25 AEST yesterday at 19:26 AEST Install "bitwarden" snap
16 Done today at 17:36 AEST today at 17:37 AEST Pre-download tasks for auto-refresh
tim@ElecGear:~$ snap refresh --list Name Version Rev Size Publisher Notes firefox 114.0-3 2751 256MB mozilla✓ - tim@ElecGear:~$
[I then exited firefox again … nothing happens. sudo snap refresh updated firefox without errors]
Hi. Was this reply to my message? If so, then my firefox is still on version 113.0.1-1 despite me waiting for it to DTRT for two weeks since last post. As far as I know the snap is not on hold, because I never issued such command.
> $ snap info firefox
> name: firefox
> summary: Mozilla Firefox web browser
> publisher: Mozilla✓
> store-url: https://snapcraft.io/firefox
> contact: https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla
> license: unset
> description: |
> Firefox is a powerful, extensible web browser with support for modern web application
> technologies.
> commands:
> - firefox
> - firefox.geckodriver
> snap-id: 3wdHCAVyZEmYsCMFDE9qt92UV8rC8Wdk
> tracking: latest/stable
> refresh-date: 24 days ago, at 11:55 CEST
> channels:
> latest/stable: 114.0-3 2023-06-06 (2748) 256MB -
> latest/candidate: 114.0-3 2023-06-02 (2744) 256MB -
> latest/beta: 114.0b9-1 2023-05-26 (2724) 255MB -
> latest/edge: 116.0a1 2023-06-07 (2754) 262MB -
> esr/stable: 102.12.0esr-1 2023-06-06 (2735) 186MB -
> esr/candidate: 102.12.0esr-1 2023-05-29 (2735) 186MB -
> esr/beta: ↑
> esr/edge: ↑
> installed: 113.0.1-1 (2667) 253MB -
$ snap refresh --list
Name Version Rev Size Publisher Notes
firefox 114.0-3 2748 256MB mozilla✓ -
Just wondering whats going on. In those two weeks I closed firefox multiple times. Did not receive any popup messages about pending firefox update as far as I remember.
ps. other snaps are updating ok
Just adding another datapoint here that the issue with firefox in-place updates still persists. When a new update is available a notification will pop up indicating to close firefox to start the update. After closing firefox, the ‘snap changes’ command will show something analogous to this:
2916 Done today at 13:57 EDT today at 13:57 EDT Pre-download tasks for auto-refresh
Even after waiting a few minutes the message remains the same and the refresh is never started. In contrast, for other snaps the status will show a change in summary to Refresh snap x with a status of doing. Once done, another notification appears to indicate that ‘snap x’ is ready for relaunch. That process typically takes about 20-30 sec.
There do not appear to be any stray c-group entries for firefox that are blocking the update (based on the command in one of the above comments). In fact, when firefox is closed, running snap refresh firefox will download and refresh firefox as expected. The fact that the manual command starts with a download suggests to me that there may be an issue/delay with the autodownload component, given that the new snap version doesn’t appear to be queued up when the message appears to restart firefox. I’ve tested the stable, candidate and core22 channels and all have the same issue.
Perhaps there is some relation to the phased update issue as indicated by ogra, where the metadata is out of sync with the download. In that case, maybe a solution would be to ensure that no notification is shown until the autodownload is fully completed?
When it goes wrong, it stays wrong. It never does the pre-download
Hi timattrn,
When you encounter the issue again, would you please also confirm that you see “Pre-download tasks for auto-refresh” when running snap changes.
Then would you please also run and share output of snap refresh --time