Snaps & better refresh notifications

by Igor Ljubuncic on 4 November 2022

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.

By default, snap refreshes are triggered four times a day. Users have the option to fine-tune the exact schedule, which can help minimize any conflict with actual work, but even so, there might be an update to a running application while it’s in use. In this case, a notification is shown to the user asking them to close the application, in order to allow it to be refreshed in the next slot (about six hours later), or to allow them to manually run the snap refresh command. Of course, this behavior is confusing and inconvenient, and that’s why the snapd team is working on a number of methods designed to minimize impact in these scenarios. These include snap refresh awareness and deferral for when the application is closed.

Refresh notifications

The basic concept is, after having notified the user that one of their running programs has a pending update, to trigger a new refresh operation as soon as the user closes the program. This allows the users to continue working with the updated application as soon as possible.

A good example would be Firefox or Chrome. As Web browsers, they neatly fit into the earlier story: an essential tool with online functionality, strong requirement for timely security, and they are often used for a long period without closing, which can preclude the patches from being installed and applied. This is not specific to snaps, or Linux, though.

On Windows, for instance, the Firefox update service will apply the patches in the background, and will then prompt the user to restart the program. In Linux, if you run a distribution that ships the browser through its repository archive mechanism, and you update the system, you will see a notification that tells you to restart the application.

With the desktop integration in place, the same basic principle applies to snaps. If you open Firefox and there’s an update at that time (manually or automatically initiated), you will see a notification on your system. It will tell you that there’s a pending update, and you will have fourteen days to restart the browser to complete the process. Ideally, you will do that sooner, in order to patch the browser. But this gives you time to prepare, save any work, and then gracefully apply the update.

With the changes that are being worked on, the snapd service will wait, and once you close the browser, update the application – but only if the refresh was started as part of the normal schedule. For manually initiated updates, you will need to rerun the command yourself. 

On the command line, if you try to run an update while the application is running, you will see something like:

snap refresh firefox
error: cannot refresh "firefox": snap "firefox" has running apps (firefox), pids:

This looks easy to implement, why are we still waiting?

While seemingly trivial, these changes have to be added into the core snapd, which is a critical component for the functionality of the ecosystem, and must behave in a rock-solid manner. This means that any change must pass a very strict set of reviews before being allowed to be published.


Update notifications are one of the many ways by which the snap teams are trying to make the experience more streamlined both for developers and the end users. The balance between security and functionality is always a delicate one, and requires careful attention to details. With better awareness and smoother application of updates, snap users should benefit from improved security without having a degraded experience. While the tooling is still in early stages, the notifications work well and display reasonably well on both the GNOME and Plasma desktops. On the latter, at the moment, the notifications do not expire, and you need to dismiss them manually.

This is where you can help, by testing the desktop integration in different distributions and desktop environments, and provide feedback to the snapd team. If you’d like to participate, please grab the snapd and desktop integration snaps from the edge channel, and try them on your system. You can provide feedback directly on the snapd GitHub page, or join our forum and let us know what’s missing.

Photo by Валерия 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 […]

Private shared memory support for snaps

At first glance, the title of this article may sound like an oxymoron. However, what it highlights is the introduction of a rather useful feature that will enable a far more robust and elegant handling of the /dev/shm implementation inside the snap sandbox. This will make snap development easier, more secure, and reduce potential bugs […]

Creating Snaps on Ubuntu Touch

This article was written in collaboration with Alfred E. Neumayer of the UBports Project. Tablets, phones and current technology’s capabilities are phenomenal. Who would have thought a thin, light, barely 10 inch device would provide all the power necessary to run Virtual Machines, wherever one desires while powered on battery? That a sma […]