[WIP] Refresh App Awareness

I just noticed that telegram was failing to download attachments in the usual way that indicated it was refreshed while running:

[1921659.491083] audit: type=1400 audit(1591279662.027:1005541): apparmor="DENIED" operation="mkdir" profile="snap.telegram-desktop.telegram-desktop" name="/home/laney/snap/telegram-desktop/1616/" pid=81570 comm="telegram-deskto" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

but I have refresh-app-awareness on:

laney@raleigh> sudo snap get core experimental.refresh-app-awareness
true

yet snapd did indeed refresh telegram:

laney@raleigh> snap info telegram-desktop
...
tracking:     latest/stable
refresh-date: 4 days ago, at 16:31 BST

the process accounting seems to be working though

laney@raleigh> snap refresh telegram-desktop --edge
error: cannot refresh "telegram-desktop": snap "telegram-desktop" has running apps

here’s my versions of stuff

snap    2.45
snapd   2.45
series  16
ubuntu  20.04
kernel  5.4.0-29-generic

anything I can usefully do to see what happened? Or maybe the above referenced project means that this is still under active development and it’s better to try a new version.

We do refresh after a week though.

There’s a snap warning in 2.45 (or 2.46, I forgot which), that tells you about force-refresh if it happens.

Ah right, so I guess the most this feature can do for long running processes is put the annoyance off for a week.

2 Likes

We are going to discuss changing the duration period. I was thinking it should be much larger, similar to the length of the snap refresh hold period, aka ~60 days. Details will be available later today.

We’re also looking at enabling this by default in the next release, perhaps.

4 Likes

Apologies for infrequent updates. Over the past few weeks we’ve discussed that the next steps in making this feature available involve:

  • Displaying desktop notifications to the user, making them aware of the pending refresh
  • Increasing the grace period for which an app can block the refresh process for up to two weeks

We are lining up pieces to complete this for the next release. We will again gather feedback and would hope to enable this new behavior by default for the release after that.

There are still several technical changes needed to enable this option by default, those are being worked on but are unlikely to hit this milestone. From the top of my head, changes to SElinux policy relevant to the tracking mechanism, changes to the snapd test suite to accommodate the new behavior and some additional logic related to run inhibition locks that is under review and development.

2 Likes

I’m sure this was discussed, but please keep in mind that an unprivileged user (eg, without snap login, sudo, etc) is in a position to prevent refresh via the refresh app awareness mechanism. I mention this only so this aspect of auto-refresh awareness is kept in mind (I’m not saying that two weeks is too long, but it feels like we might be getting close to too long).

I’ll also mention that of course simply informative desktop notifications are fine, but as soon as we want to do something more interactive, please incorporate policykit/etc to mediate any controlling of the refresh process so that unprivileged users can’t do more than they should.

Lastly, thanks for all your work on this!

1 Like

Two weeks was specifically picked to be longer than one week, so that users are not surprised by something that may have happened over weekend.

I acknowledge the need for policykit. The current plan is to not do any interaction yet. The next plan will be to implement remaining snapctl design, to allow application to be notified the same way the user is, and to allow them to act on it by requesting an update after the process quits.

2 Likes

Refresh app awareness has landed in master and should be available in edge soon. Please try it by enabling the experimental feature:

sudo snap set system experimental.refresh-app-awareness true

Please share your thoughts about the experience.

2 Likes

Thanks! Should we unset the experimental variable documented in the original post before trying this?

(And good luck in your future endeavours when you leave the team!)

1 Like

They are one and the same. Internally we map core and system to the same thing.

Great. Thanks. This has worked for my use case. However, I tend to reboot at least nightly so don’t have any very long running applications. It’ll be interesting to hear the experiences of those who do.

1 Like

Some feedback on the desktop notifications associated with refresh awareness I’ve seen so far:

  1. If you leave a system locked over the weekend (or holiday), multiple notifications for each open app can be posted. Ideally the new notification would update/replace the old one. This may be easier when we add support for the GNOME 3 notifications API, but is certainly possible with FDO notifications.

  2. On the GNOME lock screen, notifications are displayed in a redacted form. For snaps without icons, the notification is pretty useless:

    image

    The lack of an application name is probably due to the io.snapcraft.SessionAgent desktop file not being present on the host system, which should resolve itself when a deb release containing that file is released.

    We probably want to associate an icon with that desktop file too, but I’m not sure what icon to use. It’s not clear that the Snapcraft bird logo is the best choice, since that isn’t necessarily what users would associate with package management.

  3. The Snap Store continues running in the background when you close the window, with the same instance redisplaying the next time the user opens it. Ordinary users aren’t likely to know how to quit out of the app if they get a refresh notification for it.

    It’s not obvious that converting the main snap-store process to use D-Bus activation (and hence killable via systemd service control) would handle this case. It would be okay to automatically kill the process while the gnome-software window is not visible, but should not happen when one is visible.

  4. Desktop notifications are posted even if the running processes are not owned by the user. The request to post a notification should only be sent to the session agents belonging to users owning the blocking processes.

Instead of notifications, what if there was an indicator (“tray”) icon showing that the updates are available?

(Edit: I understand: easier said than done :slight_smile: I meant it as a suggestion for future plans.)

you mean like:

That’s probably partly what gave me the idea. But I don’t know if it needs to be an always visible icon, at least by default.

thanks for posting this collated feedback

Been testing this for a while now after experiencing problems with Jetbrains IDEs and it works pretty well.

The only minor annoyance is that if I quit and immediately restart, the app isn’t actually updated. Then after a while I get the notification again. Seems like it would not be a problem to install the new version in the background automatically, but just keep the old version installed until I quit it. If that is how it is supposed to work already, then there is a problem somewhere.

2 Likes

Agreed. I’ve thought about editing the .desktop files for VS Code (and maybe Chromium) to call snap update code before launching. Since I rarely close and relaunch it, I wouldn’t see the delay much. (Chromium would be worse.)

@pedronis what is the timeline for marking this feature stable and enabling it by default?

I am asking because users of the chromium snap are still being bitten by this (as shown by the growing number of duplicates for bug #1616650).

4 Likes

@jamesh is helping us trying to improve some of the issues with the associated notifications, once that is taken care we can consider making it not experimental anymore. We all want this enabled as soon as possible.

2 Likes