Refresh-schedule via core config

[mvo]

The new snapd 2.25 has a new feature to set the refresh schedule within a 24h window. This allows to say that you want updates only between 4:00-7:00 in the morning for example or between 4:00-7:00 and 19:00-22:00.

The syntax is:

$ sudo snap set core refresh.schedule=4:00-7:00/19:00-21:00

Note that a refresh may happen outside of this window if your last refresh is too old, in this case snapd will refresh even outside the scheduled windows.

[JamieBennett]

Thanks Michael, this is great!

[kyleN]

What is the easy way to determine the version of snapd in a particular core system?

[ogra]

the easiest and preferred way is:

ogra@pi3:~$ snap version snap 2.26.1+201705151555.git.d15bf5b~ubuntu16.04.1 snapd 2.26.1+201705151555.git.d15bf5b~ubuntu16.04.1 series 16 kernel 4.4.0-1051-raspi2 ogra@pi3:~$

a slightly more hackish fallback (if you cant exec “snap”) is:

ogra@pi3:~$ cat /usr/lib/snapd/info VERSION=2.26.1+201705151555.git.d15bf5b~ubuntu16.04.1 ogra@pi3:~$

[geekgonecrazy]

Note that a refresh may happen outside of this window if your last refresh is too old, in this case snapd will refresh even outside the scheduled windows.

What or where is too old defined? I assume the idea is to keep end users from deciding to not ever refreshing. But good to know what “too old” means here.

[JamieBennett]

Older than 24hrs is too old.

[pedronis]

While implementing something else I discovered that at first boot/last-refresh unset we decide to trigger a refresh immediately but through a slowish computation, I think we have two choices

• shortcut: last-refresh unset => immediate refresh
• last-refresh unset => compute the next refresh assuming last-refresh = midnight of the day before (or something similar)

for the default schedule these two are equivalent but for other schedules set through they gadget they might not be

• trying to refresh as soon as possible after a first boot seems a good property and the device usually cannot be expected to be immediately available

[niemeyer]

Unless we have a reason to disable that, the idea of refreshing immediately when it was never refreshed seems reasonable.

As a side note, I’ve just updated the documentation for core configuration options. Let’s please try to keep it up-to-date.

[pedronis]

ok, just a matter of fixing the code not to decide that taking 1s+

[pedronis]

I made a small PR that makes that explicit:

overlord/snapstate: have an explicit code path last-refresh unset/zero => immediately refresh try

[awe]

A couple of observations and questions about refresh.schedule:

• It appears by default the refresh.schedule option isn’t set to anything initially (ie. a get of refresh.schedule reports no key found if it’s never been snap set). If the user sets a schedule, how would they revert this change back to the original behavior?

• I was able to set the refresh.schedule to a single time (eg. sudo snap set core refresh.schedule=4:00). Is this valid?

• I was able to specify five time periods, is there a maximum number of time periods that can be set?

• There doesn’t appear to be any validation of the supplied arguments, I was able to specify the following refresh schedules:

• $ sudo snap set core refresh.schedule=12:00-11:00

• $ sudo snap set core refresh.schedule=12:00-143:00

Note - all the above were observed with snapd 2.25.

[skidmark]

PROBLEM
The directions in the documentation only specify a daily time window.

How can the refresh be set to a particular day of the month or day of the week between specific times?

What is the command to reset the refresh schedule to the default SNAPS refresh schedule behavior?

Is this feature persistent through Ubuntu server system reboots?