Comment 8 for bug 1773515

May 26 10:36:35 ThisOne apparmor[2850]: AppArmor parser error for /etc/apparmor.d/usr.lib.snapd.snap-confine.real in /etc/apparmor.d/usr.lib.snapd.snap-confine.real at line 11: Could not open '/var/lib/snapd/apparmor/snap-confine'

The above indicates that /etc/apparmor.d/usr.lib.snapd.snap-confine.real is still on the system but /var/lib/snapd/apparmor/snap-confine is not. Keep in mind that /etc/apparmor.d/usr.lib.snapd.snap-confine.real is a Debian conffile and therefore not removed unless --purge is specified. Since the reporter only did a remove without a purge, /var/lib/snapd/apparmor/snap-confine was removed and /etc/apparmor.d/usr.lib.snapd.snap-confine.real was not. IME, this is a bug in the snapd packaging-- /etc/apparmor.d/usr.lib.snapd.snap-confine.real should be changed from a conffile to a config file (eg, copied into place from /usr/share or somewhere instead of shipped in /etc) and /etc/apparmor.d/*snap-confine* should all be removed on remove (with or without --purge). With how snapd works with re-exec, it is almost unreasonable to expect a local admin to make changes to /etc/apparmor.d/usr.lib.snapd.snap-confine.real and expect them to last (and thus justifying changing them to config files that can just be removed on package removal).

@Dale, importantly, please keep in mind that the log message and systemd status is non-fatal: all profiles that could be loaded were loaded and you can verify this with 'sudo aa-status'. You should be able to work around this by performing 'sudo dpkg --purge snapd' which should remove the problematic profile. If it doesn't, please report back since that would indicate a bug in the packaging (and once reported, simply removed the file yourself with 'sudo rm -f /etc/apparmor.d/usr.lib.snapd.snap-confine.real').