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

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

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.

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?

$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

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

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.

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.

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

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

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.

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

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?

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.

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?

$ 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.

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.

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

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

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.

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)

I All,

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

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

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)

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"

@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"

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.

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/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-b5b3e096-ebb3-4eca-b9d1-d07ca7028b22.scope/init.scope is not a snap cgroup

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

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"

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

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

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?

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.

 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.

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.

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.

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

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.

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.

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.

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

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

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.

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

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.

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.

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

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/user@1000.service/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.

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/user@1000.service/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

I am experiencing this problem too. using VNC (tigervnc-standalone-server).
I read the entire thread. I tried damn near all of the workarounds. None worked.

The symptom is that I can't start Firefox in my xfce4 session .
madbrain@u22041:~/Desktop$ firefox
/system.slice/vncserver.service is not a snap cgroup

Here is my xstartup :

madbrain@u22041:~/.vnc$ cat xstartup
#!/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 &

And my systemd unit :

[Unit]
Description=Tiger VNC server
After=syslog.target network.target

[Service]
Type=forking
User=madbrain
PIDFile=/home/madbrain/.vnc/%H:5902.pid
ExecStartPre=-/usr/bin/vncserver -kill :2 > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -geometry 3840x2160 -localhost no :2
ExecStop=/usr/bin/vncserver -kill :2

[Install]
WantedBy=multi-user.target

I think the issue is related to my systemd. If I start
vncserver :2
from a terminal, then Tim's workaround from comment 31 works.*

But if I start it through systemd, it fails.

I think the issue here is that snaps (with cgroupsv2) require a systemd user session and some desktop environments do not set this up? It's not clear to me what needs to change here -- should snapd be more tolerant of this situation or should the other desktop environments change to set the necessary environment variables?

IMHO it's not reasonable for any software to absolutely require an environment variable that's not already set in a default console login. We all need to build better software that still works without environment variables.

Also changing multiple desktop environments now and into the future doesn't scale.

This is not a snap problem. I don't think it is a problem with standard
Linux desktops either. The problem seems to be entirely reported for remote
desktop sessions,.somehow they have missed something modern systemd sets up
at login.

On Mon, 17 Oct 2022, 13:40 Daniel van Vugt, <email address hidden>
wrote:

> IMHO it's not reasonable for any software to absolutely require an
> environment variable that's not already set in a default console login.
> We all need to build better software that still works without
> environment variables.
>
> Also changing multiple desktop environments now and into the future
> doesn't scale.
>
> --
> 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
>
>

Just thought I'd add a 'me too' although my situation is slightly different in that 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.

Unfortunately, I must disagree with Tim in #55: This problem affects me on a standard desktop, with absolutely no remote access involved. I'm running 22.04, which I updated from 21.10 with KDE Plasma, and firefox intermittently(!) will not start, spouting the "not a snap cgroup" error message (logged to ~/.xsession-errors).

To be more precise: Launching firefox from the .desktop launcher in Plasma will _sometimes_ (but not always!) fail with the abovementioned snap/cgroup error.

However, launching firefox from the console with the "firefox" command will _always_ work correctly, as well as executing a keyboard shortcut that runs the "firefox" command.

just to add some extra context:
dbus-daemon[26236]: [session uid=1001 pid=26236] Activating service name='org.freedesktop.portal.Documents' requested by ':1.0' (uid=1001 pid=26249 comm="/snap/bin/chromium.chromedriver --port=9515 " label="unconfined")
dbus-daemon[26236]: [session uid=1001 pid=26236] Activating service name='org.freedesktop.impl.portal.PermissionStore' requested by ':1.1' (uid=1001 pid=26269 comm="/usr/libexec/xdg-document-portal " label="unconfined")
dbus-daemon[26236]: [session uid=1001 pid=26236] Successfully activated service 'org.freedesktop.impl.portal.PermissionStore'
dbus-daemon[26236]: [session uid=1001 pid=26236] Successfully activated service 'org.freedesktop.portal.Documents'
cmd_run.go:1055: WARNING: cannot start document portal: Expected portal at "/run/user/1001/doc", got "/home/test_user/.cache/doc"
dbus-daemon[26236]: [session uid=1001 pid=26236] Activating service name='org.freedesktop.systemd1' requested by ':1.0' (uid=1001 pid=26249 comm="/snap/bin/chromium.chromedriver --port=9515 " label="unconfined")
dbus-daemon[26236]: [session uid=1001 pid=26236] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
/system.slice/cron.service is not a snap cgroup

Tim, I'm not sure where you got that impression about remote desktops (re #55), but I'm the original reporter and I reported the problem on a local openbox session (see comment #6). My impression was that most of the people chiming in were similar to me, running local sessions with various window managers other than gnome or kde.

The problem was identified as the session not being established correctly
in some instances, and those instances were 100% involved in non-mainstream
session starts (nomachine or other remote session starts such as X2Go).
The fixes apart from disabling cgroups v2 involve simulating one aspect of
a successful login.

It seems that the login process of these sessions skips something that
systemd now requires. X2Go for instance is old and it is not surprising
perhaps. I think the problem is happening at login not when the gui shell
is started.
I don't know openbox, but if you consistently get this problem, may be that
is the reason. So the common element is not remote desktop as such, but old
and non-compliant login process (I hypothesize). I hope you report this
back to openbox and they have people interesting in investigating it.
Nomachine is a blackbox (non open source) and I don't think X2Go has
development effort.

 Obviously a standard gnome, plasma or xfce session does not get the
problem, because if Ubuntu, Kubuntu and Xubuntu users couldn't use the
default browser, we would know about it. All the complaining about slow
start times would be nothing to the browser not actually starting.

There are some reports here of people using gnome and encountering the
problem. I can not explain that, except that there may be another root
cause, or those systems may be strangely misconfigured. Also, it is not a
snap bug and if snap needs to run in a v2 cgroup and the session can't
enable this, what do you propose that snapd do about it?

On Thu, 20 Oct 2022 at 08:20, Akkana Peck <email address hidden>
wrote:

> Tim, I'm not sure where you got that impression about remote desktops
> (re #55), but I'm the original reporter and I reported the problem on a
> local openbox session (see comment #6). My impression was that most of
> the people chiming in were similar to me, running local sessions with
> various window managers other than gnome or kde.
>
> --
> 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

Akkana, what login manager are you using with openbox?

On Thu, 20 Oct 2022 at 14:57, Tim Richardson <email address hidden> wrote:

> The problem was identified as the session not being established correctly
> in some instances, and those instances were 100% involved in non-mainstream
> session starts (nomachine or other remote session starts such as X2Go).
> The fixes apart from disabling cgroups v2 involve simulating one aspect of
> a successful login.
>
> It seems that the login process of these sessions skips something that
> systemd now requires. X2Go for instance is old and it is not surprising
> perhaps. I think the problem is happening at login not when the gui shell
> is started.
> I don't know openbox, but if you consistently get this problem, may be
> that is the reason. So the common element is not remote desktop as such,
> but old and non-compliant login process (I hypothesize). I hope you report
> this back to openbox and they have people interesting in investigating it.
> Nomachine is a blackbox (non open source) and I don't think X2Go has
> development effort.
>
> Obviously a standard gnome, plasma or xfce session does not get the
> problem, because if Ubuntu, Kubuntu and Xubuntu users couldn't use the
> default browser, we would know about it. All the complaining about slow
> start times would be nothing to the browser not actually starting.
>
> There are some reports here of people using gnome and encountering the
> problem. I can not explain that, except that there may be another root
> cause, or those systems may be strangely misconfigured. Also, it is not a
> snap bug and if snap needs to run in a v2 cgroup and the session can't
> enable this, what do you propose that snapd do about it?
>
>
> On Thu, 20 Oct 2022 at 08:20, Akkana Peck <email address hidden>
> wrote:
>
>> Tim, I'm not sure where you got that impression about remote desktops
>> (re #55), but I'm the original reporter and I reported the problem on a
>> local openbox session (see comment #6). My impression was that most of
>> the people chiming in were similar to me, running local sessions with
>> various window managers other than gnome or kde.
>>
>> --
>> 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

I'd like to re-interate that I use a regular Kubuntu installation, freshly installed as 21.10 and later upgraded to 22.04 (a few months after 22.04 was released). During the upgrade to 22.04, the dpkg firefox was replaced by the snap firefox. That's when the problem appeared.

hi @mtu, in that case no confined snaps will work for you, which you are
probably noticing. Something is wrong with your installation, I think. At a
wild guess, try installing gdm3 and making it default. Or reinstall.
Speaking from my own experience, I have not seen this once in any upgrades
or installs (from a sample size including VMs which is > 10, one of which
is kubuntu 22.04 -> 22.10)

On Thu, 20 Oct 2022 at 19:51, mtu <email address hidden> wrote:

> I'd like to re-interate that I use a regular Kubuntu installation,
> freshly installed as 21.10 and later upgraded to 22.04 (a few months
> after 22.04 was released). During the upgrade to 22.04, the dpkg firefox
> was replaced by the snap firefox. That's when the problem appeared.
>
> --
> 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

@mtu and make sure that systemd is properly installed, how you check this I
don't know.

On Fri, 21 Oct 2022 at 08:13, Tim Richardson <email address hidden> wrote:

> hi @mtu, in that case no confined snaps will work for you, which you are
> probably noticing. Something is wrong with your installation, I think. At a
> wild guess, try installing gdm3 and making it default. Or reinstall.
> Speaking from my own experience, I have not seen this once in any upgrades
> or installs (from a sample size including VMs which is > 10, one of which
> is kubuntu 22.04 -> 22.10)
>
> On Thu, 20 Oct 2022 at 19:51, mtu <email address hidden> wrote:
>
>> I'd like to re-interate that I use a regular Kubuntu installation,
>> freshly installed as 21.10 and later upgraded to 22.04 (a few months
>> after 22.04 was released). During the upgrade to 22.04, the dpkg firefox
>> was replaced by the snap firefox. That's when the problem appeared.
>>
>> --
>> 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

This happened to me on a fresh install of Xubuntu 22.04 when using X2Go. Local sessions don't have this problem. I can work around it by setting the environment variable (as specified in message 31) DBUS_SESSION_BUS_ADDRESS before running firefox.

I'd like to get this fixed as we use X2go extensively at my office, and we'll be stuck on Ubuntu 20.04 until this is fixed. It sounds like a new x2go (bug) integration issue starting with 22.04.

Tim Richardson is probably right that X2go is not doing something the way systemd expects, and that therefore x2go is 'old'. Is there a 'new' remote access tool that is known to work?

I rather like x2go and would love to port the 'new' solution to x2go if I knew what exactly needed to be done.

I looked here for information about what the right way to do this, but it's not clear from that page where to go for the steps I need: https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html

I also looked in the the source for x2go:
https://code.x2go.org/releases/source/
But I have yet to find the code responsible for this bug or any clue about what it should be changed to.

I also find related bug reports dating back many years, but it's just clues, not a clear explanation of what's being done 'the old way' and what the new way should look like:
https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1046

I'm looking for a bug report for this bug on the x2go side, but I can't find one. Does anyone know if one is open, or should I open a fresh one?

The closest related bug report I could find was this:
https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=814

Once I have a proper bug report found/opened, if anyone with a slightly deeper knowledge of how to fix this could give me some clues of where to look or what to fix, that would be great.

After a lot of digging, it seems that I have an unexpected, but simple work-around for getting firefox to work under x2go on ubuntu 22.04:

Add to ~/.bashrc:
unset DBUS_SESSION_BUS_ADDRESS

I tried putting this unset command in xinitrc right before xfce4-session is run. No luck.

I tried the unset in a custom script that calls xfce4-session from x2go: no luck.

I tried the unset in 95bdbu_update-activation-env: no luck.

It seems that xfce4-session is restoring the environment variable. This is unexpected, and may represent a bug in xfce4-session, or possibly in ubuntu's latest changes. I looked in the source for xfce4-session, but it wasn't readily obvious that it was doing anything that would cause this to be set.

I'd love to produce a proper fix if someone can give me a clue where to look, but at least I/we have a quick work-around.

Can anyone else confirm that this fix works for them?

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.

@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

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

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.

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

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

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

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?

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.

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/

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".

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

@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.

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.

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.

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

# 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.

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.

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

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

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.

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.

In GNOME Terminal:
$ chromium
/user.slice/user-1000.slice/user@1000.service/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.

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/user@1000.service/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

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/user@1000.service/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/user@1000.service/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
>
>

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

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