Comment 2 for bug 1421303

This bug manifested in upgrade issues for users upgrading from mysql-5.5 (over the last day for any users following Vivid).

An update is on its way. Some comments on what happened:

The postinst (mysql-server-5.6.postinst) runs mysqld directly for bootstrapping before the "service" is started. On first install, this was unconfined, since AppArmor profile loading happens afterwards. On upgrade, this was on the previously loaded profile, not any new one shipped with the upgrade. I've fixed this with a workaround and have filed bug 1435368 to track a proper fix.

Also debian/rules was calling dh_apparmor at a point after dh_installinit, causing the ordering in the postinst to cause the new AppArmor profile to be loaded *after* the mysqld service was started. I've filed bug 1435452 because I think the dh sequencer should handle the ordering, but I've also uploaded the ordering fix manually.

The two bugs both meant that on upgrade the previous AppArmor profile was used, rather than the new one that permits mysqld access to the new /etc/mysql/mysql.conf.d/ directory. Previously, the upstart job manually loaded the profile before job start anyway. Now with systemd, we rely on dh_installinit and dh_apparmor to do the right thing entirely. This didn't work, so caused things to fail on upgrade.

Users would have seen a 10 minute delay while systemd timed out on starting the mysqld service unit, followed by a failure for mysqld to start anyway. Loading AppArmor profiles correctly would have worked around this.