Disabling automatic refresh for snap from store

It shouldn’t be too hard to tweak the automatic refresh behavior if one is willing to build one’s own version of snapd (in a PPA for instance). The auto refresh logic appears to be mostly contained in the source file https://github.com/snapcore/snapd/blob/master/overlord/snapstate/autorefresh.go. Of key importance is the maxPostponement parameter which is currently set at 60 days.

That’s not really a solution for developers trying to avoid causing downtime for users. That’s a solution for technicians and admins.

Why not just make it so that the update is installed in the background but only applied when the app is relaunched?

First of all, hello everyone, this is my first post ever.

I must say installing LXD via snap is super fast and easy.

But I have a possible problem:
let’s say I have a Ubuntu or Debian server with LXD installed via snap.
LXD got updated, but there is a bug which kills LXD because sh!t happens.

There should be, imho, a flag somewhere to keep some packages at a specific version (because I want another snap get always updated because reasons), and after some extented testings I’ll update the snaps manually, I can’t risk every day to see some important services broken, and recover a backup (which will be broken again because snapd tries to update my package again)

Or at least create a fork of snapd for servers called “Snap Pro” or something else and leave the option to make the sysadmins owners of their servers.

EDIT: if it could be helpful I can open a ticket on snapd launchpad with this request tomorrow, right now here it’s 1:15 in the night and my brain is going to standby :slight_smile:

3 Likes

See:

and you can also simply set schedules for planned maintenance windows like described in:

That is a non-solution, only kicking the problem further down the road.

3 Likes

Following up on my earlier post, wouldn’t changing the maxPostponement constant in autorefresh.go from 60 days to 60 years effectively allow you to disable auto updates?

which sounds like a workaround like the manual download with the --dangerous switch or edit the source like @casey did.

Here an idea:
in /etc/default/snap.conf we can make a parameter called “manual” or something else. Default is 0, if someone puts the value 1, the manual management for single snap is enabled.

somewhere else in a directory called snap.d , we can make a configuration file (like a json or yaml) . Every file is the name of the snap app (let’s say “foo.conf” for the package “foo”)

Inside this foo.conf we can decide when to update the single package (with the already written configuration and logic, or even with a cron-like syntax.), and if there is something like “noupdate=1” directive, the package is ignored by the refresh.

When I want to update a package with “noupdate=1” or I delete the configuration file or I put a schedule inside the configuration.

A neat thing to do: could be interesting to pin a package inside this configuration, like I want only the channel of “LTS 4” of LXD, but IIRC it’s not necessary because when you install a snap you can do already something like that.

If there is no .conf the refresh of the package follows the standard configuration.

Seems a more *nix way to do things, for my $0.02

1 Like

well, what i linked was our official documentation :slight_smile: not a workaround of any kind …

admittedly the refresh-app-awareness feature is still experimental though but will eventually land …

Well, my suggestion sounds better in my mind.
Time flies (and I forget), or I go away from my current company and I forget to say to the new sysadmin : “Look! The foo package is manual because $reasons!”.

If there is something like a snap.d configuration directory like in my previous post, he will go to see this directory and he will remove or edit the configuration.

Because it seems the solutions proposed right now is global, but something like this could be needed:

  • Package foo: will update every x time
  • Package bar: will never update automatically. Only when I tested on the staging server.
  • Package lorem: will update normally

obviously this is all IMHO :slight_smile:

3 Likes

You can always move to a flatpak
Unless blocking snap in the hosts file is a valid option

Maybe the below link will help you.
https://discuss.linuxcontainers.org/t/disable-snap-auto-refresh-immediately/5333

I’ve spent months hunting down why my multi-day jobs on microk8s often fail.
Someone in microk8s said an update occurred at about the same time as one of my crashes.
Is there a log of snap update activity?
Is there no way for me to schedule the updates for when it’s convenient?

snap changes

has the logs from snapd (for the last 72h or so)

to schedule updates you can use refresh.timer or refresh.hold:

thanks, what does this mean

snap changes
ID   Status  Spawn                   Ready                   Summary
382  Done    yesterday at 18:08 CST  yesterday at 18:08 CST  Running service command for snap "microk8s"
383  Done    yesterday at 18:08 CST  yesterday at 18:08 CST  Running service command for snap "microk8s"
384  Done    yesterday at 18:08 CST  yesterday at 18:08 CST  Running service command for snap "microk8s"
385  Done    yesterday at 18:08 CST  yesterday at 18:08 CST  Running service command for snap "microk8s"
386  Done    yesterday at 18:08 CST  yesterday at 18:08 CST  Running service command for snap "microk8s"

Also, whould anyone know if microk8s is dependent on other snap packages? I’m not sure what constitues a snap package.

likely that someone started/stopped/restarted the snap, you can get log details when using the ID (first column) like:

snap change 123

again, thank you.

From this, looks like snap can be daemons or app. Is this correct ?

snap change 382
Status  Spawn                   Ready                   Summary
Done    yesterday at 18:08 CST  yesterday at 18:08 CST  restart of [microk8s.daemon-etcd]

john@john-trx40-designare:/var/log$ snap change 383
Status  Spawn                   Ready                   Summary
Done    yesterday at 18:08 CST  yesterday at 18:08 CST  restart of [microk8s.daemon-containerd]

john@john-trx40-designare:/var/log$ snap change 384
Status  Spawn                   Ready                   Summary
Done    yesterday at 18:08 CST  yesterday at 18:08 CST  restart of [microk8s.daemon-apiserver]

yes, snaps can contain daemons, apps or simply data … you should start a new thread if you want to go on discussing this though, it is kind of offtopic for this (already huge) “automatic refresh” thread …

1 Like

good point. I’ll create a new topic to better understand the frequency and scope of updates.

I beleive on topic, is the “Software & Updates” ubuntu app, 3rd tab called “Update” referring to snap?
The first line “Snap packages update are checked routinely and installed automatically” implies so.
The 2rd selector “automatically check for updates” implies it will turn off snap updates.
I had set this to never at the start of my debugging window and this morning it was back to “daily”.

The link ogra https://snapcraft.io/docs/keeping-snaps-up-to-date#heading–refresh-hold does not describe a UI. Is this the same thing?

the Software and updates app only applies to apt/deb packages (with teh exception of the livepatch tab), to my knowledge there is no GUI for the snapd settings currently.

1 Like