Indeed, steps 3 and 4 should ideally happen in the reverse order. I don't know if debhelper provides facilities to order autoscript snippets though.
In passing, once https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1385414 is done I think we should use systemd's AppArmorProfile= directive and it will do the right thing, i.e. compile the updated policy just before starting the upgraded daemon. But we're not there yet. -- 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/1738958 Title: Ordering of start and apparmor reload upgrade can cause issues Status in apparmor package in Ubuntu: New Status in ntp package in Ubuntu: New Bug description: We found this in ntp, but I think it is a general issue in the ordering. The tail of NTPs postinst looks like that: if [ "$1" = "triggered" ]; then # The default configuration uses a leapfile from tzdata # restart ntp on changes invoke-rc.d ntp try-restart || true fi #DEBHELPER# Therefore on an upgrade it is restarted one more time restarted "the old way". E.g. if there are changes delivered by #DEBHELPER# generated maintainer script snippets e.g. apparmor profiles, then this try-restart will be without them. Also this might be a bad "combo" with "--no-restart-after-upgrade" that is set in debian/rules. --no-restart-after-upgrade Undo a previous --restart-after-upgrade (or the default of compat 10). If no other options are given, this will cause the service to be stopped in the prerm script and started again in the postinst script. I think no-restart-after-upgrade + try-restart means try-restart will do nothing as "try-restart" on the (now stopped service) does nothing. So what happens seems to be this: 1. prerm stops ntp 2. postinst try-restart does nothing as it is stopped (not important to this cases but good to know) 3. postinst dh_installinit will "invoke-rc.d ntp start" with the old profile 4. postinst dh_apparmor reloads apparmor profiles So if you have issues triggered by the start on #3 before the new profile is in place due to #4 this causes issues. I think #3 (as well as similar systemd things) and #4 should be reordered so that the new profile is loaded BEFORE To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1738958/+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
