Updates are an integral part of the software lifecycle. Quite often, they bring improvements, vital security patches – and sometimes, unfortunately, bugs, too. In mission-critical environments, it is important to assert a high degree of oversight and precision over updates.
Snaps come with a built-in automatic update mechanism, whereby snaps are refreshed to a new version whenever there’s a new release in the Snap Store. Typically, the refresh occurs four times a day, and in the vast majority of cases, they will complete seamlessly, without any issues. However, there are cases when and where snap updates need to be deferred or postponed, or simply managed with a greater, more refined level of control. There are several ways the users can achieve that.
Snap (refresh) control
The snap updates schedule is governed by four system-wide options. These include:
- Refresh.timer – Defines the refresh frequency and schedule. You can use this parameter to set when the snaps will refresh, so this does not conflict with your other activities – like work meetings, data backups, or similar.
- Refresh.hold – Delays the next refresh until the defined time and date. The hold option allows you to postpone updates for up to 60 days. In combination with the timer option, you can set very specific time windows for when the snaps are updated.
- Refresh.metered – Pauses refresh updates when the network connection is metered. By default, snap refresh is enabled over metered connections. However, to conserve data, you can pause the refreshes on such networks.
- Refresh.retain – Sets how many revisions of a snap are stored on the system. By default, the last three revisions of the installed snap will be kept.
The combination of these four factors gives users quite a fair bit of flexibility in how they control the snap updates. In particular, the timer and hold can be used to create set windows for updates, allowing you to perform any necessary pre- and post-update tasks, like functionality checks, data backups, and more.
The time-snap continuum
Let’s have a look at some practical examples. For instance, you may want to set your snap updates only to run overnight, between 01:00 and 02:00 (in the 24h format).
sudo snap set system refresh.timer=01:00-02:00
After you set the schedule window, you can check what the system reports:
snap refresh --time
last: today at 12:38 PST
next: tomorrow at 01:00 PST
There are quite a few variations available, including the ability to set the schedule at specific hours or time windows for each day of the week, you can omit some days, and you can also set in which particular week of a month you may want to run the update. You can use values 1-4, e.g.: mon3 will be the third Monday of the month, while 5 denotes the last week in the month, as no Earthly calendar currently has more than 31 days.
Setting the hold interval takes a specific date format, as it needs to conform to RFC 3339. This may sound like a page straight out of the Vogon book on time management, so you can use the following command to convert dates into the right format:
date --date="TMZ YYYY-MM-DD HH:MM:SS" +%Y-%m-%dT%H:%M:%S%:z
date --date="PST 2020-08-01 13:00:00" +%Y-%m-%dT%H:%M:%S%:z
Then, you can set the refresh value with the formatted date string:
sudo snap set system refresh.hold=2020-08-01T13:00:00+01:00
sudo snap get system refresh.hold
Once the refresh hold is in place, you can check the refresh schedule:
snap refresh --time
last: today at 12:38 PST
hold: in 31 days, at 13:00 PST
next: tomorrow at 01:00 PST (but held)
As you can see, the information now combines parameters both from the timer and hold settings. The next update is meant to be tomorrow at 01:00, as defined by the timer, but it will be held – for 31 days – until the update deferment expires.
Similarly, you can configure the updates on metered connections. Setting the value to hold will prevent updates, while changing the value to null will allow updates to resume.
sudo snap set system refresh.metered=hold
sudo snap set system refresh.metered=null
Again, you can combine this option with the timer and hold settings to create a granular and precise update schedule that will not interfere with your critical tasks, ensure maximum consistency, and also allow you to receive the necessary functional and security patches.
Then, occasionally, you may want to check which snaps will update on next refresh. This will give you an indication of the pending list of new snap revisions your system will receive:
snap refresh --list
Name Version Rev Publisher Notes
lxd 4.3 16044 canonical✓ -
snapcraft 4.1.1 5143 canonical✓ classic
Now, the full list of installed snaps is longer. For example, the system currently has lxd version 4.2 installed:
snap list lxd
Name Version Rev Tracking Publisher Notes
lxd 4.2 15878 latest/stable canonical✓ -
This is another feature that you can use to control the updates. In some cases, you may be running a vital task that must not be interrupted in any way. To that end, you can use refresh awareness to make sure the application will not be updated while running. If you try to run a manual snap update while it’s running (and you’re using the awareness feature), you will see a message like below:
snap refresh okular --candidate
error: cannot refresh "okular": snap "okular" has running apps (okular)
Automatic updates can never be a blanket solution for all use cases. Desktop, server and IoT environments all have their particular requirements and sensitivity, which is why snapd comes with a fairly extensive update control mechanism. The combination of timed schedules, update delay of up to 60 days, metered connections functionality, and snap refresh awareness and update inhibition offer a wide and pragmatic range of options and settings, through which the users can create a robust, reliable software update regime. Furthermore, business customers can configure their own snap store proxy.
Hopefully, this article clears some of the fog surrounding snap updates, and what users can do with them. If you have any comments or suggestions, please join our forum for a discussion.