Thanks Alberto :
Re-enabling the snapd.apparmor service has fixed my issue.
Therefore, I have migrated my issue to a contribution to
https://bugs.launchpad.net/snapd/+bug/1806135
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags removed: jammy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871148
Title:
services start before apparmor profiles are loaded
To manage notifications about this bug go to:
Oh, this is interesting! Then, Etienne, my suggestion is the following:
re-enable the snapd.apparmor service, and if that (as I expect) fixes
the bug, let's stop discussing this issue here, and instead open a
separate issue about the service being disabled.
It may be that something went wrong
$ systemctl status snapd.apparmor
○ snapd.apparmor.service - Load AppArmor profiles managed internally by snapd
Loaded: loaded (/lib/systemd/system/snapd.apparmor.service; disabled;
vendor preset: enabled)
Active: inactive (dead)
I do NOT remember having manually disabled this service.
Oh, thanks Alex, I forgot that we have our own service for loading the
AppArmor profiles of the snaps!
Etienne, could you please show the output of
sudo systemctl status snapd.apparmor
?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
@mardy I thought we had snapd.apparmor specifically to avoid this
scenario but I can't see that service mentioned at all in systemd-
analyze plot...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Inside the attached journal for the 'apparmor.service' unit, I do NOT
understand at all which "DENIED" messages are normal and which are
abnormal.
For independent reasons, I would like to keep my machine running for several
days (or weeks).
But after I reboot, and before running the
Yes, on the slower machine (where I am seeing this issue), I will NOT be
able to start firefox until I have run that apparmor_parser command.
Not even if I try starting firefox well after the login.
$ ls -l /etc/apparmor.d/disable
total 0
lrwxrwxrwx. 1 root root 31 août 27 2019 usr.bin.firefox
Thanks Etienne, this is a bit surprising! Do I understand correctly,
that on the slower machine (where you are seeing this bug) you will not
be able to start firefox until you have run that apparmor_parser
command? Not even if you try starting firefox well after the login?
It's strange, because
** Attachment added: "systemd-analyze-plot-sirius-2022-05-18.svg"
https://bugs.launchpad.net/apparmor/+bug/1871148/+attachment/5590993/+files/systemd-analyze-plot-sirius-2022-05-18.svg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
The issue that I am seeing is exactly the one explained in the bug
description.
More precisely, on my slower machine, each time I start firefox (which is now a
snap) from a terminal, following error message is displayed :
cannot change profile for the next exec call: No such file or directory
@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
Hi Etienne, can you be a bit more explicit about what is the issue that
you are seeing? What are the services which are not starting?
Also please attach the SVG file generated by "sudo systemd-analyze
plot", it might help us.
--
You received this bug notification because you are a member of
With snapd 2.55.3+22.04ubuntu1 and apparmor 3.0.4-2ubuntu2 from Ubuntu
22.04 (Jammy Jellyfish) :
- On a machine with a powerful i7-7700 HQ processor, the issue did NOT
appear yet.
- On a machine with the slower AMD FX-8370E processor, the issue occurs
systematically after each reboot.
$
** Tags added: jammy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871148
Title:
services start before apparmor profiles are loaded
To manage notifications about this bug go to:
This was fixed in snapd in 2.44 via
https://github.com/snapcore/snapd/pull/8467
** Changed in: snapd (Ubuntu)
Status: In Progress => Fix Released
** Changed in: snapd (Ubuntu Focal)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member
Adding a snapd Ubuntu task, marking as In Progress and assigning to mvo
since he is preparing a 20.04 upload.
** Also affects: snapd (Ubuntu)
Importance: Undecided
Status: New
** Changed in: snapd (Ubuntu Focal)
Assignee: (unassigned) => Michael Vogt (mvo)
** Changed in: snapd
** Changed in: snapd
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871148
Title:
services start before apparmor profiles are loaded
To manage
I've pushed a tentative fix for this to
https://github.com/snapcore/snapd/pull/8467
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871148
Title:
services start before apparmor profiles are loaded
** Changed in: snapd
Status: New => In Progress
** Changed in: snapd
Assignee: (unassigned) => Zygmunt Krynicki (zyga)
** Changed in: snapd
Importance: Undecided => High
** Changed in: snapd
Milestone: None => 2.44.3
--
You received this bug notification because you are a
Daniel, this is a different cause but same result:
zfs-load-module.service (2ms)
zfs-import-cache.service (8ms)
zfs-import.target
...
var-lib.mount (69ms)
...
snap-multipass-1869.mount (1.358s)
...
apparmor.service (279ms)
...
In this case, apparmor correctly waited for var.lib.mount, but
Adding a snapd bug task.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871148
Title:
services start before apparmor profiles are loaded
To manage notifications about this bug go to:
** Attachment added: "1871148-vm-no-varlib-mount_diddledan.svg"
https://bugs.launchpad.net/apparmor/+bug/1871148/+attachment/5350256/+files/1871148-vm-no-varlib-mount_diddledan.svg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Daniel responded on irc and said after several reboots with the new
apparmor, everything was fine on every boot (though his critical-chain
has var.lib.mount listed).
My attached systemd-analyze plot svg shows that apparmor.service is
indeed starting after var.lib.mount on the VM where the
Here is an 'sudo systemd-analyze plot > ./1871148-vm-no-varlib-
mount.svg' on a focal VM that reports the following critical-chain:
$ sudo systemd-analyze critical-chain apparmor.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to
Seth wrote:
I have to think the better approach may have been to introduce something
like apparmor@.service and configure an apparmor@snapd.service that will
load profiles before snapd is started -- at least if snap is not itself
loading profiles before launching programs.
Note that snapd is
All that said, Daniel and Jean-Baptiste, I installed 20.04 in a vm and
tried to reproduce this and could not. The apparmor change was about
correctness of the unit so I performed the upload, but I also hoped that
it would address the issue you are seeing.
I'm not certain it will. On one boot,
Marking the zsys task back to New based on my last comment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871148
Title:
services start before apparmor profiles are loaded
To manage notifications
Seth, the service starts fine if snapd is not installed and the
mountpoint is not present.
$ sudo systemctl status apparmor
● apparmor.service - Load AppArmor profiles
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor
preset: enabled)
Active: active (exited) since
Jamie, what happens on systems without snap installed? Will systemd
start the apparmor service?
How much later does this push the already-too-late apparmor service?
Requiring a potentially new thing may push the apparmor unit further
behind, allowing even more services to start before profiles
This bug was fixed in the package apparmor - 2.13.3-7ubuntu4
---
apparmor (2.13.3-7ubuntu4) focal; urgency=medium
* debian/apparmor.service: add /var/lib/snapd/apparmor/profiles to
RequiresMountsFor since Ubuntu's rc.apparmor.functions looks for it
(LP: #1871148)
*
@jibel, can you explain how the mount generator makes local-fs.target
satisfied *before* /var/lib is mounted?
I think this is worth investigating.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
There is nothing to do on zsys's side. mount points are generated by the zfs
generator and mount order is set by systemd. apparmor must wait until all its
requirements are met to start which is what Jamie's fix does.
Closing zsys task.
** Changed in: zsys (Ubuntu Focal)
Importance: Critical
I uploaded 2.13.3-7ubuntu4 to address this:
https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu4
There might be other fixes for zsys, but this should address the issue
in snapd. It is currently in unapproved, but a member of the release
team will hopefully approve it soon.
** Changed
Reassigning the snapd task to apparmor in Ubuntu since it has a patch to
rc.apparmor.functions to look for /var/lib/snapd/apparmor/profiles but
does not add it to RequiresMountsFor.
** Project changed: snapd => apparmor
** Changed in: apparmor
Status: Confirmed => In Progress
** Changed
** Also affects: zsys (Ubuntu)
Importance: Undecided
Status: New
** Changed in: zsys (Ubuntu)
Status: New => Confirmed
** Changed in: zsys (Ubuntu)
Importance: Undecided => Critical
** Also affects: zsys (Ubuntu Focal)
Importance: Critical
Status: Confirmed
**
36 matches
Mail list logo
