Can't run snaps: .slice/session-1.scope is not a snap cgroup

[Akkana Peck]

I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with:

/user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid

With firefox, I was able to fix the problem with:

snap remove --purge firefox
apt purge firefox
apt install firefox

Now firefox works. But I tried the same thing substituting chromium-browser for firefox, and it didn't help: chromium fails with the same error message.

I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version?

Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing.

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: snapd 2.53+21.10ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18
Uname: Linux 5.13.0-21-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Thu Nov 18 18:12:45 2021
InstallationDate: Installed on 2020-04-29 (568 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: snapd
UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago)

[Maciej Borzecki (maciek-borzecki)]

Can you run `SNAPD_DEBUG=1 snap run firefox` and attach the output?

[jack8514 (jack-odom)]

I have the same issue, but chromium was working on impish prior to this issue (last boot was 11/18, so about 20 days uptime). SNAPD_DEBUG=1 attached. Dbus daemon appears to be running and /run/user/{id}/bus exists.

I don't see an update that could have caused this, and I haven't really made any system changes since last boot.

[Maciej Borzecki (maciek-borzecki)]

Snapd needs to talk to systemd user instance to setup a scope for the snap. This is done over a session bus.

Is DBUS_SESSION_BUS_ADDRESS set in your environment? Run `echo $DBUS_SESSION_BUS_ADDRESS`, the output should be like `unix:path=/run/user/NNN/bus` (where NNN is your uid). Can you then run `ls -l /run/user/NNN/bus` and check if the socket file is there?

[Akkana Peck (akkzilla)]

$DBUS_SESSION_BUS_ADDRESS is:
unix:abstract=/tmp/dbus-rBFSkTtKSd,guid=9839721c1a52b5cd5e2e0d6961ae292d

ls -l of that gives No such file or directory

My window manager is openbox, started with /usr/bin/dbus-launch --exit-with-session openbox

[Maciej Borzecki (maciek-borzecki)]

Can you run `systemctl --user`? Does it work at all?

[Akkana Peck (akkzilla)]

Sure. Do you want the full output (162 lines)? Or maybe just the output of systemctl --user | grep snap, or something? I'm not sure what you're looking for.

[Maciej Borzecki (maciek-borzecki)]

Ok, so the logs you attached earlier are:

2021/12/03 15:21:45.540312 tracking.go:45: DEBUG: creating transient scope snap.chromium.chromium
2021/12/03 15:21:45.543273 tracking.go:185: DEBUG: using session bus
2021/12/03 15:21:45.547127 tracking.go:290: DEBUG: StartTransientUnit failed with "org.freedesktop.DBus.Error.Spawn.ChildExited": [Process org.freedesktop.systemd1 exited with status 1]
2021/12/03 15:21:45.547174 cmd_run.go:1187: DEBUG: snapd cannot track the started application
2021/12/03 15:21:45.547199 cmd_run.go:1188: DEBUG: snap refreshes will not be postponed by this process

When snap starts the /usr/bin/snap binary tries to create a scope for the application. The scope is needed so that the app can run in a separate cgroup which is then confined to access specific devices. Unfortunately this is the only way to set this up on a cgroup v2 system. The setup is done by talking to your `systemd --user` instance. In the log it's clearly indicated that it failed and systemd exited, thus no scope and the app cannot be run, because the confinement would break your session cgroup (.slice/session-1.scope). I'm afraid I don't know enough about your setup to guess what could be wrong there and why the user instance may have exited. Perhaps reviewing the user logs (journalctl --user) could help uncover the problem.

[Akkana Peck (akkzilla)]

$ journalctl --user
No journal files were found.
-- No entries --

Does it need to be configured to show snap information somehow?

[Maciej Borzecki (maciek-borzecki)]

No, it just means that the journal is not collecting any user session logs. I'm afraid this is beyond snapd scope at this point. Perhaps you can try to make you openbox session to be more like what GNOME and KDE set up, that is with systemd user instance that can be accessed via dbus. I don't know how you log in, maybe to need to tweak the PAM config so that pam_systemd is included, though I'm far from being expert here and the user sesion setup has become crazy complicated.

Anyways, the snapd part is working as expected, such that if a separate cgroup for the snap cannot be created it stops before breaking the one your session is in.

[enen (koom)]

i ran into this error today when i ran my X server through startx rather than gdm.

[Marc Cheng (bdgraue)]

I ran into this problem today when i had my headset attached via usb on startup. the problem disappeared, when i restarted without the usb headset attached to the notebook?

[Daniele Cruciani (daniele-smartango)]

headset? umh, well I found that I have no `systemd --user` running (thank to Maciej Borzecki comment in #1956942), then I run it in a terminal, and this fixed the problem.

I started session by `startx`, like enen above, I have no idea about gdm session, but I can guess systemd --user is started there, in GDM, but not by startx, and probably is a good idea not to run `systemd --user` from startx, but user feedback is awful, I mean, by clicking on the chromium launcher there is no feedback at all, running from terminal there is this cgroup related message, when in debug there is some reference to dbus, not systemd.

At the end everybody need Maciej Borzecki to explain where is the problem, maybe snapd can return some less obscure message? Just an idea, thank you for support anyway.

[Daniele Cruciani (daniele-smartango)]

ah, I forgot about usb headset, I saw pulseaudio relay on systemd --user, maybe via dbus, so starting with headset could has triggered the start of systemd --user?

[Daniele Cruciani (daniele-smartango)]

$ systemd --user
Failed to create /user.slice/user-1000.slice/session-1.scope/init.scope control group: Permission denied
Failed to allocate manager object: Permission denied

that's it.

Still:

SNAPD_DEBUG=1 snap run chromium
2022/04/08 09:33:56.722937 tool_linux.go:204: DEBUG: restarting into "/snap/snapd/current/usr/bin/snap"
...
2022/04/08 09:33:56.751746 tracking.go:294: DEBUG: StartTransientUnit failed with "org.freedesktop.DBus.Error.Spawn.ChildExited": [Process org.freedesktop.systemd1 exited with status 1]

No update, no information about snapd in ubuntu 22.04

Is it possible to try newer package in ubuntu 21.10 ? a ppa?

Thank you.

[Maciej Borzecki (maciek-borzecki)]

FWIW systemd --user is expected to have been started as part of your session. This is supposed to be fully automatic. I don't think you can start it yourself, as it's up to systemd/logind to properly start the process and move it to the right cgroup. I've added systemd to the bug report, so maybe this time it will get some traction.

[Launchpad Janitor (janitor)]

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

[Endolith (endolith)]

Same problem in 21.10 with Firefox, Chromium, and Waterfox Classic. All have suddenly stopped working with error

/user.slice/user-1000.slice/session-30.scope is not a snap cgroup

I'm running MATE inside X2Go

[Patrick Walker (walkerp)]

Same problem with both 22.04 Server and Ubuntu Mate 22.04.
All the confined GUI snaps have this problem and thus can't run.
First, I encountered running MATE desktop via X2Go Server.
Then I tried to see if using xRDP would work. No still problem persists whether I use xRDP or X2Go
Left unable to remotely run any UI confined snaps using Ubuntu Server/Mate 22.04 until fix or workaround instructions provided.

[Daniele Cruciani (daniele-smartango)]

It has been reported also for Debian 11

https://forum.snapcraft.io/t/non-classic-snaps-fail-to-load-due-to-cgroup-apparmor-issue/28756

looking at `tail -f /var/log/syslog` I see almost the same message

```
May 13 08:31:15 iltoshibo dbus-daemon[15558]: [session uid=1000 pid=15556] Activating service name='org.freedesktop.systemd1' requested by ':1.3243' (uid=1000 pid=797511 comm="telegram-desktop " label="unconfined")
May 13 08:31:15 iltoshibo dbus-daemon[15558]: [session uid=1000 pid=15556] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
```

Maintainer say "my guess is there’s something missing or misconfigured in your session.". Now the problem is to find _what_ is missing or misconfigured (for all subscriber here, I think)

[Damo (damo-clarky)]

I All,

I can confirm same problem with Ubuntu MATE 22.04 running Xtightvnc session.

[Michael Joyner (michael-newsrx)]

Confirm issue is in latest LTS Xubuntu setup running x2go desktop environment.

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04 LTS
Release: 22.04
Codename: jammy

[Tim Richardson (tim-richardson)]

I have this problem connecting with nomachine to a virtual xubuntu desktop.
I hoped that the solution here might have helped:
https://askubuntu.com/a/1310739/152287

but this script does not fix the problem, although it is active for me (the new environment variables are present in my session, for instance)

[Tim Richardson (tim-richardson)]

Please note that nomachine technical support provided me with a workaround. It works, but I don't understand the implications. This fixed the problem with xubuntu 22.04. The support notes says it works for ubuntu 22. 04 as well

In my case I added the kernel setting to GRUB_CMDLINE_LINUX which was present in my /etc/default/grub

"*1.* sudo vim /etc/default/grub
change from:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash systemd.unified_cgroup_hierarchy=0"

*2. *sudo update-grub
*3.* sudo reboot"

[Daniele Cruciani (daniele-smartango)]

@tim-ruchardson unified_cgroup_hierarchy=1 is exactly what I want to enable, and I reported the problem in #1956942, where there is a reference to https://lists.ubuntu.com/archives/ubuntu-devel/2021-August/041598.html

the default is hierarchy=unified.
Also, in my configuration docker is using systemd, and it works, but snapd does not work.

It does not look like a work around, but like a "let it be and do not use cgroupv2"

[Tim Richardson (tim-richardson)]

Yes, based on your link this 'work around' disables new cgroups.
: "If for some reason you need to keep the legacy cgroup v1 hierarchy, you
can select it via a kernel parameter at boot time:
systemd.unified_cgroup_hierarchy=0"

however, it at least allows a working session.

on another point: this problem happens with xubuntu which does not use gdm3, it uses lightdm.
So what ever session start script is being missed by the standard startx scripts we are all using for our various remote connection tools, is not specific to gdm.

[Tim Richardson (tim-richardson)]

I ran into this again, this time in a virt-man virtual ubuntu 22.04 guest connected to via virt-viewer --attach.

tim@ubuntu-virtio:~$ snap-store
/user.slice/user-1000.slice/[e-mail]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-b5b3e096-ebb3-4eca-b9d1-d07ca7028b22.scope/init.scope is not a snap cgroup

[Tim Richardson (tim-richardson)]

... running systemd --user in a terminal window first, and then starting the snap-store worked.

[Tim Richardson (tim-richardson)]

This is what I get in journalctl when trying to start firefox:

Jun 15 13:09:30 ubuntu dbus-daemon[7531]: [session uid=1000 pid=7528] Activating service name='org.freedesktop.systemd1' requested by ':1.60' (uid=1000 pid=8624 comm="/snap/bin/firefox " label="unconfined")
Jun 15 13:09:30 ubuntu dbus-daemon[7531]: [session uid=1000 pid=7528] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
Jun 15 13:09:30 ubuntu audit[8624]: AVC apparmor="DENIED" operation="capable" profile="/snap/core/13308/usr/lib/snapd/snap-confine" pid=8624 comm="snap-confine" capability=12 capname="net_admin"
Jun 15 13:09:30 ubuntu audit[8624]: AVC apparmor="DENIED" operation="capable" profile="/snap/core/13308/usr/lib/snapd/snap-confine" pid=8624 comm="snap-confine" capability=38 capname="perfmon"
Jun 15 13:09:30 ubuntu kernel: audit: type=1400 audit(1655262570.773:81): apparmor="DENIED" operation="capable" profile="/snap/core/13308/usr/lib/snapd/snap-confine" pid=8624 comm="snap-confine" capability=12 capname="net_admin"
Jun 15 13:09:30 ubuntu kernel: audit: type=1400 audit(1655262570.773:82): apparmor="DENIED" operation="capable" profile="/snap/core/13308/usr/lib/snapd/snap-confine" pid=8624 comm="snap-confine" capability=38 capname="perfmon"

[Tim Richardson (tim-richardson)]

for me and my xfce4 login, in a terminal this lets me launch snaps:

tim@ubuntu ~ $ export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"
tim@ubuntu ~ $ firefox

[Tim Richardson (tim-richardson)]

I added that to my ~/.profile and confined snap apps run now.

[Daniele Cruciani (daniele-smartango)]

Tim Richardson Thank you so much, but NO, no and again NO.

I will not disable cgroups v2 because "at least blah blah blah".

I came from a configuration in which cgroups v2 was disabled, and snapd worked. So thank you, but please stop spamming.

The point is that I need cgroups v2 and snapd has a bug, at least in my configuration and some of configuration of other subscriber, that make it stop to work.

But the interesting point may be about your nomachine configuration: is it fresh installed?

I see you also spammed in https://forum.snapcraft.io/t/non-classic-snaps-fail-to-load-due-to-cgroup-apparmor-issue/28756/4

Maybe you should had read there:

"""
FWIW our CI runs tests on Debian 10 and 11 vanilla images and things appear to be working correctly, so my guess is there’s something missing or misconfigured in your session.
"""

You could have commented with something more clever, like: does Debian 11 vanilla images has cgroups v2 enabled, or not?

Clearly there "session" does not mean the boot options.

If this was the point, then still there is a bug on snapd

On snapd there is a bug, and this bug is against snapd.

Can you confirm that enabling cgroups v2 on vanilla image does not work?

How could it be possible that your configuration does not work and you need to specify boot options? How could CI pass the tests?

there were an old /etc in your machine? and old /home? what?

[Maciej Borzecki (maciek-borzecki)]

I've commented before, but if your desktop session is correctly set up, the systemd --user instance should be available, then a transient scope can be created for snap and proper device access filtering can be set up in that cgroup, thus completing the sandbox. Cgroup v1 works differently, in that there is a separate hierarchy which could be set up for a snap and there's no need to ask ssytemd to set up anything on behalf of the snap. This is no longer the case for v2.

AFAICT gdm/kdm/xdm seem to be able to do that correctly. Most trouble seems to be coming from X2go/vnc or similar solutions which appear to give you a desktop access, but it's half baked, and are either missing session dbus or the systemd --user instance. Perhaps it's not really going through PAM, hence things that would have been set up through pam_systemd are missing.

[Tim Richardson (tim-richardson)]

 I do not have cgroups disabled, I reverted that earlier change. (I should have been clearer). My fix works with cgroupsv2, at least for my xfce4 session.

[Tim Richardson (tim-richardson)]

PS I do not think this is a bug in snap. It is a bug with the way the session is being setup (the user session).. I don't know what the bug is, or to be more specific, I do not know why DBUS_SESSION_BUS_ADDRESS has such a strange value in the remote session.

I have spent some hours trawling through bug reports and following clues (I tried to be useful). My "spam" on the snapcraft bug was a helpful note directing readers here, because this is the bug report tracking the actual bug, whatever it is. That's not spam, that's being a good citizen.

by following bug reports relating to "Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1" I ended up learning about the Xession init files, in particular /etc/X11/Xsession.d/20dbus_xdg-runtime

Then I compared env for a local login (which works of course) and a remote session. The difference which stood out was the value for DBUS_SESSION_BUS_ADDRESS.

I just copied how that is set in /etc/X11/Xsession.d/20dbus_xdg-runtime and it works for me now, when I connect to my nomachine workstation server running on the xubuntu machine.

the session is started with /usr/bin/startxfce4 which is probably very similar to other remote access sessions.

[curve25519 (curve25519)]

Tim,

Two "Thank-you"s for you:
    1. "spamming" elsewhere and here. Indeed, I got redirected here after I saw your comments at snapcraft forum
    2. Correctly specifying the bus address for the session by setting DBUS_SESSION_BUS_ADDRESS. This worked like magic! My Ubuntu 22.04 running KDE Plasma was almost unusable over x2go. I can't thank you enough!

This is the exact issue that appears when running any confined snap over x2go (or VNC as reported by others)
```
/user.slice/user-1000.slice/session-1.scope is not a snap cgroup
```
As it turned out, it was snapd not finding the bus path. For anyone looking for a quick fix, apply Tim's fix to your ~/.profile and you are good to go. Some snaps (like Firefox) requires re-installation to work.

[Daniele Cruciani (daniele-smartango)]

Tim, yes it works adding the environment variable, but you wrote "I should have been clearer" in comment 35, but that is wrong, you should at least had mentioned that you did enabled the cgroupsv2, and from comment 27 to comment 32, there are no mention about reverting systemd.unified_cgroup_hierarchy=0 to 1.

Should I say I am sorry for my misunderstood? Well for me it was really hard to read on without this details: cgroupsv2 was enabled.

Without neither mention that "detail", it follow my interpretation as a spam/off-topic

[Tim Richardson (tim-richardson)]

I'm just an ordinary user trying to get this working and volunteering what I learn, so bear that in mind. I have no real clue about what the problem is and I still don't understand where in the session start process DBUS_SESSION_BUS_ADDRESS is set and why we get a wrong value when starting sessions with our remote access.

I sent my workaround to nomachine since it has some advantages over their current solution of disabling cgroupv2. They said it works for them, and they have altered their tech note to say the node.cfg could also be:

DefaultDesktopCommand "env
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus /usr/bin/startxfce4"

I think you will recognise how to apply that.
This seems to allow only one session per user.

let me know if it works. I remember now I setup "loginctl enable-linger", which may or may not be helping my solution.

[Tim Richardson (tim-richardson)]

And let us hope that someone who can fix it steps up and fixes it properly because right now, ubuntu 22.04 and derivatives are unfit for remote desktop deployments.

[Tim Richardson (tim-richardson)]

I have been reading a bit more. I'm starting to form the impression that this problem may originate from the way our various remote solutions are logging in. They may not be doing it the proper modern login-systemd way. This would mean that nomachine, x2go are both wrong.

[Daniele Cruciani (daniele-smartango)]

Tim Richardson, I recognize your effort and contribution to solve the problem, but without my comment in #33, where I must say I were not very nice, you would not have clarified that cgroups v2 was enabled again.

Maybe you stated that with nomachine community, but not here.
Not stated before my comment #33

[Tim Richardson (tim-richardson)]

Now I think we should file upstream bug reports with x2go (which I don't use) and nomachine and get some clarity on whether they are doing the login in compliance with up-to-date https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html

[Michael Woods (woodsy)]

Updated one server from 20.10 and another from 22.04. Both got this error independently. Both using X2Go for remote desktop.

Both servers env would show DBUS_SESSION_BUS_ADDRESS as something in /tmp iirc

Long story short and a lot of rooting around..

added:
DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"
export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"

to the end of:
/etc/X11/Xsession.d/20dbus_xdg-runtime
/etc/X11/Xsession.d/75dbus_dbus-launch
/etc/X11/Xsession.d/95dbus_update-activation-env

Probably not needed in all three files but whatever, it fixes everything...
Probably entirely related to the IF statements in those files not matching correctly to set the env variable.
Not sure if they changed on upgrade and i cbf'd checking but everything was working perfectly before upgrade.

[Launchpad Janitor (janitor)]

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

[Stephen (artist-wavenet)]

I too get an error when I attempt to launch firefox in freshly installed Ubuntu Studio 22.04. It is very similar to the one this Jira was opened with.

When I attempt to launch firefox remotely by SSH I get this error:

/system.slice/ssh.service is not a snap cgroup

When I attempt to launch firefox locally I get this warning, and error:

WARNING: cannot start document portal: Expected portal at "/run/user/1000/doc", got "/home/stephen/.cache/doc"
/system.slice/sddm.service is not a snap cgroup

In my case it appears this bug manifests itself not just remotely, but locally as well. Without the ability launch snap packaged applications my newly acquired, and very expensive, computer is useless. I hope this bug's fixing gets a high priority.

In an effort to work around it I edited the three files as recommended by Michael Woods (woodsy) in c44. The result was the computer booted a blank, and black, monitor screen. Fortunately the OS was nevertheless accessible by SSH, and so I was able to remotely restore the three files, and after doing so, I rebooted and got the expected screen displays.

I am not sure I edited those three files correctly, so I attached the edited version of those files to this posting for inspection. I also included in the attachment the output I get from the locally entered command:

SNAPD_DEBUG=1 snap run firefox

I would deeply appreciate any recommendations regarding how to effectively work around this bug.

[Stephen (artist-wavenet)]

I have recently discovered:

1) The global variable XDG_RUNTIME_DIR is not set to anything.

2) There is only one user on this newly installed Ubuntu 22.04 OS. It would be expected the user number for it is 1000. This is verified by the global $UID being set to that number as expected. But the directory /run/user/1000 does not exist. The directory /run/user/ is empty.

Included the updated attachment to c47 is the syslog file.

[Stephen (artist-wavenet)]

I have firefox working. To get it to work I had to disable cgroup. To do this I followed Tim Richardson's instructions at c25. When launched it output many permission denied errors which are attached. These errors were solved by commands I descried in this thread:

http://forums.mozillazine.org/viewtopic.php?f=38&t=3097766

[mtu (mtu)]

I see the same as Stephen in c46: snap-Firefox fails to start locally, _sometimes_ – the error is not readily reproducable.

When it happens, the following errors appear in ~/.xsession-errors:

/user.slice/user-1000.slice/[e-mail]/app.slice/app-firefox_firefox-0403ae5e70f94aa6ace2ebfdfb404e54.scope is not a snap cgroup
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2201, resource id: 104858919, major code: 18 (ChangeProperty), minor code: 0
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:366: Unable to assign [undefined] to QString

Usually, launching firefox from a terminal still works as expected.

[Tim Richardson (tim-richardson)]

It is (much) better to use the more sophisticated workaround that does
not disable cgroups v2.

On Tue, 2 Aug 2022 at 07:32, mtu <email address hidden> wrote:
>
> I see the same as Stephen in c46: snap-Firefox fails to start locally,
> _sometimes_ – the error is not readily reproducable.
>
> When it happens, the following errors appear in ~/.xsession-errors:
>
> /user.slice/user-1000.slice/[e-mail]/app.slice/app-firefox_firefox-0403ae5e70f94aa6ace2ebfdfb404e54.scope is not a snap cgroup
> qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2201, resource id: 104858919, major code: 18 (ChangeProperty), minor code: 0
> file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:366: Unable to assign [undefined] to QString
>
> Usually, launching firefox from a terminal still works as expected.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1951491
>
> Title:
> Can't run snaps: .slice/session-1.scope is not a snap cgroup
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/x2go/+bug/1951491/+subscriptions
>

--
Tim Richardson