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)]

@Akkana. My suspicion from digging around is that the problem happens
during login, not session start. Certain steps in the sessiond login
process need to be invoked for the session bus to work correctly. You will
see from other reports that this issue is with the dbus session bus not
being set up correctly. The report about cgroups is a consequence of that.
The workarounds prove this. When I looked into the session start up
process, the problem occurred before session start. systemd has
documentation on what the login needs to do, and I don't think this is
being followed when this problem occurs. I therefore think this is not
about the sessions, but the login process. It's why I wondered if you were
using a modern login manager (such as gdm3) because gdm3 is compliant with
systemd's requirements.
You could dp

echo $DBUS_SESSION_BUS_ADDRESS

from your console before you do startx, and see if it is valid. I'm going
to guess that it is not. When I spent some time looking at this a few
months ago, I had the impression that this variable needs to be set
correctly before the gui session starts.

On Sun, 23 Oct 2022 at 07:40, Akkana Peck <email address hidden>
wrote:

> Tim Richardson: I'm not using a login manager, I'm logging in on the
> console then running startx.
>
> This is clearly not an openbox-specific bug since people have seen it in
> many different environments, and besides, it only happens on Ubuntu with
> Ubuntu snaps. The problem seems to be that snap has started to require
> [some unknown system service or configuration] that it didn't need
> before, which some desktop environments start and others don't. If we
> knew what it was looking for, then people who need to run snaps could
> make sure it was configured in their environments.
>
> --
> 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

[Ron Simpkin (ronsimpkin)]

You can disregard my issue. It was caused by the limited environment supplied by cron.

[Luigi Caiazza (lcaiazza88)]

Same issue here.

My configuration is a fresh install of Ubuntu Mate 22.04 LTS, meant to be used both locally and remotely (via X2GO).

From local sessions, I have no anomalies for each application installed via snap, so I am sure that the system works like a charm under some conditions. In contrast, if I log in from a remote session and I try to start almost all applications installed via snap (e.g., Firefox, Brave, Arduino IDE), I fall into:

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

The "strange" thing is that I found an application that works pretty well even through remote sessions: Visual Studio Code, installed using this command:
sudo snap install code --classic

I have not yet understood what can make the difference here, but to have a full working system I prefer to rely on a sort of bugfixing, rather than (permanently) apply some workaround that distorts the behaviour of the system.

I am curious to know why Visual Studio Code works (maybe for the classic confinement?). Please, inform us if you get the point.

Thank you.

[Tim Richardson (tim-richardson)]

unconfinded snaps don't have thie problem (that is, --classic snaps), these
bypass all the snap sandboxing and I guess this means they bypass the
controls and restrictions of cgroups. If you want this fixed, you have to
get x2go fixed. Report the bug there.

On Sun, 6 Nov 2022 at 21:05, Luigi Caiazza <email address hidden>
wrote:

> Same issue here.
>
> My configuration is a fresh install of Ubuntu Mate 22.04 LTS, meant to
> be used both locally and remotely (via X2GO).
>
> From local sessions, I have no anomalies for each application installed
> via snap, so I am sure that the system works like a charm under some
> conditions. In contrast, if I log in from a remote session and I try to
> start almost all applications installed via snap (e.g., Firefox, Brave,
> Arduino IDE), I fall into:
>
> /user.slice/user-1000.slice/session-14.scope is not a snap cgroup
>
> The "strange" thing is that I found an application that works pretty well
> even through remote sessions: Visual Studio Code, installed using this
> command:
> sudo snap install code --classic
>
> I have not yet understood what can make the difference here, but to have
> a full working system I prefer to rely on a sort of bugfixing, rather
> than (permanently) apply some workaround that distorts the behaviour of
> the system.
>
> I am curious to know why Visual Studio Code works (maybe the classic
> confinement?). Please, inform us if you get the point.
>
> Thank you.
>
> --
> 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

[Vishal Manchanda (vishalmanchanda)]

Hi, any update on this bug, we are facing this issue in OpenStack CI jobs. For error, logs see here [1]. let me know if more info. is required.

I have opened a new bug in openstack/horizon as well to track it and added more details there [2].

[1] https://zuul.opendev.org/t/openstack/build/e17d10e36eae4ccab3c94e6371b12c83/log/job-output.txt#2705
[2] https://bugs.launchpad.net/horizon/+bug/1996638

[EML (eml1)]

Another datapoint. Just upgraded a laptop from 20.04 to 22.04.

1 - the laptop itself has no problem running Chromium or Firefox. When run from a terminal, DBUS_SESSION_BUS_ADDRESS is 'unix:path=/run/user/1000/bus'

2 - When connecting over vnc, using the 'normal' xstartup (which must have been on the net for 15-odd years), I see exactly this problem, but for 'session-5.scope'. DBUS_SESSION_BUS_ADDRESS is 'unix:abstract=/tmp/dbus-joEHty7pAj,guid=64e54e1c9ccf659527b095906389fcc0'. This xstartup is shown as config (1) below

3 - I'm using tigervnc. If I don't have a ~/.vnc/xstartup it defaults to /etc/X11/Xtigervnc-session (see /etc/tigervnc/vncserver-config-defaults). This is shown as config (2) below. When using this default, Chromium and Firefox work Ok, with the 'correct' DBUS_SESSION_BUS_ADDRESS

Ergo this is just one more problem with vnc/remote desktop setup, which is almost entirely unsupported on Ubuntu, Debian, and RedHat. Clearly the people running on bare metal have a slightly different issue, but I bet it has the same root cause. With config (1), I also get a pop-up saying that 'The application IBus Preferences has closed unexpectedly'. Note also, while I'm complaining, that this is the second snap issue that I've had to deal with today to get 22.04 running (see https://github.com/snapcore/snapd-desktop-integration/issues/23#issuecomment-1335072721). I also do a server image for 22.04.1, which has snap completely removed (because it is, in more ways than one, a waste of space), but Canonical seem to be going out of their way to make this impossible on desktop (ironic, since snap was meant to be for servers).

Config 1:

#!/bin/sh
# Start up the standard system desktop
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS

#/usr/bin/startxfce4
/usr/bin/gnome-session

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
x-window-manager &

Config 2:

#! /bin/sh

test x"$SHELL" = x"" && SHELL=/bin/bash
test x"$1" = x"" && set -- default

if test -r /etc/default/keyboard &&
   test -x /usr/bin/setxkbmap; then
  . /etc/default/keyboard
  /usr/bin/setxkbmap \
    -model "${XKBMODEL}" \
    -layout "${XKBLAYOUT}" \
    -variant "${XKBVARIANT}" \
    "${XKBOPTIONS}"
fi

tigervncconfig -iconic &
"$SHELL" -l <<EOF
exec /etc/X11/Xsession "$@"
EOF
tigervncserver -kill $DISPLAY

[Steve Fatula (rs26)]

Have the same issue as Ron Simpkin in c56. "I'm attempting to run automated testing from cron running chromium on X/vfb (headless server). The cron job works so long as the user is logged in, the tests also run successfully directly from the command line (in an ssh session). I've tried the workarounds suggested here and none are successful."

Ron, what was your solution? When some are saying it's not a snap issue, and keep beinging up login oddities, etc., what's the proposed solution for snaps and cron jobs? There is no session, and nothing to fix?

[DiagonalArg (diagonalarg)]

I'm running xpra from vanilla 22.04 (wayland) to vanialla 22.04 (X). Firefox works fine directly on the server, but won't run over xpra. The `export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"` works for me.

[Rafael Alves (rafaotec)]

Yeah, I know my answer dont solve this issue. But, if you cant wait for a fix, like me, you can try install chrome without snap. In my case I thought it was impossible, cause I was running ubuntu 22.04 in a ARM instance. But after remove the snap version and install a deb version I found peace and my webscrapping is working fine now.

Follow this link to install deb version oc chromium: https://fosspost.org/chromium-deb-package-ubuntu-22-04/

[Philippe Bernard (philippe-bernard)]

IF that can help, I can reproduce the issue, with the snap working with a user and failing with another one.

Setup a fresh Ubuntu Server 22 in a VirtualBox hosted on Windows (but I also reproduce the issue on a dedicated server). No extra packages apart from an SSH server.

Once Ubuntu is available, run:

# Install Chromium
$ sudo snap install chromium
(...)

# Launch Chromium (okay, just print its version)
$ chromium --version
Chromium 108.0.5359.124 snap

# Create another user
$ sudo adduser otheruser
(...)

# Log as the new user
$ sudo su otheruser

# I expect Chromium to be available for this new user but...
$ chromium --version
/user.slice/user-1000.slice/session-3.scope is not a snap cgroup

In the last error message, 1000 is the id of the initial user, the first user who installed Chromium and who can run it. Not the id of otheruser, the new user who can’t run Chromium.

When running SNAPD_DEBUG=1 snap run chromium, with the initial user (success):

$ SNAPD_DEBUG=1 snap run chromium
2022/12/27 19:28:50.299534 tool_linux.go:204: DEBUG: restarting into "/snap/snapd/current/usr/bin/snap"
2022/12/27 19:28:50.317267 logger.go:184: DEBUG: -- snap startup {"stage":"start", "time":"1672169330.317265"}
2022/12/27 19:28:50.322615 cmd_run.go:1037: DEBUG: executing snap-confine from /snap/snapd/17883/usr/lib/snapd/snap-confine
2022/12/27 19:28:50.323853 cmd_run.go:440: DEBUG: SELinux not enabled
2022/12/27 19:28:50.324980 tracking.go:46: DEBUG: creating transient scope snap.chromium.chromium
2022/12/27 19:28:50.326309 tracking.go:186: DEBUG: using session bus
(...)

With otheruser (failure):

otherphil@ubuntu-22:/home/philippe$ SNAPD_DEBUG=1 snap run chromium
2022/12/27 19:27:01.059280 tool_linux.go:204: DEBUG: restarting into "/snap/snapd/current/usr/bin/snap"
2022/12/27 19:27:01.075310 logger.go:184: DEBUG: -- snap startup {"stage":"start", "time":"1672169221.075289"}
2022/12/27 19:27:01.082983 cmd_run.go:1037: DEBUG: executing snap-confine from /snap/snapd/17883/usr/lib/snapd/snap-confine
2022/12/27 19:27:01.083514 cmd_run.go:440: DEBUG: SELinux not enabled
2022/12/27 19:27:01.083753 tracking.go:46: DEBUG: creating transient scope snap.chromium.chromium
2022/12/27 19:27:01.083813 tracking.go:189: DEBUG: session bus is not available: cannot find session bus
2022/12/27 19:27:01.083818 cmd_run.go:1224: DEBUG: snapd cannot track the started application
2022/12/27 19:27:01.083822 cmd_run.go:1225: DEBUG: snap refreshes will not be postponed by this process
(...)

So the first diff is on "session bus is not available: cannot find session bus".

[Philippe Bernard (philippe-bernard)]

The error described in comment 78 is due to the way the session is established.

When connecting directly, it works:

$ ssh philippe@myserver
$ chromium -v # Works

Whereas using sudo su generates an error:

$ ssh anotheruser@myserver
$ sud su philippe
$ chromium -v # not a snap cgroup

I think this was suggested by Tim in comment 36, but I admit I was not familiar enough with this topic to fully grasp how this could be addressed.

Also see https://forum.snapcraft.io/t/not-a-snap-cgroup-error-when-running-chromium/33243/3?u=pbernard

[Ron Simpkin (ronsimpkin)]

@Steve Fatula I resolved my issue with:

sudo loginctl enable-linger <user>

I'm not sure this is really the correct way to go about it, but it ensures that everything is there for the user when the cron process spawns.

[Jamie Davis (sichemist)]

For those of us who are using Xubuntu, X2Go and experiencing this problem, I have a work-around:

I had already switched firefox to the apt repository version, so I installed the chromium snap to test with. As expected, it failed to launch with the same issue mentioned at the top of this thread:

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

So, I added this file:

/etc/x2go/Xsession.d/96dbus-snap-fix

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

After logging out and back in via X2Go, the Chromium snap worked. It is my hope that this fixes snaps for ALL users without having to edit individual user login files (like .bashrc).

Edit:
I removed the PPA version of Firefox and replaced it with the snap. Working perfectly.

[Simon Andrews (xylan22)]

Another affected user. Here using VNC through Apache Guacamole with XFCE4 as a desktop manager. Similar errors to others:

$ firefox
2023/03/30 14:56:04.261227 cmd_run.go:1055: WARNING: cannot start document portal: Can't mount path /home/student/.cache/doc
/user.slice/user-1000.slice/session-1.scope is not a snap cgroup

The DBUS_SESSION_ADDRESS is set:

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-XNw4LGQaye,guid=488bab5d48a052fe381e2fa76425a2f9

..but the path it refers to doesn't exist.

If I try to check the systemd --user status I get:

$ systemd --user
Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

..so the fixes involving manually changing the DBUS address won't work.

All other graphical apps work, it's just the confined snap apps which don't.

[Russell Greene (russellgreeneshotover)]

For me installing `dbus-user-session` fixed this issue

[markling (markling)]

# I have this problem on a fresh install:

Xubuntu 22.04
Firefox 113.0.2 (snap)

# When I try to launch Firefox from the command line with a profile that is already running, I get an error reported to mu GUI:

"Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile."

# From the terminal I get the following error:

._. firefox -P default "https://forums.mozillazine.org/viewtopic.php?f=38&t=3097766"
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.

# My $DBUS_SESSION_BUS_ADDRESS reports thus from the terminal:

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

# also, note:

._. echo $XDG_RUNTIME_DIR
/run/user/1000

# systemd seems to think $DBUS_SESSION_BUS_ADDRESS is not set, so systemd --user gets an error:

._. sudo systemd --user
Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

# syslog seems to report no problems when Firefox is called. It runs with uid 1000.

# I have attached reports generated from: SNAPD_DEBUG=1 snap run firefox --profile-manager
# it does appear to have user value 1000 set

I would be grateful for any pointers.

[markling (markling)]

I may be mistaken in thinking that the Firefox I was using under 20.04 was not a snap.

All the same, launching new Firefox windows with the same session on different workspaces was a normal part of my day-to-day workflow until I upgraded to 22.04 a couple of weeks ago. I now get an error when I try it.

[ITEAS (info-tux-pc)]

With steamsnap it is the same. A new ENV for steam helps:

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

[Alexander Au (auism)]

Thanks for your comments and workarounds, I was using nomachine at a headless server with run target set to multi-user instead of graphical, and Firefox had this problem in the xsession created by nomachine.

My workaround is to edit the Firefox script itself, handily, /usr/bin/Firefox is a script instead of a binary, so I added

unset DBUS_SESSION_BUS_ADDRESS

towards the end of the script just before the last line calling presumably the Firefox binary.

Works like a charm, and feels good to know that only Firefox will be affected in case other programs need the DBUS_SESSION_BUS_ADDRESS to function properly.

Hope it helps.

[Andy Ruddock (andy-ruddock)]

I'm using VNC to access a desktop and experiencing just this issue. Using the "export DBUS_SESSION_BUS_ADDRESS" allows me to get a firefox window. I can't open file load/save dialogs from that session though, so can't import/export certificates & websites with file upload pages that use the standard file-picker dialog don't work.

To be fair though I'm fed up of being told that it's my configuration that must be wrong & I should be applying one of many random environment variable settings that I may find on the internet. If firefox works in, say, an xfce session by default & everything works, but it doesn't work in a similar session over VNC then something in the distro configuration is broken - simple as.

I've better things to do than try to apply workarounds to fix broken systems, so I'll use a distro that works. It seems that the team at Ubuntu is simply not ready to fully support the myriad ways of using desktop linux.

[Janus Kobain (jkobain)]

In GNOME Terminal:
$ chromium
/user.slice/user-1000.slice/[e-mail]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-404feab7-2748-4d47-ad69-3cceb67db014.scope is not a snap cgroup

In xterm:
$ chromium
/user.slice/user-1000.slice/session-2.scope is not a snap cgroup

$ lsb_release -a; uname -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy
Linux panama 5.15.0-85-generic #95-Ubuntu SMP Fri Sep 1 15:02:17 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Started happening out of nowhere several hours ago, now I'm afraid to restart Firefox.

UPD0: For me, this happened after I set SUID bit for /usr/bin/snap
This wasn't very smart on my end, but I managed to finally figure it out and fix it (by unsetting the SUID bit and changing ownership in ~/snap/ subdirectories). Thank you all.

[Tim Richardson (tim-richardson)]

Janus, your kernel is old and does not match a desktop (HWE) kernel for
22.04.3, so I guess this is a server install of Ubuntu. How are you
connecting to it?

On Tue, 17 Oct 2023 at 13:21, Janus Kobain <email address hidden>
wrote:

> In GNOME Terminal:
> $ chromium
> /user.slice/user-1000.slice/[e-mail]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-404feab7-2748-4d47-ad69-3cceb67db014.scope
> is not a snap cgroup
>
> In xterm:
> $ chromium
> /user.slice/user-1000.slice/session-2.scope is not a snap cgroup
>
>
> $ lsb_release -a; uname -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 22.04.3 LTS
> Release: 22.04
> Codename: jammy
> Linux panama 5.15.0-85-generic #95-Ubuntu SMP Fri Sep 1 15:02:17 UTC 2023
> x86_64 x86_64 x86_64 GNU/Linux
>
> Started happening out of nowhere several hours ago, now I'm afraid to
> restart Firefox.
>
> --
> 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

[Tim Richardson (tim-richardson)]

I doubt the kernel but a standard desktop install should have given you the
hwe kernel so something isn't right. There is no way you should get this
problem running Firefox in a standard desktop install. The bug is mostly
due to non standard logins and certainly a standard Ubuntu install delivers
snaps that work.

On Wed, 18 Oct 2023, 04:15 Janus Kobain, <email address hidden> wrote:

> Tim, this is a desktop installation of 22.04 LTS, I simply followed
> where package updates led me.
>
> After installing linux-generic-hwe-22.04-edge package:
> $ snap --version
> snap 2.60.4
> snapd 2.60.4
> series 16
> ubuntu 22.04
> kernel 6.2.0-36-generic
>
> $ firefox; chromium-browser
> /user.slice/user-1000.slice/[e-mail]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-97c582ae-0a89-4dc4-bef2-1a400d8b1688.scope
> is not a snap cgroup
> /user.slice/user-1000.slice/[e-mail]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-97c582ae-0a89-4dc4-bef2-1a400d8b1688.scope
> is not a snap cgroup
>
> Is the problem still in the kernel version?
>
> --
> 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
>
>

[mtu (mtu)]

As noted in #57, this bug _does_ occur on standard desktop installs, such as mine (updated from 21.10 to 22.04, thus taking firefox from .deb to snap).

[Tim Richardson (tim-richardson)]

If you find a way to reproduce it, for example installing into a VM in such
a way that you can trigger it, then it would be helpful. The point is that
there are millions of standard Ubuntu installs involving a few different
kernel versions and the only reports of it are a couple here. If a
developer can't reproduce it, they can't fix it.

On Wed, 18 Oct 2023 at 20:47, mtu <email address hidden> wrote:

> As noted in #57, this bug _does_ occur on standard desktop installs,
> such as mine (updated from 21.10 to 22.04, thus taking firefox from .deb
> to snap).
>
> --
> 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

[Andy Ruddock (andy-ruddock)]

Install VNC on a remote box (or VM), connect using VNC client, try to run firefox.
Stop telling users it's their fault for having mis-configured machines or using "non-standard logins" (whatever one of those is).
Jeez, I've been a fan of Ubuntu over the years, but this piece of functionality is simply broken for certain use-cases.

[Tim Richardson (tim-richardson)]

Hi, if you connect with VNC, then you are starting the session with the VNC
scripts, and this is actually an instance of the bug as I understand it, a
non-standard login. If this is how you reproduce it, you are simply
repeating what is common to the reports already here. There is something
wrong with the login process missing some part of the systemd setup. This
means it is not an Ubuntu or gnome or snapd or systemd problem, which is
why no one from this packages is interested in fixing it. It is not a snap
problem because snap is perfectly allowed to assume cgroups v2 are working
in our sessions.

On Sat, 21 Oct 2023 at 20:46, Andy Ruddock <email address hidden>
wrote:

> Install VNC on a remote box (or VM), connect using VNC client, try to run
> firefox.
> Stop telling users it's their fault for having mis-configured machines or
> using "non-standard logins" (whatever one of those is).
> Jeez, I've been a fan of Ubuntu over the years, but this piece of
> functionality is simply broken for certain use-cases.
>
> --
> 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

[Richard Brooksby (rptb1)]

Some clues:

If I start Ubuntu 22 with kernel argument `systemd.unit=multi-user.target` (i.e. non-graphical) then start Wayland with `XDG_SESSION_TYPE=wayland dbus-run-session gnome-session` then DBUS_SESSION_BUS_ADDRESS gets set to something like "DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-mcSf5L11K8,guid=b86aac9a59f39dddad072fc86546c3f8" and the Firefox snap errors with "/user.slice/user-1000.slice/session-1.scope is not a snap cgroup".

But Firefox launched with `DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" firefox` from a Terminal will run.

Note that DBUS_SESSION_BUS_ADDRESS is already set in the non-graphical shell before starting the Wayland session. It is overriden by dbus-run-session (as documented in the man page).

I don't understand these systems, but it would seem to me that the Firefox snap is assuming that it's being run from a top-level session. If a Wayland is started by a user with dbus-run-session then it can't talk to it because it's assuming the top level D-bus.

This might also be a clue as to why things don't work for remote sessions. Perhaps snaps assume (indirectly) that they're only being run in a top-level local session. A "standard session" if you like.

Incidentally, the Firefox is happy if I use `startx` to get a session.

[Tim Richardson (tim-richardson)]

it is more that systemd is not setup properly rather than snaps, but snaps
assume systemd cgroup is set up when other applications are not so fussy.
systemd-oomd also relies on cgroups and I wonder if it is broken too.
Anyway, the root cause of this is not snaps, but rather, snaps expose a bug
which has occurred before the graphical session even starts.
The DBUS_SESSION_BUS_ADDRESS is supposed to be set in the login process,
way before the graphical session starts,,so my own amateur investigations
agree with yours. There is a promise relating to the systemd "pam" login
steps which do this, and I guess our broken logins skip this, but there are
so many scripts involved that it hard to work out. It seems plausible that
this is relatively recent change to the login process which old tools with
custom login approaches have not been adapted to
 This is why I concluded that the problem that people are having is related
to the way the login is done by their remote access tool, be it nomachine
in my case or x2go or the vnc connections that first spawn a login (some
types of remote access simply connect to an existing session and these
would be immune from our problem).
However, I'm just repeating myself, and likewise I will no doubt get more
angry replies from people who believe this is a snap bug and are frustrated
about the snap developers ignoring it.

On Sun, 5 Nov 2023 at 09:55, Richard Brooksby <email address hidden>
wrote:

> Some clues:
>
> If I start Ubuntu 22 with kernel argument `systemd.unit=multi-
> user.target` (i.e. non-graphical) then start Wayland with
> `XDG_SESSION_TYPE=wayland dbus-run-session gnome-session` then
> DBUS_SESSION_BUS_ADDRESS gets set to something like
> "DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-
> mcSf5L11K8,guid=b86aac9a59f39dddad072fc86546c3f8" and the Firefox snap
> errors with "/user.slice/user-1000.slice/session-1.scope is not a snap
> cgroup".
>
> But Firefox launched with
> `DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" firefox` from
> a Terminal will run.
>
> Note that DBUS_SESSION_BUS_ADDRESS is already set in the non-graphical
> shell before starting the Wayland session. It is overriden by dbus-run-
> session (as documented in the man page).
>
> I don't understand these systems, but it would seem to me that the
> Firefox snap is assuming that it's being run from a top-level session.
> If a Wayland is started by a user with dbus-run-session then it can't
> talk to it because it's assuming the top level D-bus.
>
> This might also be a clue as to why things don't work for remote
> sessions. Perhaps snaps assume (indirectly) that they're only being run
> in a top-level local session. A "standard session" if you like.
>
> Incidentally, the Firefox is happy if I use `startx` to get a session.
>
> --
> 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

[Richard Brooksby (rptb1)]

Thank you for the clarifications, Tim. For what it's worth, my Ubuntu 22 non-graphical shell *does* have DBUS_SESSION_BUS_ADDRESS to the same value that appears in a Wayland session ("unix:path=/run/user/1000/bus"). So the bug you mention being exposed does not occur for me.

It is also set correctly for an RDP (remote desktop) login to a headless Ubuntu 22 machine with xrdp installed to provide the session. The Firefox snap starts happily in that session.

A local X session started with `startx` also produces a session in which the Firefox snap will run.

The only session that breaks Firefox for me is starting Wayland using `XDG_SESSION_TYPE=wayland dbus-run-session gnome-session`. I have not found any other way to get a Wayland session from the command line.

It's possible this is all evidence of this bug being fixed in Ubuntu 22, and all I have is a problem with starting Wayland correctly.

[Tim Richardson (tim-richardson)]

if by non graphical shell you mean a shell you arrive at via a local login,
I would not expect the bug to be present. The bug, as I understand it,
happens when the login process (not the UI) skips some step.
I can't imagine you would encounter this in any "official" login, such as
to a virtual terminal, or via ssh. Because I think the bug happens in the
login process and not the session start process, I have to predict that
using wayland vs xorg sessions would make no difference. \
It is interesting that xrdp works. I don't know how xrdp works as far as
starting sessions goes. But it is actively maintained unlike x2go so it
seems likely to me that it has "modern" log in methods so it may be fine.

I use nomachine workstation server and the most recent version release
notes specifically mention changes to the login process with respect to PAM
handling.
The systemd experts who have looked at this bug, including correspondence
I've had with them outside of this bug report, indicate that the problem
with x2go and nomachine look like a missing PAM step in the login process.
I will upgrade my server soon to check it out

regards
TIm

On Tue, 7 Nov 2023 at 05:16, Richard Brooksby <email address hidden>
wrote:

> Thank you for the clarifications, Tim. For what it's worth, my Ubuntu
> 22 non-graphical shell *does* have DBUS_SESSION_BUS_ADDRESS to the same
> value that appears in a Wayland session
> ("unix:path=/run/user/1000/bus"). So the bug you mention being exposed
> does not occur for me.
>
> It is also set correctly for an RDP (remote desktop) login to a headless
> Ubuntu 22 machine with xrdp installed to provide the session. The
> Firefox snap starts happily in that session.
>
> A local X session started with `startx` also produces a session in which
> the Firefox snap will run.
>
> The only session that breaks Firefox for me is starting Wayland using
> `XDG_SESSION_TYPE=wayland dbus-run-session gnome-session`. I have not
> found any other way to get a Wayland session from the command line.
>
> It's possible this is all evidence of this bug being fixed in Ubuntu 22,
> and all I have is a problem with starting Wayland correctly.
>
> --
> 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

[Rohit (proteus-1)]

I have similar problem with telegram-desktop on Kubuntu 23.10. Before the dist upgrade this snap used to work fine and could be launched from the application launcher. After the upgrade, the snap stopped working and no amount or remove or purge would make it work. I see this in syslog

> 2023-11-19T12:31:41.606068-08:00 thinky plasmashell[58460]: /user.slice/user-1000.slice/[e-mail]/app.slice/app-telegram\x2ddesktop_telegram\x2ddesktop-f2dadf1eb5b643f894123a937b68e08c.scope is not a snap cgroup

Launching telegram-desktop from the command line works just fine though.

[Benjamin (benj5378)]

Also had this issue on Ubuntu Serverusing crons and chromedriver, as well as with newly added user

cron.service is not a snapd cgroup.

Were able to fix it by `loginctl enable-linger ubuntu`

[Antony Shen (antony-shen)]

I've encountered similar issue, and my installation is Ubuntu Mate 22.04. After some tinkering I found a workaround that works for me. On my Ubuntu Mate, there is a file /etc/X11/Xsession.d/80mate-environment containing a command to unset DBUS_SESSION_BUS_ADDRESS, this seems cause the subsequnt call to dbus-launch thought it should use a default value generated by it; so my workaround is to comment the line, from

    unset DBUS_SESSION_BUS_ADDRESS

to

# unset DBUS_SESSION_BUS_ADDRESS

This works for me. Now Firefox or other none-classic snaps like telegram-desktop works fine.

[DRC (drcommander)]

I maintain TurboVNC, a modern Xvnc implementation derived originally from TightVNC and TigerVNC, and users have reported this problem both with the Firefox snap on Ubuntu 22.04 and with Podman on Fedora. I wanted to add some clarifying remarks:

- The reason why Linux remote desktop solutions such as TurboVNC call dbus-launch to create a unique session bus instance for each remote desktop session is because, if we don't, we can't have multiple simultaneous remote desktop sessions under the same user account. Granted that GNOME 3+ doesn't seem to officially support multiple simultaneous sessions, but in practice, it mostly works as long as each session has a unique session bus instance. MATE and Xfce fully work with multiple simultaneous sessions (except for cgroup issues like this, which aren't related to the window manager.)

- TigerVNC, in v1.11, adopted a completely different approach for launching VNC sessions, using a systemd service that emulates a GDM login. Thus, it is "fully baked" from systemd's point of view and doesn't experience this issue. However, the price you pay is that only root can start/stop VNC sessions, and only one session (including VNC and local sessions) can run simultaneously. Also, this new approach eliminated the ability to use TigerVNC on non-systemd operating systems (FreeBSD) at all. Referring to the tigervnc-users mailing list, it was a somewhat unpopular move, so we have chosen to stick with the traditional (vncserver) approach in TurboVNC. However, it would be really nice if we could figure out how to get what we want (multiple simultaneous sessions under the same user account) without having a "half-baked" desktop.

- As near as I can tell, you can get all of the benefits of TigerVNC's approach by simply foregoing the creation of a new session bus instance and using the one that systemd provides, with the caveat that only one session at a time can use the systemd-provided session bus instance. Someone who understands more about systemd than I do will have to tell me whether this is still half-baked (maybe 3/4-baked) or not, but it does eliminate this specific cgroup issue. (Those who care to experiment can use the latest pre-release build of TurboVNC, downloadable from https://turbovnc.org/DeveloperInfo/PreReleases, and set TVNC_SHAREDDBUS=1 in the environment to force a new session to use the systemd-provided session bus instance.)

- Setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus before launching Firefox, i.e. telling Firefox to use the systemd-provided session bus instance, is a problematic workaround. If another session, such as a local session, is using the systemd-provided session bus instance, then this will cause some of the dialogs in Firefox (for instance, the certificate import dialog) to appear in the other session rather than in the remote desktop session. If there is no session using the systemd-provided session bus instance, then those dialogs will not appear at all.

- Unsetting DBUS_SESSION_BUS_ADDRESS as a workaround avoids the aforementioned dialog issues, but I have seen Firefox complain about this, something to the effect of being unable to save something to ...

[Gerrit Venema (gmoniker)]

Encountered this problem while attempting to run a confined snap from a cronjob.

All that is wrong actually is that the systemd user session has not been properly setup.

I had to install dbus-user-session and then make sure the /run/user/../bus was initialized by for example runuser -u user /bin/true.
And make sure that it remains by loginctl enable-linger user

Cron by itself won't load pam_systemd in the session because it uses common-session-noninteractive in pam which doesn't load pam_systemd.

[Julian Andres Klode (juliank)]

Thanks for the bug report, unfortunately this has become quite convoluted and I've identified at least 3 different strands of discussion in here that are not related.

Some stuff, like "runuser" in a cron job is clearly never going to work, but I don't know how the other two instances - sessions without session busses and issues with VNC connections are affected.

I'd advise filing clear succinct reproducible issues for those cases, but I don't think there's much that can be done with this bug anymore.