http://bugzilla.opensuse.org/show_bug.cgi?id=1015249
http://bugzilla.opensuse.org/show_bug.cgi?id=1015249#c5
--- Comment #5 from Christian Boltz
/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. -- You are receiving this mail because: You are on the CC list for the bug.