Hello, Am Donnerstag, 4. Januar 2018, 16:18:24 CET schrieb Thorsten Kukuk:
On Wed, Jan 03, Christian Boltz wrote:
For now, I can offer two workarounds: - rcapparmor reload while /var/lib/apparmor is writeable to build or> update the cache (which also means no more write attemps on boot until you install a new kernel) - or -
- disable the "write-cache" option in /etc/apparmor/parser.conf - but let me warn you that this slows down profile loading 5 to 10 times, so this is nothing I want to do for the "normal" distribution. (If there is a build condition to match only Kubic, I'm willing to accept that in the AppArmor package as a hotfix. Technically we just have to disable a patch ;-)
As I wrote in one of the bug reports: since apparmor should load the profiles very early in the boot process, it should do the very early load without "write-cache" option and create the cache later in the running system. This avoids that the profiles are loaded to late and there are unproteced services running, and the performance problem should be the same.
Such a split makes sense if it helps to load profiles earlier - but if it doesn't help with this, I'd prefer to avoid the additional complexity. As you probably noticed in my reply to Aleksa, upstream provided a patch that makes cache write failures a warning instead of an error. This is probably not the final solution, but fixes the most urgent problem. For building the profile cache, run rcapparmor reload while /var/lib/apparmor is writeable.
At least I don't see why creating the cache and loading the rules is faster than loading the rules without creating the cache. If this is really the case, we should move the cache to /run/ ....
;-)) The slowdown is obviously the comparison between "having a valid cache" and "having no cache" - things are fast if you have a valid cache and apparmor_parser doesn't need to re-compile the profiles. If you don't have a valid cache, the difference between "loading the profiles" and "loading the profiles and writing the cache" is very small. Compiling the profiles needs time/CPU, writing the cache file to disk is quite "cheap" in comparison. Regards, Christian Boltz -- Ein Computer tut ja das, was man ihm "sagt", und nicht das, was man will. Ergo muß man wissen, wie man ihm sagt, was man will. [Stefan G. Weichinger in postfixbuch-users] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org