Comment 7 for bug 1830502

So I ran your snippet to determine which profiles weren't loaded and the only one which wasn't loaded was:

```
$ sudo cat /sys/kernel/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 '
Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
      1 snap-update-ns.layouts-test
```

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:

```
$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-update-ns.layouts-test
$ echo $?
0
```

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.