Comment # 5 on bug 1015249 from Christian Boltz

(In reply to Ulrich Windl from comment #3)
> /var is from BtrFS (/var/lib/machines is a subvolume mount of the same
> device).
> Jan 02 07:53:24 linux-n9gv kernel: AppArmor: AppArmor initialized
> Jan 02 07:53:45 linux-n9gv systemd[1]: var.mount: Directory /var to mount
> over is not empty, mounting anyway.

That explains it.

> So blame systemd for that?

I have "better" things to blame systemd for ;-) but they are slightly OT here.

In this case, AppArmor doesn't specify a dependency on local-fs, so I'm not too
surprised about the order.

> Why not fix the mount/execution order?

Because AppArmor profiles should be loaded as early as possible.

If a process was started before loading its AppArmor profile, it will run
unconfined forever - you can't "apply" an AppArmor profile on it. (Well, at
least unless you restart it, but that results in a new process.)

Note that reloading profiles is different - if a process is already running
with AppArmor confinement, the updated profile will be used for it.