Comment 7 for bug 1605687

When this happened to us during a mysql-server upgrade, the root
cause is that we had mysql (the server) disabled, ie 'systemctl disable
mysql'. When you do this, 'invoke-rc.d mysql start' winds up doing nothing
and not starting the server, which causes mysql_upgrade to fail because
it requires a running server.

Explicitly starting mysql before you do the upgrade doesn't help,
because the mysql-server-5.7 postinst script starts out by shutting it
down. What does work around the issue is re-enabling mysql beforehand:
'systemctl enable mysql', do the upgrade, then 'systemctl disable mysql;
systemctl stop mysql'.

(Invoke-rc.d does not directly ask systemd for the status of mysql.
Instead it looks at /etc/rc5.d/ S* and K* symlinks, which systemctl
manipulates for systemd services that also have an /etc/init.d
script, which mysql does. Finding this takes tracing through a lot
of layers.)

A correct bugfix for our issue would be for the mysql-server postinst
script to unconditionally start mysql using eg 'service mysql start',
instead of relying on invoke-rc.d. The ideal sequence would be to
explicitly start mysql, run mysql_upgrade, shut mysql down, and then run
'invoke-rc.d mysql start' to restart it only if it's been enabled.