The biggest problem is that it isn't easily disabled because it is hardcoded in
the script instead of being in /etc/apparmor/parser.conf.
Instead of hardcoding, it would had been better to just update that conffile
and let dpkg update it if the user didn't change it (which is highly likely) or
on new installs.
In /lib/apparmor/functions we have this:
# LP: #1383858 - expr tree simplification is too slow for some
# policy on 32bit ARM, so disable it for now
cache_extra_args=
if [ -d "$PROFILES_CACHE_VAR" ] && [ "$pdir" = "$PROFILES_VAR" ]; then
cache_extra_args="-O no-expr-simplify"
fi
So now for machines with 2Gib of RAM and Snaps, Ubuntu 18.04 has become
unusable.
I know the minimum requirements are 4Gib but it did actually work fine with
2Gib before so it is a bit sad to loose that capability.
My suggestion is to just revert that change and do it in parser.conf
instead, so at least we have the option to easily modify it to retain
some 2Gib support.
Thanks a lot for considering this!!!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1830502
Title:
apparmor uses excessive memory leading to oom kill
Status in apparmor package in Ubuntu:
Confirmed
Bug description:
When attempting to load the profile from comment #7, apparmor uses
excessive amounts of memory leading to being killed by the OOM killer
and thus the apparmor.service failing.
Original bug description:
On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
my system was unable to finish booting and I had to go into recovery
mode and remove a number of files before the system would boot. After
doing so I discovered that now the apparmor.service systemd unit
always fails to start. I see this in dmesg:
[ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796
or sacrifice child
[ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB,
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
[ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Whenever apparmor.service is attempted to be started by systemd, i.e.
either on boot, or later with `systemctl start apparmor`.
The log from journalctl doesn't show any actual issues with any
profiles just this:
-- Reboot --
May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:01:40 apparmor[1521]: ...fail!
May 25 17:01:40 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:05:25 apparmor[4747]: ...fail!
May 25 17:05:25 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.
I can see that apparmor profiles are active after doing this (using
aa-status), but it's still troubling that apparmor runs into an issue
without actually saying what the error is.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
