How to manage snap updates

by Igor Ljubuncic on 9 July 2020

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
timer: 01:00-02:00
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

For instance:

date --date="PST 2020-08-01 13:00:00" +%Y-%m-%dT%H:%M:%S%:z
2020-08-01T13:00:00+01:00

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
2020-08-01T13:00:00+01:00

Once the refresh hold is in place, you can check the refresh schedule:

snap refresh --time
timer: 01:00-02:00
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✓  -

Refresh awareness

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)

Summary

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.

Photo by Chris Leipelt on Unsplash.

Newsletter Signup

Related posts

Complex problems, clever solutions – unique containers and virtualization snaps

Snaps come in many shapes and forms: security tools, productivity apps, games, handy utilities, video editing software, and more. Often, most snap package a single application. But snaps can also include services, databases, as well as multiple binaries. How far can this concept scale, you ask? Quite far. There are also some rather unique […]

Canonical enables Linux desktop app support with Flutter

By Chris Sells (Google) & Ken VanDine (Canonical) Google’s goal for Flutter has always been to provide a portable framework for building beautiful UIs that run at native speeds no matter what platform you target. To validate this capability, we started by focusing on the mobile platforms, Android and iOS, where we’ve seen more than […]

A snap confined shell based on Mir: Mircade

Mircade: An example snap confined user shell There are various scenarios and reasons for packaging a Snap confined shell and a selection of applications together in a confined environment. You might have applications that work well together for a particular task; or, you may want to offer a number of alternative applications and have them […]