"Close the app to avoid disruptions" for a closed app

Periodically I’m getting this notification.


I can reproduce this by simply running snap refresh. There is indeed an update pending:

alan@ziggy:~$ snap refresh --list
Name       Version  Rev   Size  Publisher   Notes
snapcraft  7.3.1    8931  66MB  canonical✓  classic

snapcraft isn’t running.

alan@ziggy:~$ ps aux | grep snapcraft
alan      435432  0.0  0.0   9076  2304 pts/5    S+   15:57   0:00 grep --color=auto snapcraft

What gives?

a plain snap refresh (without --list) should actually print out the PID of the blocking process …

It didn’t. But now it randomly works where it previously didn’t. I changed nothing.

alan@ziggy:~$ snap changes
ID   Status  Spawn                   Ready                   Summary
105  Done    yesterday at 17:17 GMT  yesterday at 17:17 GMT  Refresh "x16emu" snap
106  Done    today at 11:44 GMT      today at 11:45 GMT      Install "mailspring" snap
107  Done    today at 14:37 GMT      today at 14:37 GMT      Auto-refresh snap "core18"
108  Done    today at 14:45 GMT      today at 14:45 GMT      Refresh all snaps: no updates
109  Done    today at 14:45 GMT      today at 14:45 GMT      Refresh all snaps: no updates
110  Done    today at 15:57 GMT      today at 15:57 GMT      Refresh all snaps: no updates
111  Done    today at 16:55 GMT      today at 16:55 GMT      Refresh snap "snapcraft"
112  Done    today at 16:56 GMT      today at 16:56 GMT      Refresh all snaps: no updates

Thinking about it, while this shouldn’t make any difference, when I was trying earlier (those changes at 108, 109, 110, i was doing snap refresh in the terminal, and then typing my password in the desktop popup.

When it worked, on change 111, I’d done *sudo* snap refresh. I can’t reproduce that right now, but that’s all I can think that differed in the 20 mins between my first post and you replying. :thinking:

Hi. My guess is that snapcraft starts other processes that stick around after it closes. Snapd checks if a snap is running by looking for its cgroup scope, so if there a snap leaves processes hanging after it exits, the snap is thought to be running. If you could, when this happens again, please run systemctl status and look for a snap scope named something like “snap.snapcraft.*.scope”. If you find anything, please copy the entries under that scope and paste them here. That would help us confirm this hypothesis.


1 Like

The only things we identified as blocking snapcraft from updating:

  • running a build at the time
  • signing; we use snapd to sign and it starts a gpg-agent which never goes away

The former is valid use case, the latter is someone of a bug; @pedronis any update on how we should work this one out?

I wasn’t doing either of those. I’d only use snapcraft to do remote builds. Maybe there is something lurking from those?

Perhaps try and reproduce (revert snapcraft, do remote build) and and see what comes up by looking at cgroup scope

Sadly I already removed snapcraft from the machine, so i cannot revert, and snap doesn’t allow me to install an older version. The only way I can see to do this, I suspect is to install snapcraft from the edge channel, run it, and wait for an update.

@ernestl - see nothing about cgroups scope checking in your link?

Apologies, incorrect link. I meant to refer to this comment: "Close the app to avoid disruptions" for a closed app