How to disable snapd update notifications permanently

Hi there,

I’ll be the first to admit that I’m not a huge fan of snaps. In my expericence they are annoying and obtrusive to the user.

One particular thing that makes me angry every single time is the “Close the app to avoid disruption (x days remaining)” notification which seems to pop up CONSTANTLY in my system, always to the most inconvenient times. I’m okay with snap holding off updates until I close the “app”, but I want it to STFU about the “grace time” it is giving me. I want to disable this permanently.

I’ve looked at the snapd source code, but am not experienced in Go and therefore found out that the message is triggered by a REST API call, but I could not locate any conditional that would allow this message notification to be disabled. Is this indeed true or is there some way to remove the message?

At this point I’m irritated enough to rip out all of snapd and install my browser manually just to avoid the hassle.

Thanks, Rob

2 Likes

Not sure what desktop environment you are using, but in GNOME you should be able to go to Settings > Notifications > Snapd User Session Agent and turn them off from there.

2 Likes

I agree the messages are annoying, but if you ignore/silence them the snap will eventually be updated out from under the running app with no warning, which rarely ends well. If you start getting very random errors from the app, you probably ran into snap confinement issues due to the update that was forced upon you and you’ll need to restart the app. As a result, you might consider making use of the refresh timer configuration as well which could improve things a little.

Not sure what desktop environment you are using, but in GNOME you should be able to go to Settings > Notifications > Snapd User Session Agent and turn them off from there.

Hi, thanks… unfortunately I’m on Mate and there isn’t any such menu.

That’s a great point actually.

What I would like, ideally is: If the application is closed, snap may update away. If it’s open, never update. I think this whole “ultimatum” thing is ridiculous (“close your browser or else”) and exceptionally obtrusive. Replacing a binary without consent is horrific and downright hostile.

Especially since for a web browser, there is a small window of opportunity that snap always seems to miss (just booted up, but browser not started yet). Then, obviously, the browser is open as long as my computer is on and it cannot update.

Maybe I’ll just use the workaround to disable updates entirely by blackholing the snapcraft URI to 127.0.0.1. Or get rid of snapd completely. I don’t think it can be made to behave the way I want it to behave.

2 Likes

I agree, my usage is the same. I literally always have both the browser and vscode open. If snapd misses the opportunity to update them, I rarely am willing to close either because I always have something important going on.

Well put. Although to be fair, while I refuse to consume my web browser in particular via snap, firefox is just as bad through apt security updates (which I have configured to apply automatically). Every once in a while it’ll update in the background and then refuse to open new tabs until I restart the entire application. A very silly way to write software, in my opinion. But at least I can disable those automatic updates; with snaps you can’t.

There isn’t even any need for snapd to wait for the program to close. It always keeps two versions of the snap installed: the current version and the previous version. The problem only happens if two updates get installed while the program is running.

So this can be trivially fixed by changing it so that instead of keeping the two most recent versions installed, it keeps the most recent version and whatever version is currently running. Which it knows, because that’s how it knows to show a popup.

This was pointed out several years ago on the thread where the update notifications were initially tested, but so far nothing has been done to fix it.

I don’t believe that’s true. If memory serves, this feature was originally developed because, when an update happens, snapd updates its profiles for the new revision and applies them to the running process. So for example, if your application was writing data into /var/snap/<snap name>/1234, it suddenly no longer has permission to write there, because the profile was rewritten to allow access to /var/snap/<snap name>/1235. Thus the running process will start throwing errors whining about a lack of permission. Any update that happens while your application is running will cause that problem to occur, assuming the application in question is writing any data.

So it is indeed rather important for snapd to wait for the application to prevent the update from interfering with the confinement of said application.

1 Like

Perhaps that was the intention but in practice it is not how snaps work at all. If a snap is reading from /snap/<snap name>/1235 then it will continue to do so as long as that directory still exists. If the snap is updated (version 1236) then that directory will continue to exist and the app will continue to work. If it is updated a second time (version 1237) that directory gets deleted and the app will simply crash with a “file not found” failure if it attempts to read or write it.

This is the exact problem that Refresh Awareness was supposed to fix - except it doesn’t. It just delays it.

This fix for this is incredibly simple: only inhibit installation and show the popup if the currently running version is the older of the two installed versions. That way, when you quit and restart, the newer installed version will run.

I’m afraid that’s not true, which was the whole point of my post: that directory is no longer accessible under the new confinement profile after the refresh occurs. It doesn’t matter if it exists or not.

Then why do programs only crash after the second update?

That’s not actually my experience. Any chance you’re using a non-Ubuntu system that actually runs snaps in a degraded security state (e.g. without apparmor)? Debian, perhaps?

No, I am using Ubuntu. Here is a bug report against pycharm for this exact error: https://youtrack.jetbrains.com/issue/IDEA-257508/

Ah, that’s classically-confined, which means it’s virtually unconfined. For classic confinement, you’re correct: it will continue to work until the directory is removed. That is an exception to the rule, though, not how snaps work in general.