Re-visiting update control on the desktop

This is the current default.

I think the important part here is that users are notified of pending updates, and then get the option to postpone them. I think very few users will remember to go into settings and postpone all updates until after their big presentation. However, if a user has a big presentation the next day and they get a dialog asking to run updates, they might say “postpone them until after my presentation”.

So in short, snapd should warn desktop users that an update will happen and give them an option to postpone updates then and there.

Holding updates on metered connections is already possible, see Keeping Snaps Up To Date.


Actually for postponing I meant exactly that :smile: Thank you for the clarification

Hi @popey, first of all thank you for opening this task and revisiting that settings.

I would also like to freeze a specific snap version and update only some security vulnerabilities maybe.
Not sure if the following packages are in snap (yet), but their update caused a lot of trouble in the past for me and my projects: GCC, clang, CMake, curl. (change of behaviour, my projects did not compile anymore, etc).

I would like to have it in XFCE as well of course, but I can manage it in cmdline until then (to switch off automatic refresh)

Best regards.

This should already be possible using “channels”. A publisher creates a track for each major version of their applications and users chooses which track they want to follow. By default, every new major version gets installed immediately but if users manually choose a specific track, they will stay on that major version until they manually upgrade. Since you mentioned cmake; it is available in the Snap store and it does support tracks:

$ snap info cmake
name:      cmake
publisher: Crascit✓
  latest/stable:    3.18.2                 2020-08-20 (549) 112MB classic
  latest/candidate: ↑                                             
  latest/beta:      ↑                                             
  latest/edge:      3.18.20200822-g08170b1 2020-08-22 (556) 113MB classic
  3.18/stable:      3.18.2                 2020-08-20 (549) 112MB classic
  3.17/stable:      3.17.4                 2020-07-30 (507) 111MB classic
  3.16/stable:      3.16.8                 2020-06-01 (401) 129MB classic

Is this what you are looking for @taw_moto?

@galgalesh thanks for the idea. Currently I am not using snap(because I did know about channels and I hate automatic updates), but I will give it a try, it doesn’t sound so complicated :slight_smile:


@galgalesh I researched a bit your idea and is nice indeed, but very few packages have the option to track a specific major version, for example skype and valgrind do not have this option.
So I have valgrind 3.16 and I will be upgraded to 3.17 when that version will become stable, which I don’t want to. I want to stay with 3.16 for ever. (just an example)

Thanks for the idea though.


I think in those cases, it’s best to contact the publishers and ask them to create tracks for that snap. There is no way for Snap to know whether something is a security/minor update if the publisher doesn’t mark them as such. If the software is expected to be backwards-incompatible, the publisher really should create a track for each major version.

1 Like

@galgalesh I understand but I don’t think it’s a good idea to contact 10-15 publishers and ask them to modify their snap packages.
Isn’t more simple to have a snap option to disable updates for a certain package?
Smth like “snap disable-updates valgrind” which will pin the current version of valgrind and it will not update it.

I can understand this seems a little daunting. This work would traditionally be done by distribution maintainers. The Ubuntu developers publish multiple versions of GCC, for example and make special security update releases for all software.

With Snap packages, this suddenly becomes the task of the upstream software maintainer, and many of them are not yet accustomed to how Snap works and what the best way to do releases is.

This would be a simpler option from your perspective, yes. There are a few reasons why the Snap developers are resistant to adding this feature:

Note that I am a community member myself, so don’t use this as an official source

Decreasing the number of insecure Linux systems out there

The number of APT updates that actually get applied is shockingly low. There is a very large number of insecure Linux machines out there, and many of them are already being used in botnets to attack secure systems. Addressing this issue is a big goal of Snap.

At this point, many people ask “but it’s my system why can’t I decide if I want to be insecure?”

  • Many systems hold personal information of seemingly unreladed individuals. See the Equifax breach, for example, which was caused by outdated software.
  • Many insecure systems have been weaponized to fight secure systems. Most botnets are created by infecting insecure systems and most DDoS attacks originate from such botnets.

Having many insecure Linux systems hurts everyone. For this reason, the Snap developers are going through great lengths to avoid adding an option to turn off updates completely. I agree with you that this is a quite idealistic stance and I know it creates friction with people who are used to turning off automatic updates. I myself am not totally convinced that this is the right approach, but I applaud the Snap developers for trying to solve this issue once and for all.

Because APT is still a very valid alternative, Snap has some room to experiment. If users don’t like this approach, they can keep using the regular packages.

Pushing users and publishers towards better solutions

If publishers enable it, then tracks are a much better solution for your use-case because you’ll still get minor and security updates. Moreover, the publisher of the software will know people are still using previous versions.

The actual underlying issue is that publishers don’t support multiple versions of their software. snap disable-updates is a band-aid which only makes the issue worse: publishers won’t actually know users want to run older versions of their software because users can “hack around it”. As you said yourself; you would much rather apply a workaround than actually telling the publishers there is an issue with their snap.

This is a common issue in Linux. The libinput stack, for example, disabled configuration options for the very same reason: when a touchpad driver misbehaves it should be fixed in the upstream code so that all users of that driver get the fix. The old input stack had so many configuration options that distributions and end users just worked around issues instead of asking the developers to fix them.

So I would definitely recommend contacting the publishers because you’ll solve this issue for everyone else too. Moreover, the solution you get is a lot better than what you’d get with snap disable-updates. This is, in my opinion, a good way to give back to the community.

I can totally understand it, however, if you’d rather keep using other packaging methods like APT.


@galgalesh Thanks again for your answer but your approach is quite idealistic, because:

  1. Contact the publishers… :slightly_smiling_face: I contacted several publishers/git maintainers/etc for bugs/problems, including LLVM, Microsoft and very very very few answered or were open to change. Most of ones who answered just said NO, although my proposals were voted by many people. So I doubt this works in practice.

  2. I love auto-updates as long as they don’t break something. For example I use VirtualBox quite a lot and every after EVERY major update, they break something: video, sound, keyboard input…Sometimes my old VM does not work, is very very painful. Therefore I am using a stable VirtualBox version now OR, before updating it, I do a backup. Another example: Ubuntu broke DejaVu rendering in 16.04: (fixed in 18.04)

I work in security so I understand your concerns but my experience with Linux packages is that everytime they break something. Every single time. That’s why APT is more conservative and does not update.

I made an account for this post. I have to say, I’m astounded by the arrogance of the snap developers. All of the arguments for not allowing people control over their own systems’ updates basically boil down to “but some people won’t know any better and have insecure computers! That’s why we need to take agency away from everyone!” You seem to have forgotten that the entire point of open source software is control for the users of said software. I know the developers here will tell me “it’s your choice to use snaps then!” And to a degree, it certainly is. However, I have been using Ubuntu as my primary operating system for over 14 years at this point, and I’m now considering moving everything away from it because I really can’t stand dealing with this, and regular Ubuntu’s become so intertwined with snaps that I really can’t use it if I remove snaps from it entirely. This was the thread I came to while frantically googling various ways to get snaps to stop updating automatically, because I’m tired of not being able to shut down a laptop without getting a Windows style "hold on! We’re installing updates so you get to stare at this slowly rotating throbber for the next five minutes! :slightly_smiling_face: "

To give a specific example, I was recently trying to shut down a machine with a faulty charging circuit that I was worried might literally catch fire as it started firing ozone out the back of it, but I didn’t want to corrupt the SSD on it. A normal shutdown only takes about 15 to 45 seconds on it, so that would’ve been fine, but instead it started running an update on Chromium or something in the background and refused to shut down, so after three minutes I just forced the power off and risked corruption of the SSD to avoid a literal potential explosion because of the snap system forcing me to install an update I did not need or want at that moment. Now, I know, the developers here will say “well that’s just an edge case! That’s not going to happen for everyone!” And sure, it’s not. But designing software means accounting for edge cases, and if your solution to edge cases is "don’t have them! :grin: " Then you’ve made bad software.

Anyway, this is going to fall on deaf ears, just like the dozens upon dozens of requests for this feature before, and I’ll probably just get booted from this forum for “not being constructive,” but, frankly, I’m pretty upset, and I wanted to put this in a place where maybe a few developers of this software will see it. Again, this attitude is arrogant. Pure and simple. There are legitimate reasons to want to have control over exactly when and how a system updates, and claiming "well we can’t give the users control of this or they might do it wrong! :frowning: " is insulting to the entire community, and I know I’m far from the only person who thinks so, as the diaspora of Ubuntu users to other distributions has shown, and will continue to show.

It was just one example, but way to attack the example rather than the point.

EDIT: looks like the post was withdrawn, never mind.

They specifically make a post discussing the possibilty of implementing the specific feature, IMHO that’s far from being arrogant. :slight_smile:

I believe that is a point for Free Software, not open source software. :wink:

Also, this also doesn’t grant software user authority over the upstream’s design decision, if one really don’t like it one would fork it and implement an option right away.

Have you tried pressing Ctrl + Alt + Delete 7 times in a row in a short period? That should workaround the problem :). Also, there’s Magic SysRq key at your disposal.

There is a reason why the developers are hesitated in giving the option, and I fully respect that while allowing them for seeking the possibilities to mitigate the impact.

Just as they specifically made a post for discussing disabling auto-updates, but do not respond to inquiries and concerns made in that post, just as in this post? “Making a post and then ignoring it” is not the same as addressing the issue, it’s deliberately to blackhole conversation for it.

“If one does not like it then they can fork it” does not work when half of the software is proprietary and in tandem with internal design decisions. Also, since when has “just fork it” really worked as an argument to a platform software of this kind?

1 Like

Yeah, that’s pretty much the arrogant, condescending attitude I expected from this community. Not sure why I commented in the first place, in retrospect.

Well, this topic is about implementing desktop integration for the multiple update control mechanisms that snapd provides, it is not a debate on principles of snapd.

if you face issues with shutdown, this is a bug, snapd should gracefully stop a running update when a sutdown signal comes … i do not see it ever behaving that way and i run a lot of machines over here, you should definitely open a new topic in the snapd category and provide logs and info so this bug can be fixed and you do not get annoyed by it anymore … i think for the gist of “lets discuss how we better integrate snapds update control with the desktop” you are a bit off-topic though …

there are plenty of other threads where the base principles of snap updates are being discussed, this is not one of them. turning every technical discussion into a complaint over basic snap principles does not really help to get the actual topic forward.


This is literally a topic about whether or not the snap desktop client should allow people to disable automatic updates. I provided a concrete example of how I had a problem with an automatic update. How is that unrelated? Actually, on second thought, I don’t care. I’m out. I shouldn’t have made an account here to post at all, I don’t know what I expected. This entire community’s attitude towards allowing users to have control over what they have installed has always been the same, arrogant position, and trying to argue about it here was a mistake. I’m just going to mute this and forget I made an account here.

You mean this one?

Not agree with the inquiry != Do not respond the inquiry

I agree, however the API is available so anyone with enough motivation should be able to make a compatible Snap Store and, convince all the stakeholders to use it.

Grammarly disagrees with you :wink:

1 Like

please re-read alans original post at the top, it is about exposing the features from:

to desktop users, nothing more. fundamental changes in behaviour of snaps need to be discussed for snapd itself, not in a desktop integration thread. there are already existing threads (linked above from several posts) that discuss this.

this thread is not about permanently disabling updates but about refresh.timer, refresh.hold, refresh.metered and refresh.retain exposure via the UI plus desktop notification integration of snapd.

and again: regarding your “example” that snapd slows/stalls shutdown, pretty please file a bug or open a thread in the snapd category and provide the logs you get asked for, since it is a bug.

this is unexpected behaviour that needs to be fixed.


I very much disagree. I cannot speak for @popey but it is clear to me this thread is about tweaking update control to better fit desktop users. Part of this is creating a GUI. Part of this is creating more options tailored towards desktop users. As an example from the original post:

The ability to completely switch off automatic refreshes is not possible via the CLI. This is a new feature. Many replies on this thread discuss what update control features should be added to better support desktop users. As an example, my proposal from the third post:

This is clearly the correct place to discuss the pains of the current update control limitations on the desktop. I do not agree with @imoutthiswasamistake’s tone, but that does not remove from the fact that this thread is the correct place to discuss those matters.

@imoutthiswasamistake’s tone should also not distract us from the message:

  • The current restrictions are very unpopular and have a number of unaddressed issues, like when you require a quick shutdown on the desktop.
  • Although this thread was started with the best of intentions, it seems as if it has gotten nowhere. Five months after the thread started, there has been no communication about any plans to address the issues.

Let us focus on the message instead of the tone. If @imoutthiswasamistake’s tone does not improve, then by all means use admin tools to prevent further abuse. Continuously discussing their tone, however, prevents us from actually solving the issues presented in this (and many other) threads.