[lunar] Snaps don't launch due to cgroup issue

[Francois Thirioux]

Hi,

Lunar up to date, Intel+Nvidia GPUs, Ubuntu Wayland or X11 session, hybrid or discrete graphics.

If I click on a snap dash icon, nothing happens.
Tested with Thunderbird, Firefox, Shortwave...
(VS Code seems ok, maybe due to classic confinment?)

I can launch without issue Chrome (deb), Synaptic, GNOME apps, etc.

Recent updates included gnome-shell and libadwaita.

---

I get this type of log for all problematic snaps:

/user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-shortwave_shortwave-11885.scope is not a snap cgroup

---

Context:

$ snap --version
snap 2.58.3+23.04ubuntu1
snapd 2.58.3+23.04ubuntu1
series 16
ubuntu 23.04
kernel 6.1.0-16-generic

$ snap list
Nom Version Révision Suivi Éditeur Notes
bare 1.0 5 latest/stable canonical✓ base
code ee2b180d 122 latest/stable vscode✓ classic
core 16-2.58.2 14784 latest/stable canonical✓ core
core18 20230308 2714 latest/stable canonical✓ base
core20 20230207 1828 latest/stable canonical✓ base
core22 20230210 522 latest/stable canonical✓ base
firefox 111.0-2 2432 latest/candidate mozilla✓ -
gimp 2.10.30 393 latest/stable snapcrafters -
gnome-3-28-1804 3.28.0-19-g98f9e67.98f9e67 161 latest/stable canonical✓ -
gnome-3-38-2004 0+git.6f39565 119 latest/stable canonical✓ -
gnome-42-2204 0+git.09673a5 65 latest/stable canonical✓ -
gtk-common-themes 0.1-81-g442e511 1535 latest/stable/… canonical✓ -
gtk-theme-pocillo 0.14.4.1 5 latest/stable ubuntubudgie -
gtk-theme-qogirbudgie 22.04.1 8 latest/stable ubuntubudgie -
gtk2-common-themes 0.1 13 latest/stable canonical✓ -
hunspell-dictionaries-1-7-2004 1.7-20.04+pkg-6fd6 2 latest/stable brlin -
kde-frameworks-5-91-qt-5-15-3-core20 5.91.0 1 latest/stable kde✓ -
kde-frameworks-5-99-qt-5-15-7-core20 5.99.0 15 latest/stable kde✓ -
kde-frameworks-5-core18 5.67.0 35 latest/stable kde✓ -
libreoffice 7.5.1.2 270 latest/stable canonical✓ -
shortwave 3.0.0 79 latest/stable alexmurray✪ -
snapd 2.58.2 18357 latest/stable canonical✓ snapd
snapd-desktop-integration 0.1 71 latest/stable/… canonical✓ -
stellarium-daily v1.2 1396 latest/stable t4saha -
thunderbird 102.9.0-1 305 latest/candidate canonical✓ -
vlc 3.0.18 3078 latest/stable videolan✓ -

[Idarktemplar (idarktemplar)]

SUMMARY
Since cgroup is created in kio after process startup, there is a race condition present if started process forks and starts some children before cgroup creation is processed.

Currently, situation sometimes, depending on various circumstances, may be following:
1. kio starts new process via KProcessRunner class.
2. Started process runs and forks, creating one or more children.
3. kio creates new cgroup and puts started process to this new cgroup. All children created by started process stay in current cgroup.

STEPS TO REPRODUCE
1. Try starting via KProcessRunner class applications which fork soon after launch.
Modern firefox, for example.
If application forks and parent exits, it's even better.

OBSERVED RESULT
Sometimes created cgroup would contain only parent process without any it's children. If parent process quits, it may result even into an empty cgroup. Children of launched process would be left in the cgroup of parent of launched process. Should not be reliably reproducible.

EXPECTED RESULT
Cgroup should contain both started process and all it's children reliably.

ADDITIONAL INFORMATION
I did not try reproducing it.

Currently, cgroup created when process is already running, and if this process creates some children fast, it may lead to described issue. Here's the link to code:

https://invent.kde.org/frameworks/kio/-/blob/8d6b306f585920230acecd19903325f6f0387b8e/src/gui/kprocessrunner.cpp#L226

Function 'registerCGroup()' is called in 'KProcessRunner::slotProcessStarted()' slot, which is invoked after process started, within some undetermined timeframe.

In my opinion, proper way to start process in new cgroup in order to fix this issue looks like following:
1. KProcessRunner forks.
2. Fork sets up cgroup, puts itself into it, waits until it's confirmed that OS finished moving it into new cgroup. Optionally between forking and setting up cgroup, it may exec into some helper which would setup cgroup.
3. Fork (or helper used to setup cgroup, if one is used) execs into the new process. Since it's already running in new cgroup before exec, when new process is started it's already contained in new cgroup, and even if first thing it does is fork() call, all children would be contained in that new cgroup as well, without any race conditions.

AFAIK, systemd-run actually setups cgroup and reliably puts requested process and all it's children into newly created cgroup, but I might be wrong. Not sure which interfaces are available from systemd via dbus or some library for starting process similarly to systemd-run.

[U26 (u26)]

There is a theoretical race, yes.

The landed patch was a somewhat "lite" and invasive version of introducing the concept.

What you describe is how systemd-run does it.

But there's a much simpler solution, we can just use startTransientService(execLine) instead of startTransientScope(somePid) then it all becomes someone else's problem.

See:

https://invent.kde.org/frameworks/kio/-/merge_requests/71

[Idarktemplar (idarktemplar)]

(In reply to David Edmundson from comment #1)
> There is a theoretical race, yes.
>
> The landed patch was a somewhat "lite" and invasive version of introducing
> the concept.
>
> What you describe is how systemd-run does it.
>
> But there's a much simpler solution, we can just use
> startTransientService(execLine) instead of startTransientScope(somePid) then
> it all becomes someone else's problem.
>
> See:
>
> https://invent.kde.org/frameworks/kio/-/merge_requests/71

I've looked a bit at this merge request and it looks like it should fix this issue. And it should also allow to implement later something like CgroupV2ProcessRunner for systems with no systemd.

[Francois Thirioux (fthx)]

https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mike Adams (mikethebos)]

Interestingly, launching via snap run works, but not through GNOME.

[Francois Thirioux (fthx)]

In terminal with the direct app name too.
Seems random. Sometimes I can launch FF or any from dash.

[Francois Thirioux (fthx)]

Seems to be gone with core22 snap update.
Needs to be confirmed as solved by another user.

[Francois Thirioux (fthx)]

I still do experience some oddities (black window at start-up for TB, ...).

[Mike Adams (mikethebos)]

The bug is still present for me on core22 v20230304.

[Francois Thirioux (fthx)]

Yes for me too.

[Scott C (cooper48k)]

I'm also seeing this issue with Firefox & Thunderbird.

snap run also seems to consistently work

$ snap --version
snap 2.58.3+23.04ubuntu1
snapd 2.58.3+23.04ubuntu1
series 16
ubuntu 23.04
kernel 6.1.0-16-generic

[Scott C (cooper48k)]

Though if I click on Firefox then right click & open a new private window while it's "loading" (which it either will or it'll just spin and then not actually start) the private window seems to start fine. If I then click on Firefox it allows me to start a new non private window...

This is with both core22 20230304 (547) & core22 20230316 (583)

Very similar thing with Thunderbird...if I right click and 'compose new message' while it's "loading" I can then open a new window...

[Mike Adams (mikethebos)]

I can confirm the intermittent behavior described by Francois and Scott, as well as the ability to sometimes use New Private Window on the GNOME right click menu of FF during a loading period.

[Sebastien Bacher (seb128)]

Sharing debug details from jamesh

When starting snap applications via the shell, log messages like the following are produced:
Mar 21 18:07:49 MGLT-Ubuntu chromium_chromium.desktop[13099]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-chromium_chromium-13099.scope is not a snap cgroup

This error is triggered in snapd’s device-cgroup-support.c, where it expects the process to be in a cgroup created by snapd but finds it in an app-gnome-*.scope cgroup instead. I think this is down to a race condition between gnome-shell and snapd.

On the gnome-shell side, it’s doing:

    spawns the app via GLib.spawn_async, which returns the pid of the running child process.

    Calls GnomeDesktop.start_systemd_scope on the pid.

    start_systemd_scope calls the systemd StartTransientUnit D-Bus method to move the pid to the app-gnome-*.scope cgroup.

On the snap side:

    the executables in /snap/bin are equivalent to running snap run snapname.

    the snap run code asks systemd to move its own pid to a snap.*.scope cgroup via StartTransientUnit.

    it then execs /usr/lib/snapd/snap-confine to set up the sandbox. This includes the device-cgroup-support.c code with the cgroup check.

    if it could set up the sandbox correctly, snap-confine execs the sandboxed application.

I think the problem occurs if gnome-shell’s StartTransientUnit call occurs between steps (2) and (3) on the snap side.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Martin Randau (cmmrandau)]

Same problem here on Ubuntu 23.04 with wayland on AMD Ryzen 6850. Most snaps only start occasionally from dash icon. Works every time from console.

[Batuhan (kde-batuhan)]

Not super how much it helps, but I have the same exact issue on two different systems (one using Kubuntu 22.10 -- with a mainline kernel of 6.0 and the other one using Kubuntu 23.04 [upgraded from 22.10] development branch with a mainline kernel of 6.2.7).

This specifically happens when krunner is used to launch an application, and it happens randomly (even in the same session; but I noticed that it is less likely to happen when the first session started and more likely to happen after you start a few apps).

Here is what I get when I run krunner and choose slack to launch.

❯ krunner --replace
/user.slice/user-1000.slice/[e-mail]/app.slice/app-slack_slack-7092918b60f045318ad5898c1cd14a71.scope is not a snap cgroup

First attempt fails with this, but then I try it again and it works (2nd attempt). I quite and try to launch it again, but this time first two attempts fail and the third one succeeds and launches slack again.

/user.slice/user-1000.slice/[e-mail]/app.slice/app-slack_slack-e699191c66c043c49b21af01db44a21f.scope is not a snap cgroup
/user.slice/user-1000.slice/[e-mail]/app.slice/app-slack_slack-a38502fd65ca425ebdf9b3cbac2d154c.scope is not a snap cgroup

❯ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus

Everything I have is stock Kubuntu 23.04 (I'm updating it each day) except the mainline kernel (which is needed for the graphics driver).

System: AMD Ryzen 9 7950X as both the CPU and iGPU.

[Batuhan (kde-batuhan)]

> I think this is down to a race condition between gnome-shell and snapd.

As someone who is using Kubuntu where gnome-shell is not present, I'd like to mention that I'm also experiencing the same exact issue. Not sure if there is a similar race condition is present on a KDE application in Kubuntu (like Konsole?) but this feels like more of a snap problem than a GNOME problem.

Adding snap version since I missed the chance of doing so in the last post:

❯ snap version
snap 2.58.3+23.04ubuntu1
snapd 2.58.3+23.04ubuntu1
series 16
ubuntu 23.04
kernel 6.2.7-060207-generic

Also I was able to record a trace of `SNAPD_DEBUG=1 krunner --replace slack` which includes a bit more information (not sure how useful)

[Remco Brenninkmeijer (requist1)]

Same issue here, I have never seen any snaps opening from the dash (both Firefox and Brave) and they both put out a cgroup error in the syslog. Starting from terminal works and without the cgroup error in the log.
Maybe also noticable, I see snap core20 and core22 both installed and cannot remove core20 because it is being used by firefox (but not brave which also does not start).

The list of snaps installed:

Name Version Rev Tracking Publisher Notes
bare 1.0 5 latest/stable canonical✓ base
brave 1.49.128 218 latest/stable brave -
core20 20230308 1852 latest/stable canonical✓ base
core22 20230316 583 latest/stable canonical✓ base
firefox 111.0-2 2453 latest/stable/… mozilla✓ -
gnome-42-2204 0+git.09673a5 65 latest/stable canonical✓ -
gtk-common-themes 0.1-81-g442e511 1535 latest/stable/… canonical✓ -
kde-frameworks-5-96-qt-5-15-5-core20 5.96.0 7 latest/stable kde✓ -
keepassxc 2.7.4 1645 latest/stable keepassxreboot -
libreoffice 7.5.1.2 270 latest/stable canonical✓ -
snap-store 41.3-76-g2e8f3b0 935 latest/stable/… canonical✓ -
snapd 2.58.3 18596 latest/stable canonical✓ snapd
snapd-desktop-integration 0.1 71 latest/stable/… canonical✓ -

[Daniel van Vugt (vanvugt)]

We're also tracking a crash in bug 2012839 (private for now) which might explain similar issues seen outside of gnome-shell.

[James Henstridge (jamesh)]

@Batuhan: it's different code, but looks to be the same type of problem:

https://github.com/KDE/kio/blob/5bda428992cbd168fc1898661d80a089a8217449/src/gui/systemd/scopedprocessrunner.cpp#L13-L41

It's moving the process to a new cgroup after the application has started executing (so happens without any synchronisation with what the application is doing).

[James Henstridge (jamesh)]

Another idea for how to synchronise the StartTransientUnit call without resorting to passing pipe file descriptors to the child: we could simply have the child_setup_func call kill(getpid(), SIGSTOP). The parent process can now do the cgroup move at its leisure, and then send a SIGCONT to the child to let it continue to the exec() call.

[Marco Trevisan (Treviño) (3v1n0)]

The workaround that is coming in gnome-shell is enough to handle the normal snap cases, however that's not to be considered a proper solution.

The usage of `ChildSetupFunc` is not easily doable without some refactor in the shell that I'm not keen to do for something that is not likely going to be upstreamable, because the child PID isn't known at JS level at that point so we can't just use it without implementing something else in C ("it is not safe to call any function which may call malloc()" from there, so we can't control what gjs is going to do).

Even doing it, this wouldn't fix the majority of other cases where the cgroup move happens when using the launch context (i.e. when apps are launched from dock or activities).

So, I feel snapd tracker should somewhat be able to track that an app changed its cgroup and move it back to what it belongs, but as discussed in https://github.com/systemd/systemd/issues/26925 there's nothing telling us that right now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-shell - 44.0-2ubuntu2

---------------
gnome-shell (44.0-2ubuntu2) lunar; urgency=medium

  * debian/patches: Cherry-pick more upstream fixes from stable branch
  * debian/patches: Give more priority to desktop files matching startup-wm
    class (LP: #2012645)
  * debian/patches: Do not move snap apps to GNOME apps scope (LP: #2011806)

 -- Marco Trevisan (Treviño) <email address hidden> Mon, 27 Mar 2023 21:19:20 +0200

[Remco Brenninkmeijer (requist1)]

Fix works for me (after reboot/reload Gnome), fast job, thanks! :)

[Gunnar Hjalmarsson (gunnarhj)]

I still have an issue. Not sure if it is related.

When clicking the Firefox icon in the dock, a completely black window opens. Then I can close it and try again, and the second time it works as expected. This repeats itself in each session.

[Francois Thirioux (fthx)]

Same here.

[Marco Trevisan (Treviño) (3v1n0)]

I got it too but definitely another issue.

Il mar 28 mar 2023, 19:40 Gunnar Hjalmarsson <email address hidden>
ha scritto:

> I still have an issue. Not sure if it is related.
>
> When clicking the Firefox icon in the dock, a completely black window
> opens. Then I can close it and try again, and the second time it works
> as expected. This repeats itself in each session.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/2011806
>
> Title:
> [lunar] Snaps don't launch due to cgroup issue
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2011806/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=gnome-shell;
> component=main; milestone=ubuntu-23.04-beta; status=Fix Released;
> importance=Critical; assignee=[e-mail];
> Launchpad-Bug: distribution=ubuntu; sourcepackage=kio; component=universe;
> status=Confirmed; importance=Critical; assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=snapd; component=main;
> status=Confirmed; importance=Critical; assignee=None;
> Launchpad-Bug-Tags: dt-1154 lunar rls-ll-incoming
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: 3v1n0 cmmrandau cooper48k fthx gunnarhj jamesh
> janitor kde-batuhan mikethebos1 requist1 seb128 vanvugt
> Launchpad-Bug-Reporter: Francois Thirioux (fthx)
> Launchpad-Bug-Modifier: Gunnar Hjalmarsson (gunnarhj)
> Launchpad-Message-Rationale: Assignee
> Launchpad-Message-For: 3v1n0
>
>

[Daniel van Vugt (vanvugt)]

The black window is bug 1987976.

[James Henstridge (jamesh)]

> So, I feel snapd tracker should somewhat be able to track that an app
> changed its cgroup and move it back to what it belongs, but as discussed
> in https://github.com/systemd/systemd/issues/26925 there's nothing
> telling us that right now.

There is no "snapd tracker". It's the "snap run" code that moves itself to a new cgroup before setting up the sandbox, dropping privileges, and executing the confined application. At that point, it has no permission to talk to systemd.

It's basically working like "systemd-run --scope" would: it sets up the environment appropriately and then lets the app take over.

[James Henstridge (jamesh)]

I've filed https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565 upstream to cover the gnome-shell problem.

[Marco Trevisan (Treviño) (3v1n0)]

> There is no "snapd tracker".

Yeah, I mean not part of the daemon itself, I was referring to this piece of code:
 - https://github.com/snapcore/snapd/blob/master/sandbox/cgroup/tracking.go

But I see why it can't adjust things itself.
Thanks for the report upstream.

[James Henstridge (jamesh)]

I did a search through the KDE bug tracker, and it looks like someone reported the same root problem back in 2020:

https://bugs.kde.org/show_bug.cgi?id=423756

[James Henstridge (jamesh)]

We've been seeing reports of problems launching snap applications on the Ubuntu 23.04 development release that seem to relate to this race condition. At first we thought it was only a gnome-shell problem, but some KDE users also encountered the problem and I discovered the same racy behaviour in kio. The Ubuntu bug is being tracked here:

https://bugs.launchpad.net/bugs/2011806

The race causes problems for snap applications because it uses cgroups as part of its sandboxing to control device access. The "snap run" launcher moves itself to a new cgroup via systemd's StartTransientUnit call, with some later code setting up the sandbox performing a sanity check to make sure the process is in the expected cgroup. If kio issues its own StartTransientUnit call after "snap run"'s one, the sanity check can fail with an error like:

/user.slice/user-1000.slice/[e-mail]/app.slice/app-slack_slack-4ff6abb389164e52b614e40762b46557.scope is not a snap cgroup

To remove the race, the child process would need to be moved to the new cgroup before the application process is started via exec(). It's also not enough to wait for the StartTransientUnit D-Bus call to complete: you need to wait for the corresponding JobRemoved signal.

If it is of interest, here's the upstream GNOME bug report I filed (different code, but implementing the same race condition):

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565

[U26 (u26)]

At a ubuntu level if you can patch startplasma.cpp

startkde/startplasma.cpp
342: qputenv("KDE_APPLICATIONS_AS_SCOPE", "1");

to
342: qputenv("KDE_APPLICATIONS_AS_SERVICE", "1");

and land https://invent.kde.org/frameworks/kio/-/merge_requests/1019 so we don't regress something important.

I apparently haven't followed up on the latter, so I'll do so now and get it in the next frameworks. The env var guard existed because we couldn't rely on new system which had the new exit type at the time.

[U26 (u26)]

Git commit 5c0ce0f5882d732578be22ac6bb7e1d250e2046b by David Edmundson.
Committed on 31/03/2023 at 14:19.
Pushed by davidedmundson into branch 'master'.

Set ExitType when running applications as transient systemd services

KIO internally has 3 paths to launch applications.
 - fork and exec
- fork and exec then put in a "scope" so that we have our own cgroup
(default)
 - asking systemd to launch the application

The latter was explicitly disabled by default because we had some issues
with applications being cleaned up when the first process exited. We
made those upstream changes a year ago, but haven't adopted the changes
here. This brings it in line with the setup used by xdg-autostart-generator.

Nothing will change when we land this as this operation mode is not
enabled.
Related: bug 461289

M +13 -11 src/gui/systemd/systemdprocessrunner.cpp

https://invent.kde.org/frameworks/kio/commit/5c0ce0f5882d732578be22ac6bb7e1d250e2046b

[Bug-janitor (bug-janitor)]

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1244

[U26 (u26)]

Git commit 0c540119248c1eb373eaf2ee323094798897967a by David Edmundson.
Committed on 03/04/2023 at 08:44.
Pushed by davidedmundson into branch 'kf5'.

Set ExitType when running applications as transient systemd services

KIO internally has 3 paths to launch applications.
 - fork and exec
- fork and exec then put in a "scope" so that we have our own cgroup
(default)
 - asking systemd to launch the application

The latter was explicitly disabled by default because we had some issues
with applications being cleaned up when the first process exited. We
made those upstream changes a year ago, but haven't adopted the changes
here. This brings it in line with the setup used by xdg-autostart-generator.

Nothing will change when we land this as this operation mode is not
enabled.
Related: bug 461289

(cherry picked from commit 5c0ce0f5882d732578be22ac6bb7e1d250e2046b)

M +13 -11 src/gui/systemd/systemdprocessrunner.cpp

https://invent.kde.org/frameworks/kio/commit/0c540119248c1eb373eaf2ee323094798897967a

[3vi1 (launchpad-net-eternaldusk)]

Can confirm it affects KDE users as well - discovered this while trying to launch Discord for the first time in a long time. The snap will only launch from a terminal, not the shell ("not a snap cgroup error"). Flatpak version launches from shell just fine.

[Jonas Gamao (yamiyukisenpai)]

Any updates with this one?

[Jonas Gamao (yamiyukisenpai)]

When I launch Thunderbird

Nov 14 20:12:55 systemd[9205]: Started snap.thunderbird.thunderbird-218c47bb-9cdf-4585-8487-1e76547933b3.scope.
Nov 14 20:12:55 systemd[9205]: Started app-thunderbird_thunderbird-4758a597c99d427f91814da5b05c365a.scope - Thunderbird Mail - Mail Client.
Nov 14 20:12:55 plasmashell[133984]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-thunderbird_thunderbird-4758a597c99d427f91814da5b05c365a.scope is not a snap cgroup

[Jonas Gamao (yamiyukisenpai)]

Operating System: Kubuntu 23.10
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.10
Kernel Version: 6.5.0-10-generic (64-bit)
Graphics Platform: X11
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6900 XT
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X570S AORUS MASTER
System Version: -CF

[Curtis (crgibson)]

This is also happening for me. It takes multiple tries to launch some of my snap applications like Discord, Zoom, and Slack from my Application Menu. I don't have this problem for IntelliJ Ultimate. It seemed like a lot of the applications that are having this issue rely on core22, but I don't know if that's actually related.

Here are my snaps (I've been trying to add and remove slack and zoom to try and fix them):

Name Version Rev Tracking Publisher Notes
bare 1.0 5 latest/stable canonical✓ base
core 16-2.60.4 16202 latest/stable canonical✓ core
core18 20230901 2796 latest/stable canonical✓ base
core22 20230801 864 latest/stable canonical✓ base
discord 0.0.35 163 latest/stable snapcrafters✪ -
gnome-42-2204 0+git.ff35a85 141 latest/stable canonical✓ -
gtk-common-themes 0.1-81-g442e511 1535 latest/stable canonical✓ -
gtk2-common-themes 0.1 13 latest/stable canonical✓ -
intellij-idea-ultimate 2023.2.5 462 latest/stable jetbrains✓ classic
snapd 2.60.4 20290 latest/stable canonical✓ snapd

If I try opening them directly from the terminal it works every time.

But if I open them using dolphin (with terminal open) I sometimes get the following error:

/user.slice/user-1000.slice/[e-mail]/app.slice/app-discord_discord-f458540dedf040da87633a4e587169ac.scope is not a snap cgroup

This seems to be consistent with the frequency of if I try and launch if from the Application Menu, so I'm assuming this is a similar error.

Here is my system information:

Operating System: Ubuntu 22.04
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.3
Kernel Version: 6.2.16-060216-generic (64-bit)
Graphics Platform: X11
Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor
Memory: 30.5 GiB of RAM
Graphics Processor: Radeon RX 7900 XTX
Manufacturer: ASUS

Hopefully this information is useful in trying to find a fix!

[James Henstridge (jamesh)]

@Jonas: If KDE is launching apps in the same way gnome-shell was, it is inherently racy. It needs to make sure the child process is in the new cgroup before executing the application.

Doing the cgroup move after the app is already running causes problems if the application itself wants to configure cgroups, and could let child processes of the app itself escape the cgroup if they are created before the launcher tries to move the app.

[Jonas Gamao (yamiyukisenpai)]

so...what's the fix?

My Bitwarden is also acting up now

[Techxgames (techxgames)]

I'm still experiencing this issue :-(

https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2011806/comments/43

[Marek Stasiak (marecki)]

So, this won't be fixed until https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565 is resolved? Or is it fixed in newer Ubuntu releases? (On 22.04 I am experiencing the problem quite often, wondering if there is any point in upgrading. In the last 24h I encountered it three times with Thunderbird, each time I could not start it for about ~20 minutes)

mar 05 22:11:42 pc thunderbird_thunderbird.desktop[1018965]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1018965.scope is not a snap cgroup
mar 05 22:12:13 pc thunderbird_thunderbird.desktop[1018995]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1018995.scope is not a snap cgroup
mar 05 22:12:32 pc thunderbird_thunderbird.desktop[1019063]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1019063.scope is not a snap cgroup
mar 05 22:13:36 pc thunderbird_thunderbird.desktop[1019106]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1019106.scope is not a snap cgroup
mar 05 22:15:39 pc thunderbird_thunderbird.desktop[1019468]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1019468.scope is not a snap cgroup
mar 05 22:17:04 pc thunderbird_thunderbird.desktop[1019559]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1019559.scope is not a snap cgroup
mar 05 22:19:04 pc thunderbird_thunderbird.desktop[1019660]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1019660.scope is not a snap cgroup
mar 05 23:24:55 pc thunderbird_thunderbird.desktop[1027932]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1027932.scope is not a snap cgroup
mar 05 23:29:02 pc thunderbird_thunderbird.desktop[1029016]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1029016.scope is not a snap cgroup
mar 06 00:00:09 pc thunderbird_thunderbird.desktop[1041966]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1041966.scope is not a snap cgroup
mar 06 00:00:33 pc thunderbird_thunderbird.desktop[1042002]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1042002.scope is not a snap cgroup
mar 06 00:01:06 pc thunderbird_thunderbird.desktop[1042035]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1042035.scope is not a snap cgroup
mar 06 00:01:22 pc thunderbird_thunderbird.desktop[1042063]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1042063.scope is not a snap cgroup
mar 06 00:01:52 pc thunderbird_thunderbird.desktop[1042091]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1042091.scope is not a snap cgroup
mar 06 00:03:16 pc thunderbird_thunderbird.desktop[1042381]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-gnome-thunderbird_thunderbird-1042381.scope is not a snap cgroup
mar 06 00:04:17 pc thunderbird_thunderbird.desktop[1...

[miquel cabre (miquelcvcv)]

I am using latest Ubuntu version today (23.10 mantic) and it is not working. How is possible that something so basic as Ubuntu remote desktop with vnc just does not work or take so long. I am feed up of asking google. I remember years ago I just desist of doing a remote connection using vnc, cause I could not due Wayland was a new implantation. Today i arrived further away, but it still not working properly.