Comment 22 for bug 1871148

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 ;)