Disabling automatic refresh for snap from store

Your response would seem as if it were written by someone who hadn’t actually read through the rather voluminous previous parts to this conversation.

@marekhwd What is desired is ability to switch it off.

@Ads20000 I understand that, so what, exactly, is wrong about the snappy developers not providing a simple, global, off >switch for automatic updates? Is your argument that it is wrong sound?

The answer to your first question lies in the many requests from other long term devs on other projects that have advanced quite a few reasons - - - none of which trump management decisions.
Your second question shows faulty logic. You don’t even say that the argument is wrong and you present no reasons - - - - just by your position (which is really not clear that it is anything official) you state that the argument is wrong.

@Ads20000 No worries, if you can’t deal with the status quo on this issue then that is the correct action to >take  ‘not >respecting what user wants’ isn’t that true of every piece of software, though, because no piece of >software >has an infinite number of toggles so that the user can tweak the software to do exactly what they >want it to do?

Your posit here is actually quite amusing. Somehow you are suggesting that every piece of software is infinite. Would love to hear your argument for that - - - but - - - as that posit is quite patently false the requester’s ask for a toggle is not negated.

1 Like

I’m locking this thread for a while. Please be nice to each other. It’s possible to disagree with people’s opinions without being disagreeable.

2 Likes

I live in a very poor country, I have a mobile data connection which is very very expensive and limited. I just installed Ubuntu 18.04 and almost instantaneously I was shocked because snapd was consuming all my data plan. So my question is, can I stop snapd from eating my data connection?

I am trying to be very polite, but honestly after reading this thread I am feeling very frustrated about the way this issue had been handled by the dev team. I am in a huge need for a definite solution and not just a temporal one. Do I need to remove snapd from my system?

2 Likes

This has been covered in this topic and the one about metered connections:
In 18.04, in the network settings, make sure you’ve told it that the network is metered.
Then, tell snapd to not refresh on metered, via snap set system refresh.metered=hold.

Thanks for the quick response. However if I understand correctly. the above is not going to stop snapd for automatically update it self in the long run? Is this true?

yes, of course. It gives you control over when that update happens (you can also change the refresh frequency, if you’re never not metered for example maybe it’d be best if you just set the refresh to be every 2 months or something).

Ok, thanks again for the quick reply, best!

Suerte!

Refer Keeping snaps up to date - Documentation for snaps: Universal Linux packages for more info regarding to customizing the snap refresh schedule.

You can defer snap refreshes until you have unlimited internet access, note that even you defer it there’s still a time limit where snapd will force upgrading all the snaps IIRC.

I read this topic. But I could not understand if the issue resolved.

On some other topic writes that “snap set system refresh.metered=hold” works. But I could not get if it works only for current network or not?! :frowning:

Note: I don’t trust canonical, I don’t trust snap platform too. I don’t want to install docker to whole system. The only reason for me to use the snap is that: official docker package is available as snap.

Snap is coming default installed on LTS of Ubuntu. can you think a software which start auto update and never stops? If it is canonical’s, so yes possible. They are doing this only because they are getting informations (statistics/telemetry) from their users. Nothing else.

Nothing is impossible. I am developer too. To disable/enable auto update can not be so difficult (at least with a manual config). This is completely a game. they are telling that the system is open source… only fools can believe this.

google, mozilla, canonical, open source killers…

1 Like

This configuration only works for “metered networks”, like tethered mobile network sharing that is detectable by NetworkManager via some de facto standards. You can verify if your network is metered or not by running the nmcli command.

As @Lin-Buo-Ren says, it only works for metered connections, but you can use the snap set system refresh.timer= command to hold back updates.

Yes: Chrome (on Windows), Firefox (on Windows), Chrome OS

Can you prove this statement? Personally I quite like automatic background refreshes, it means my software is fresh and secure on any version of Ubuntu (and some other operating systems) without me needing to do anything! :smiley: :smiley:

The snappy store is not open-source, everything else is. If you’re a developer and know Go then you’re very welcome to fork snappy to implement the changes you want (it’s licensed under the GNU General Public License v3.0 and the source code is available here). Indeed, some work has previously been done on implementing an alternative store (to resolve the perceived issues raised regarding External repositories).

1 Like

What about playing around the refresh.timer to give it an unreachable day through setting a cronjob :
0 0 */5 * * /usr/bin/snap set system refresh.timer=$(/bin/date --date "-1 days" +%a | /usr/bin/tr '[:upper:]' '[:lower:]')

or downloading a snap and installing it without the .assert file.

It’s trivial to disable auto-updates on those platforms. Each of them includes a simple “do not automatically apply updates” option. In my mind, that disqualifies every one of them as a valid example.

1 Like

It’s been almost two years (and ~200 comments) since I originally participated in this discussion. At work, we are once again doing some evaluations of how we package and distribute software for some of our platforms and how we manage some of our systems, and snappy still strikes me as having a lot of great potential for us.

Unfortunately, I see that this is still an unresolved request, and after reading through the comments, it seems pretty clear that a simple method of supporting manual updates (and disabling forced automatic updates) is never going to happen. I could go through and explain our internal processes and some of the contractual and regulatory requirements that require us to certify systems and not make changes to them for set periods of time (and yes, they’re typically greater than 60 days). I could explain the process we go through to secure the systems and mitigate the risks. I could discuss how the various teams managing the platforms need to careful plan and schedule their upgrades and changes on their own timelines, separate from when updates are pushed by developers.

But, it isn’t really going to make a difference, is it?

You want to force a strict update process that matches your idea of how things should be done, and I’m just interested in what seems to be the best available cross-distribution software packaging system. . . and in managing my systems.

The simple fact is that for my use case (and many others), this lack of functionality makes an otherwise really useful piece of software into a simple non-starter. It just can’t meet my requirements. And no, I’m not willing to muck with firewall rules to work around it, and I’m really not going to work around this snappy limitation through additional software like the (proprietary) proxy (I’m not interested in dealing with the additional overhead and complexity there).

From the discussion, it appears that the bar for evidence to justify a straightforward option to disable auto-updates has been raised higher with every request for the feature, and it doesn’t look like it’s ever going to be met. I concur with a few previous suggestions: at this point, after more than two years, the request should probably just be closed as “won’t fix” so people can realize that it’s not going to happen.

I still really like most of the ideas and technology behind snappy, but I can’t compromise on one point: I am the one that know what’s best for my systems. And, as I am the one responsible for them, I will always need the ability to control them, including updates. We’re not willing to risk our systems and our revenue on unexpected or uncontrolled software changes. End of discussion.

It’s interesting that I can’t think of any other single platform anywhere that has taken such an overbearing and high-handed approach to updates. Not one. Perhaps there are good reasons why that is?

Regardless, congratulations on the very cool technology you’ve produced. I just wish it didn’t come with such forced ideology.

11 Likes

I think I just had a realization. Perhaps my frustration is my fault, in that I was trying to look at snappy as a truly universal cross-distribution software packaging system. That seemed like the goal to me.

Now, however, after reading some of the comments on External repositories, I think I see my mistake and misunderstanding. Snappy isn’t the universal cross-distribution software packaging system I was looking for. It’s the cross-distribution end-user-focused software app store I wasn’t looking for.

I’m approaching this from the IT professional and system administration perspective, and trying to solve enterprise system and software distribution/management/update problems. I thought I could make Snappy fit into that, but I now suspect that I was wrong, and that Snappy doesn’t actually care about my problems (at least not if they in any way conflict with the goals of being an end-user focused app store (with an excessively strictly enforced update ideology)). Perhaps I’m not the only one to make this mistake?

I would never put Snappy on any server I’m responsible for because the current design is broken from an enterprise system administration perspective (at least, it is to me). However, from a user desktop or laptop perspective, Snappy’s forced updates are maybe (slightly) less obnoxious.

I still fundamentally disagree with the update stance (see previous comment about not being able to think of any single platform that is so determined to force its views on updates on people), but since it seems intended for a different use-case than mine, I’ll just move along and focus on alternatives that fit professional systems engineers better.

5 Likes

Experienced system administrator here. It’s crucial for me to keep my systems running. I don’t want nor need to auto-update snaps which could potentially introduce critical bugs and require manual interaction to fix them (not always possible without causing downtime).
Please provide a way to (optionally) disable snap updates.

5 Likes

I spoke to one of the Canonical sales rep about this and he told me the suggested approach is to pay for a branded store (currently 15K per year) where you control all the snaps in it and when they get released. This should solve the problem for critical (i.e. commercial) solutions that need to have tight control (when updates get released) over their systems. Am I missing something? or is this discussion more about the principle (FOSS etc)?
I didn’t see mention of this fact in this thread so I’m adding it to make it more visible as it seems to solve the practical problem

EDIT:
my conversation with the canonical sales rep was in a commercial context. I don’t know anything about a branded store for an opensource/community project