Aborted auto-refresh does not allow manual refresh

A device in slow internet conditions (≈ 30KBps) is failing to perform an auto-refresh which causes the following

# snap changes
ID   Status  Spawn                      Ready  Summary
68   Abort   20 days ago, at 06:06 EDT  -      Auto-refresh snaps "core18", <my snap>


# snap refresh <my snap>
error: snap <my snap> has "auto-refresh" change in progress

I can only try a manual refresh after rebooting the device (or probably restarting snapd would allow this too, have not tried). This happens consistently on all devices that have similar internet speed.

You can use snap abort 68 to stop an in-progress or failed refresh, then manually refresh with snap refresh <my-snap>

Thanks for your reply, this will allow me to not reboot the device. But shouldn’t snapd cleanly abort the refresh on failure on it’s own?

It depends, if the download is progressing but just very slowly then from snapd’s prospective things are working albeit slowly so it should continue trying and just wait for it to finish. We could perhaps adjust the error message about snap refresh <snap> to mention that it could be aborted if the user wants to “force” the refresh, or perhaps even an option to snap refresh like

$ snap refresh my-snap --abort-current-changes

which would then ensure if there is a current refresh or auto-refresh change for the snap ongoing that it would get aborted and then the manual refresh would be started as requested.

This took me over a year to reply, but we are still seeing the issue on snapd version 2.52.1. The issue here is clearly not the slow internet, it is the reported status of the refresh. If snapd has given up trying to refresh a snap, the status should go from doing to abort, at which point snapd should allow for a manual refresh (in the end it is supposed to be aborted already, isn’t it?).

We just had a device that kept an auto-refresh in the abort state for over 1 month, it should not hang here if abort was a clean exit from the refresh.

Hmm, as I mentioned the issue could be that snapd doesn’t think it should abort the change since it is making progress.

Are you saying that you have a new/different case with faster internet speeds where it hangs for other reasons?

That is the case, better internet and still doing this. I’m not 100% sure I understand the actual state names then, the auto-refresh change is in the state abort and it hangs like this (even if it is making progress it should stop the refresh when it is showing this state right?). Aborting the change does nothing as it is already in the abort state, so it still hangs. If it is making any progress at all then the auto-refresh state should remain doing I suppose, no matter how slow it is.

Could you please share your /var/lib/snapd/state.json file (stop snapd first; make sure to remove or obfuscate “session-macaroon” as it’s a sensitive bit)? Please use pastebin.ubuntu.com or similar and paste the link here or PM me.

We think we fixed a problem around downloads getting stuck with snapd 2.51, but maybe we didn’t completely fix it or it’s something else. A manual restart of snapd should “fix it” (but please grab state.json first).


Actually, before you stop snapd and do anything else, if it’s still in this state, could you please execute `sudo snap debug stackstraces’ and pastebin the output?