which is a local snap I was developing quite some time ago. I will attach the associated apparmor profile that was generated, but curiously, when I try to load that profile manually with apparmor_parser it succeeds:
with the following output in the system journal indicating that the load was successful:
```
May 29 11:23:22 audit[21275]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap-update-ns.layouts-test" pid=21275 comm="apparmor_parser"
May 29 11:23:22 kernel: audit: type=1400 audit(1559147002.259:420): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap-update-ns.layouts-test" pid=21275 comm="apparmor_parser"
May 29 11:23:22 sudo[21273]: pam_unix(sudo:session): session closed for user root
```
and no kernel messages regarding apparmor_parser being killed from the OOM killer.
After doing this, then there is not a diff between the expected loaded profiles and the actual loaded profiles using your snippet, but if I try again to start apparmor.service it still gets killed by the OOM killer with similar output as above.
So I ran your snippet to determine which profiles weren't loaded and the only one which wasn't loaded was:
``` security/ apparmor/ profiles | awk '{ print $1 }' > /tmp/foo ; sudo apparmor_parser -N /etc/apparmor.d/ /var/lib/ snapd/apparmor/ profiles/ >> /tmp/foo ; sort /tmp/foo | uniq -c | grep -e ' 1 ' d/disable: usr.bin.firefox d/disable: usr.sbin.rsyslogd ns.layouts- test
$ sudo cat /sys/kernel/
Skipping profile in /etc/apparmor.
Skipping profile in /etc/apparmor.
1 snap-update-
```
which is a local snap I was developing quite some time ago. I will attach the associated apparmor profile that was generated, but curiously, when I try to load that profile manually with apparmor_parser it succeeds:
``` snapd/apparmor/ profiles/ snap-update- ns.layouts- test
$ sudo apparmor_parser -r /var/lib/
$ echo $?
0
```
with the following output in the system journal indicating that the load was successful:
``` "profile_ load" profile= "unconfined" name="snap- update- ns.layouts- test" pid=21275 comm="apparmor_ parser" 2.259:420) : apparmor="STATUS" operation= "profile_ load" profile= "unconfined" name="snap- update- ns.layouts- test" pid=21275 comm="apparmor_ parser" sudo:session) : session closed for user root
May 29 11:23:22 audit[21275]: AVC apparmor="STATUS" operation=
May 29 11:23:22 kernel: audit: type=1400 audit(155914700
May 29 11:23:22 sudo[21273]: pam_unix(
```
and no kernel messages regarding apparmor_parser being killed from the OOM killer.
After doing this, then there is not a diff between the expected loaded profiles and the actual loaded profiles using your snippet, but if I try again to start apparmor.service it still gets killed by the OOM killer with similar output as above.