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

Hold your horses, I mean snaps! New feature lets you stop snap updates, for as long as you need

One of the core aspects of the snap ecosystem is the built-in, robust auto-update mechanism. Whenever there is a snap update available in the Snap Store, the snapd service will apply it, keeping your software patched and up to date. Most of the time, this works great. In some scenarios, though, this may not be […]

Snaps & better refresh notifications

Automatic updates grant snap users an ability to receive timely patches to their software, both in aspects of security and functionality. This can be rather useful and convenient, especially for applications that have online access. On the other hand, automatic updates can potentially disrupt users’ workflows if they happen to coincide. B […]

Managing software in complex network environments: the Snap Store Proxy

As enterprises grapple with the evolving landscape of security threats, the need to safeguard internal networks from the broader internet is increasingly important. In environments with restricted internet access, it can be difficult to manage software updates in an easy, reliable way. When managing devices in the field, change management […]