Hacker News Reader

Comment by mesebrec | Hacker News Reader

Snaps don't update when the app is running. I don't know what happened here, but it seems the problem might be somewhere else.

View on HN

That's a fairly recent addition, after a very long time without any notifications and abysmal handling of a running application. These issues were handled slow and dismissively, the current solution is still half-baked. It's yet another good example how bad Snap is.

If that goes on for 2 weeks, doesn't it kill the app and update anyway?

If you ignore the notifications for two weeks, yes. But you even get a notification at least four hours before updating saying you have little time left.

That said, if you run `snap hold firefox`, it will wait indefinitely.

Not updating isn't a solution. What works for me is a systemd service that does a snap refresh on boot. At least I have some controll on when it updates.

I know it is simple to do, but care to share the unit file?

It's the most basic file possible but it does it's job.

cat /etc/systemd/system/upgrade-system.service

  [Unit]
  After=network-online.target

  [Service]
  ExecStart=/bin/bash -c '/usr/bin/snap refresh && apt update && apt upgrade -y'

  [Install]
  WantedBy=default.target

The problem is that the dialog says to quit the application so snap can update, but snap doesn't do that. It checks a few times a day and bails if the application is running. It doesn't wait for the application to exit and then update, like the dialog indicates it would.

Thus you quit the Firefox, wait a few minutes, assume it has been updated because why shouldn't it, and after two weeks it gets killed mid-session.

Completely inexcusable UX...

I've encountered this exact issue: It kept bugging me to close firefox so that I can update. I closed it. Then I relaunched it and the message popped up again. I repeated this process for a couple of days until I gave up, uninstalled snap, and installed flatpak.

Issues like this are present in a lot of highly-opinionated software; they become utterly unusable when used in a way that deviates from the dev's ideal vision, or ways they plain just refuse to support. Configurability and transparency is almost always a good thing in software. It seems that some Devs will have to relearn this lesson the hard way.

For the record, the solution to this is to run "snap refresh" manually right after you exit Firefox.

Are you the same people who bitched when Win10 just restarted to install updates?

Yes this comment has a little malice in it.

What do you mean "just" restarted? Isn't killing one single program a subset of what happens when your computer restarts? And isn't 2 weeks a lot more lead time than Windows gives you?

Auto updating is only one of the multiple problems Snaps create. Read the other comments here to see many of them.

I can't wait for Snaps to crash, burn and die.

it is extremely hard to disable or remove tracking or auto-update stuff on ubuntu.

(snapd, unattended-upgrades, ubuntu-report, whoopsie, ubuntu-advantage-tools, motd and more)

You turn automatic snap updates off by running `snap hold`.

You shouldn't be disabling unattended-upgrades unless you're very diligent with security updates yourself.

> You shouldn't be disabling unattended-upgrades unless you're very diligent with security updates yourself.

That statement might be true regarding some users.

But for many Linux users and installations, it's false.

Why is it false? Those security updates are important and it's very nonintrusive.

> Why is it false? Those security updates are important and it's very nonintrusive.

Not sure if this is a complete list, but here are some of my reasons:

a) It's common for updates to contain a mix of security-fixes and other stuff. Sometimes that "other stuff" breaks things and/or needs vetting for deployed systems.

b) Sometimes even "security fixes" break stuff. (I don't have the time to find examples, so feel free to take this with a grain of salt.)

c) Sometimes a forced restart of the system or a program is worse than a delayed update. For example, when giving a presentation, or when firefighting a production issue.

d) It's absolutely an attractive attack vector. I want time to hear about problems before installing updates.

And finally, this might not resonate with everyone, but:

e) It's my system. Nobody else gets to override my choices for how it runs. Full stop. I refuse to cede my agency in this area of computing.

> It's common for updates to contain a mix of security-fixes and other stuff. Sometimes that "other stuff" breaks things and/or needs vetting for deployed systems.

So you have no experience with unattended-upgrades. They really don't contain new features, that's not how Debian's model works - they backport security fixes to keep features the same.

> Sometimes a forced restart of the system or a program is worse than a delayed update. For example, when giving a presentation, or when firefighting a production issue.

Again, you have no clue how Debian/APT updates work. Things don't just get forcefully restarted.

> It's absolutely an attractive attack vector. I want time to hear about problems before installing updates.

Unpatched software is significantly more so than attacking your distribution.

> e) It's my system. Nobody else gets to override my choices for how it runs. Full stop. I refuse to cede my agency in this area of computing.

Sure, feel free to do with yours as you please, but don't recommend terrible things to others, especially those not as proficient.

It's bad advice for most end-users and sysadmins to get rid of unattended-upgrades especially for the FUD reasons listed above.

It sounds like there's some confusion here.

I was talking about Snap, not APT.

come on, this is like gassing up your car.

Yes every once in a while you see some person on the side of the road who forgot to fill up with gas.

But is the answer to force everyone to pull over and gas up every 4 hours?

(yes, this is an imperfect analogy, but you get the idea)

That's not how unattended-upgrades works at all. It's not Snap.

Reply on news.ycombinator.com