mysql does not import apparmor profile correctly
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
mysql-5.6 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The dep8 failure here was due to the apparmor profile not being updated, which I will fix. But I'm concerned that there is a separate issue here, which is that now I understand the other bug, I expect mysqld to have failed on the first invocation after package install, not the second after the restart. This suggests to me that there's some ordering issue or race that stops the profile from taking effect on the first run.
Complicating factors may be the ordering of dh_installinit and dh_apparmor in debian/rules (I'll amend this to be more sensible, but it should be checked), and systemd vs. upstart (the upstart pre-script does load the apparmor profile in a pre-script, but we are switching to systemd this cycle and the systemd unit does not mention apparmor; I think it should).
So I'd like to leave this bug open so the issue doesn't get lost and does get looked at. We need to make sure that the apparmor profile is loaded correctly and is always active, including the first mysqld invocation after package installation, in the version we release in Vivid.
mysql-5.6 should enter main this cycle.
I think I see this as well, simply doing an 'apt-get install mysql-server-5.6' on vivid leaves things in the following state after the installation completes:
$ sudo aa-status sbin/dnsmasq (665) sbin/mysqld (9186)
[SNIP]
2 processes are unconfined but have a profile defined.
/usr/
/usr/
which suggests that something is going wrong in the rats nest of mysql.postinst/ invoke- rc.d. Is it possible that somehow the sysv init script /etc/init.d/mysql is getting invoked instead of the upstart job? (... as that script does not load the mysql apparmor profile before starting mysql, unlike the upstart job).