Comment 2 for bug 1592669

I've discussed this with Lars. The problem is that we need to run mysql_upgrade in the postinst as it is expected that /var/lib/mysql is upgraded when the package is upgraded. However, mysql_upgrade requires the daemon to be running, and the daemon must be restarted after it is finished running. This is tricky to do in a postinst with respect to policy-rc.d.

I think this is the more general case of this specific bug.

We moved mysql_upgrade to the postinst from the upstart service script in 5.7 when we did the systemd work. Otherwise we struggle to restart mysqld after mysql_upgrade has run.

I think the solution is to consider the daemon start/stop for the purposes of mysql_upgrade outside the scope of policy-rc.d, while ensuring that it doesn't appear to be running during that time to anything else. For example, run it with TCP disabled and on a Unix socket in a temporary location only, just for the purpose of mysql_upgrade to talk to it. Then it would effectively be the same as running a version of mysql_upgrade that does not require a running daemon. This special start/stop of mysqld could use start-stop-daemon with a custom configuration to run with TCP disabled and put the pidfile and Unix socket in a temporary location. I'm told that mysqld will fail to start if it cannot get an exclusive lock on specific files inside /var/lib/mysql, so we should be safe from concurrent access issues with a daemon we do not know about.

However, if policy-rc.d means that a daemon remains running when the postinst is running, we will just not be able to run mysql_upgrade. Perhaps we should warn in this case.