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 multipass
started before apparmor.service completed.
** Also affects: snapd
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to zsys in Ubuntu.
https://bugs.launchpad.net/bugs/1871148
Title:
services start before apparmor profiles are loaded
Status in AppArmor:
Invalid
Status in snapd:
New
Status in apparmor package in Ubuntu:
Fix Released
Status in zsys package in Ubuntu:
Invalid
Status in apparmor source package in Focal:
Fix Released
Status in zsys source package in Focal:
Invalid
Bug description:
Per discussion with Zyga in #snapd on Freenode, I have hit a race
condition where services are being started by the system before
apparmor has been started. I have a complete log of my system showing
the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
Restarting apparmor using `sudo systemctl restart apparmor` is enough
to bring installed snaps back to full functionality.
Previously, when running any snap I would receive the following in the
terminal:
---
cannot change profile for the next exec call: No such file or directory
snap-update-ns failed with code 1: File exists
---
Updated to add for Jamie:
$ snap version
snap 2.44.2+20.04
snapd 2.44.2+20.04
series 16
ubuntu 20.04
kernel 5.4.0-21-generic
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
