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, prior to upgrading apparmor, I
saw:
$ 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 start is printed after the "+" character.
apparmor.service +11.135s
└─local-fs.target @4.376s
└─zfs-mount.service @4.327s +48ms
└─var-lib-dpkg.mount @4.188s +137ms
└─var-lib.mount @3.883s +250ms
└─zfs-import.target @3.829s
└─zfs-import-cache.service @3.125s +704ms
└─zfs-load-module.service @3.121s +2ms
└─systemd-udev-settle.service @1.183s +1.937s
└─systemd-udev-trigger.service @933ms +248ms
└─systemd-udevd-kernel.socket @886ms
└─system.slice @535ms
└─-.slice @535ms
Note that var-lib.mount is already listed. On reboot though (without
updating apparmor), I see:
$ 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 start is printed after the "+" character.
apparmor.service +101ms
└─local-fs.target @2.812s
└─run-user-122.mount @5.172s
└─swap.target @1.823s
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap
@1.799s +22ms
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device
@1.798s
Oddly, no zfs entries are listed apparently because local-fs.target
isn't pulling them in:
$ sudo systemd-analyze critical-chain local-fs.target
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
local-fs.target @2.812s
└─run-user-122.mount @5.172s
└─swap.target @1.823s
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap
@1.799s +22ms
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device
@1.798s
Looking at var-lib.mount, I see zfs is in there:
$ sudo systemd-analyze critical-chain var-lib.mount
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
var-lib.mount +179ms
└─zfs-import.target @2.248s
└─zfs-import-cache.service @1.845s +402ms
└─zfs-load-module.service @1.840s +2ms
└─systemd-udev-settle.service @692ms +1.143s
└─systemd-udev-trigger.service @524ms +167ms
└─systemd-udevd-kernel.socket @494ms
└─system.slice @357ms
└─-.slice @357ms
So why after a reboot did the dependencies change and drop the /var/lib
entry from local-fs.target?
I then upgraded apparmor to have the RequiresMountsFor
/var/lib/snapd/apparmor/profiles, rebooted and saw no difference:
$ 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 start is printed after the "+" character.
apparmor.service +222ms
└─local-fs.target @2.562s
└─run-user-122.mount @4.834s
└─swap.target @1.687s
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap
@1.663s +24ms
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device
@1.662s
** Changed in: zsys (Ubuntu Focal)
Status: Invalid => 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 apparmor package in Ubuntu:
Fix Released
Status in zsys package in Ubuntu:
New
Status in apparmor source package in Focal:
Fix Released
Status in zsys source package in Focal:
New
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 : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
