Session-101.scope is not a snap cgroup

Hi everyone, hope someone can help med with this issue.

I’m trying to log into the shell for a snap service, and it fails with this:

ubuntu@ubuntu:~$ sudo snap run --shell zwavejs2mqtt
/user.slice/user-1000.slice/session-101.scope is not a snap cgroup
ubuntu@ubuntu:~$ echo $?
1

I’ve tried to google for a solution, but it doesn’t seem to be a solution regarding snaps.

Anyone knows what I can to do fix it?

Please run sudo SNAPD_DEBUG=1 snap run --shell zwavejs2mqtt and attach the output. Also include what version of Ubuntu this is and how your session is set up (is this a desktop session? ssh? some minimal DE?).

Hi, thanks. Didn’t know of this env.var. Neat! This is the output:

2022/01/06 15:43:47.617495 tool_linux.go:204: DEBUG: restarting into "/snap/snapd/current/usr/bin/snap"
2022/01/06 15:43:47.691987 cmd_run.go:425: DEBUG: SELinux not enabled
2022/01/06 15:43:47.692570 cmd_run.go:1187: DEBUG: snapd cannot track the started application
2022/01/06 15:43:47.692627 cmd_run.go:1188: DEBUG: snap refreshes will not be postponed by this process
DEBUG: umask reset, old umask was  022
DEBUG: security tag: snap.zwavejs2mqtt.zwavejs2mqtt
DEBUG: executable:   /usr/lib/snapd/snap-exec
DEBUG: confinement:  non-classic
DEBUG: base snap:    core20
DEBUG: ruid: 0, euid: 0, suid: 0
DEBUG: rgid: 0, egid: 0, sgid: 0
DEBUG: apparmor label on snap-confine is: /snap/snapd/14296/usr/lib/snapd/snap-confine
DEBUG: apparmor mode is: enforce
DEBUG: creating lock directory /run/snapd/lock (if missing)
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: opening lock directory /run/snapd/lock
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: opening lock file: /run/snapd/lock/.lock
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: sanity timeout initialized and set for 30 seconds
DEBUG: acquiring exclusive lock (scope (global), uid 0)
DEBUG: sanity timeout reset and disabled
DEBUG: ensuring that snap mount directory is shared
DEBUG: unsharing snap namespace directory
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: releasing lock 5
DEBUG: opened snap-update-ns executable as file descriptor 5
DEBUG: opened snap-discard-ns executable as file descriptor 6
DEBUG: creating lock directory /run/snapd/lock (if missing)
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: opening lock directory /run/snapd/lock
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: opening lock file: /run/snapd/lock/zwavejs2mqtt.lock
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: sanity timeout initialized and set for 30 seconds
DEBUG: acquiring exclusive lock (scope zwavejs2mqtt, uid 0)
DEBUG: sanity timeout reset and disabled
DEBUG: initializing mount namespace: zwavejs2mqtt
DEBUG: setting up device cgroup
DEBUG: libudev has current tags support
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1 has matching current tag
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: get bpf object at path /sys/fs/bpf/snap/snap_zwavejs2mqtt_zwavejs2mqtt
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: found existing device map
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: get next key for map 8
DEBUG: found 25 existing entries in devices map
DEBUG: delete key for c 143:-1
DEBUG: delete elem in map 8
DEBUG: delete key for c 136:-1
DEBUG: delete elem in map 8
DEBUG: delete key for c 1:7
DEBUG: delete elem in map 8
DEBUG: delete key for c 140:-1
DEBUG: delete elem in map 8
DEBUG: delete key for c 10:239
DEBUG: delete elem in map 8
DEBUG: delete key for c 189:256
DEBUG: delete elem in map 8
DEBUG: delete key for c 1:5
DEBUG: delete elem in map 8
DEBUG: delete key for c 189:129
DEBUG: delete elem in map 8
DEBUG: delete key for c 188:0
DEBUG: delete elem in map 8
DEBUG: delete key for c 189:0
DEBUG: delete elem in map 8
DEBUG: delete key for c 138:-1
DEBUG: delete elem in map 8
DEBUG: delete key for c 5:1
DEBUG: delete elem in map 8
DEBUG: delete key for c 1:3
DEBUG: delete elem in map 8
DEBUG: delete key for c 142:-1
DEBUG: delete elem in map 8
DEBUG: delete key for c 189:2
DEBUG: delete elem in map 8
DEBUG: delete key for c 1:9
DEBUG: delete elem in map 8
DEBUG: delete key for c 189:128
DEBUG: delete elem in map 8
DEBUG: delete key for c 5:2
DEBUG: delete elem in map 8
DEBUG: delete key for c 10:200
DEBUG: delete elem in map 8
DEBUG: delete key for c 139:-1
DEBUG: delete elem in map 8
DEBUG: delete key for c 189:1
DEBUG: delete elem in map 8
DEBUG: delete key for c 137:-1
DEBUG: delete elem in map 8
DEBUG: delete key for c 1:8
DEBUG: delete elem in map 8
DEBUG: delete key for c 141:-1
DEBUG: delete elem in map 8
DEBUG: delete key for c 5:0
DEBUG: delete elem in map 8
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: load program of type 0xf, 33 instructions
DEBUG: set_effective_identity uid:0 (change: no), gid:0 (change: yes)
DEBUG: v2 allow c 1:3
DEBUG: v2 allow c 1:5
DEBUG: v2 allow c 1:7
DEBUG: v2 allow c 1:8
DEBUG: v2 allow c 1:9
DEBUG: v2 allow c 5:0
DEBUG: v2 allow c 5:1
DEBUG: v2 allow c 5:2
DEBUG: v2 allow c 136:4294967295
DEBUG: v2 allow c 137:4294967295
DEBUG: v2 allow c 138:4294967295
DEBUG: v2 allow c 139:4294967295
DEBUG: v2 allow c 140:4294967295
DEBUG: v2 allow c 141:4294967295
DEBUG: v2 allow c 142:4294967295
DEBUG: v2 allow c 143:4294967295
DEBUG: v2 allow c 10:239
DEBUG: v2 allow c 10:200
DEBUG: inspecting type of device: /dev/bus/usb/001/001
DEBUG: v2 allow c 189:0
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-0:1.0 has matching current tag
DEBUG: cannot get major/minor numbers for syspath /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-0:1.0
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1 has matching current tag
DEBUG: inspecting type of device: /dev/bus/usb/001/002
DEBUG: v2 allow c 189:1
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3 has matching current tag
DEBUG: inspecting type of device: /dev/bus/usb/001/003
DEBUG: v2 allow c 189:2
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0 has matching current tag
DEBUG: cannot get major/minor numbers for syspath /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0/tty/ttyUSB0 has matching current tag
DEBUG: inspecting type of device: /dev/ttyUSB0
DEBUG: v2 allow c 188:0
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1:1.0 has matching current tag
DEBUG: cannot get major/minor numbers for syspath /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1:1.0
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2 has matching current tag
DEBUG: inspecting type of device: /dev/bus/usb/002/001
DEBUG: v2 allow c 189:128
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-0:1.0 has matching current tag
DEBUG: cannot get major/minor numbers for syspath /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-0:1.0
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2 has matching current tag
DEBUG: inspecting type of device: /dev/bus/usb/002/002
DEBUG: v2 allow c 189:129
DEBUG: device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/2-2:1.0 has matching current tag
DEBUG: cannot get major/minor numbers for syspath /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/2-2:1.0
DEBUG: device /sys/devices/platform/soc/fe980000.usb/usb3 has matching current tag
DEBUG: inspecting type of device: /dev/bus/usb/003/001
DEBUG: v2 allow c 189:256
DEBUG: device /sys/devices/platform/soc/fe980000.usb/usb3/3-0:1.0 has matching current tag
DEBUG: cannot get major/minor numbers for syspath /sys/devices/platform/soc/fe980000.usb/usb3/3-0:1.0
DEBUG: process in cgroup /user.slice/user-1000.slice/session-101.scope
/user.slice/user-1000.slice/session-101.scope is not a snap cgroup

I undestand that you are trying to run a service as a user? This isn’t entirely suppoted, but still possible if you invoke it through snap run. Looking at the code the snap command does not behave correctly, but rather blindly assumes that systemd is tracking the process already (which is true for a service), and proceeds further. When execution reaches snap-confine, the assumption is verified since it may be introducing changes that affect the current cgroup. Verification fails and further execution is stopped.

Edit: filed a bug https://bugs.launchpad.net/snapd/+bug/1956917

Hi, no I’m not. I’m running the service as default user (root).

I’m also invoking the command as root, not as myself.

Well root is still a user (though a special one). What I mean, is that zwavejs2mqtt is declared as a daemon, and thus it is expected that it is started by systemd and thus executes in a service specific cgroup which systemd creates for it. In your case, the daemon process is started by a user (through sudo or not), thus it runs your cgroup (usually session-<nnn>.scope). Also, zwavejs2mqtt has access to devices, thus snap-confine will try to set up device access filtering. On a system with unified hierarchy, device filtering can only be established on a cgroup, so /usr/bin/snap asks systemd to create a new cgroup (transient scope, named after the snap), and moves the process over to that group, such that by the time snap-confine executes it can enable device filtering on the group and not break your session in the process.

The fix has landed in master, and should be available in snapd edge channel soon.

1 Like

Thank you so much for taking action on this. Highly appreciated.