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
@eurbah hi, also for the service in question, can you attach the output
of `systemctl list-dependencies --after snap..service`
AFAICT, all services are to be started after snapd.apparmor.d, which in
turn is started after apparmor.service, which should ensure that
apparmor profiles are loaded befor
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 t
Let me reiterate what I mentioned in the MM channel. The snap in
question apparently uses device access in which case we'll set up device
filtering. The host being impish, uses cgroup v2, which percolates to
the container. Since it's v2, device filtering is implemented by
attaching a BPF program on
If this happens again try running `SNAPD_DEBUG=1 snap run telegram-
desktop` and collect the log. Since 22.04 is using unified hierarchy, we
try to ask your session's systemd to create a transient scope for it. In
your case, the log indicates that this operation failed. Looking at the
log:
Feb 23
@gsunipipeline it looks like systemd does not operate correctly in your
system. This is a prerequisite for even accessing the snapd daemon,
since we rely on systemd to provide the socket, then activate snapd
daemon, and the snapd daemon directly interacts with systemd to set up
snaps.
** Also aff
The error indicates that snapd is still in the process of early init &
setting up device. Ideally it's enough to wait for seed.loaded event,
(snap wait system seed.loaded). This is what snapd.seeded.service does,
but from the piece of log you provided, the service did not start,
because its depende
Possibly related: https://github.com/systemd/systemd/issues/3388
** Bug watch added: github.com/systemd/systemd/issues #3388
https://github.com/systemd/systemd/issues/3388
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sy
Public bug reported:
Observed on 18.04. Systemd user instance fails when trying to create a
transient scope when logged in through ssh as a regular user
Specifically this fails:
$ systemd-run --user --scope ls
Job for run-rc78f932ad730440490bd7bc17f9d5c8c.scope failed.
See "systemctl status run-r
** Changed in: snapd
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1934147
Title:
systemd leaks abandoned session scopes
Status in snapd:
We also have a change in snapd source code that will no longer show
these messages: https://github.com/snapcore/snapd/pull/10756
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to language-pack-pt-base in
Ubuntu.
https://bugs.lau
Nonetheless it isn't clear whether it's a snapd problem or the actual
libraries. Switching to confirmed in snapd, but needs investigation from
desktop team too.
** Changed in: snapd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
I've seen this happen occasionally with snaps on Arch too.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to humanity-icon-theme in
Ubuntu.
https://bugs.launchpad.net/bugs/1861558
Title:
Snap 'ed applicaitons have garbage on
Not sure whether removing files that came with distro packages is the
best idea long term. I think a better option would be to drop in a
custom rule that runs before the default ones. As usual ArchWiki has
some examples:
https://wiki.archlinux.org/index.php/Polkit#Administrator_identities
Specific
I looked at the policy used by PackageKit. I believe gnome-software uses
it as a backend, so can you try installing something that is
specifically not a snap?
At this point, all snapd does is ask PolicyKit whether given the policy,
the user can install a package. PolicyKit responds with yes, there
@jjohansen thank you for looking into this!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1824384
Title:
libapparmor not built with -fPIC
Status in apparmor package in
Public bug reported:
Attempted to build snap-confine with DEB_BUILD_MAINT_OPTIONS =
hardening=+pie. The build fails with:
mv -f snap-confine/.deps/snap_confine_snap_confine-user-support.Tpo
snap-confine/.deps/snap_confine_snap_confine-user-support.Po
17 matches
Mail list logo
