I ran into this on a headless Ubuntu 22.04 server (systemd
249.11-0ubuntu3.21, unified cgroup v2) — not a desktop, and not after
suspend.
This appears to fix the issue without requiring a reboot (first command
might not be necessary):
systemctl --user reset-failed
systemctl --user daemon-reexec
LLM's hypothesis about what happened (sorry, unverified):
- `snap run` asks the per-user `systemd --user` manager to create a transient
scope
and move the snap process into it.
- That process lives in a login-session scope (session-N.scope) under the
root-owned user-<uid>.slice. The user manager cannot write the common
ancestor's
cgroup.procs (root:root), so the *direct* move is EPERM — by design.
- systemd handles that by having the user manager ask PID 1 to perform the
move over
the **system bus** (the "...or via the system bus" in the message; the
fallback
added in systemd PR #8125).
- If the user manager's system-bus connection is stale/broken, that
privileged call
fails and surfaces as EIO -> the scope can't be populated -> "transient
scope
could not be started."
- daemon-reexec makes the user manager reconnect, so the fallback works
again. A
reboot does the same by starting a fresh user manager.
I suspect that restarting the system D-Bus daemon in place was the
trigger for the bug in my case. Clients held a dead handle to the old
system bus.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1961898
Title:
chromium-browser is refusing to start
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1961898/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
