The snippet I initially found is for a "trigger" which is independent
(other things need to reatsrt ntp. Sorry for the noise.
I found that the new postinst leaves ntp around but reloads the profile (ok
with the process running)
Eventually (after the reload) there is a invoke-rc.d ntp start ||
installinit_error from dh_installinit.
prerm stops the service.
That would start it with new new rule already loaded.
So we have:
1. trigger - restarts unrelated to apparmor
2. prerm stops, postinst starts (late after apparmor)
3. if not restarted then the profile reload will affect the running program
Therefore I think this is resolved, by
a) better understanding
b) maybe some newer dh_ tools that now generate better rules
Setting my bug to invalid.
** Changed in: ntp (Ubuntu)
Status: New => Invalid
** Changed in: apparmor (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1738958
Title:
Ordering of start and apparmor reload upgrade can cause issues
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1738958/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs