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 critical-chain
didn't show it or zfs. On irc Didier thought that critical-chain would
only list the longest path to apparmor.service starting and may not show
everything (the man page isn't clear on this point IMHO).
Based on all of this, I'm going to tentatively mark the zsys task back
to Invalid. If people continue to see this bug, we can reopen as
necessary (in which case it might be a systemd task for not generating
the mount units/requires/after correctly/in a race-free manner or it
might indicate zfs initialization is perhaps slow and apparmor.service
is starting before var.lib.mount is generated (and therefore
RequiresMountsFor is satisfied. Or it is something else ;)
** Changed in: zsys (Ubuntu Focal)
Status: New => Invalid
--
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:
https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
