Public bug reported:
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
** Affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Affects: ntp (Ubuntu)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- Ordering of try-restart and debhelper on upgrade can cause issues
+ Ordering of start and apparmor reload upgrade can cause issues
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp 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 : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
