A related issue: "/etc/init.d/apparmor stop" should invoke aa- teardown(8). Depending on the semantics of the apparmor "service," this could also be "/etc/init.d/apparmor unload" or the like. I was surprised to find that "apparmor stop" was not actually unloading the profiles, as I had assumed.
>From the perspective of a sysadmin, I rely on the init scripts to manage daemons/services without having to know the specific technical details of how to interact with each one. A major reason why those scripts exist is to translate a simple start/stop logic into whatever that reasonably means for a particular daemon or service. -- 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/1878333 Title: AppArmor cache entries not removed when profile is deleted Status in apparmor package in Ubuntu: Confirmed Bug description: This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal. If I delete a profile from /etc/apparmor.d/, reboot the system, and then look in /var/cache/apparmor/XXXXXXXX.0/, I still see a file for the compiled form of the profile. The same occurs if the profile is "deleted" by other means, such as symlinking it from /etc/apparmor.d/disable/. This behavior caused me some consternation as I was developing an alternate profile for a program that already had one, and I continued to see old behavior even though I had removed the old profile. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1878333/+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
