Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0(EOL)
Description
After MDEV-8497 had been fixed and the bugfix backported to 10.0, upgrade from MySQL 5.6 to 10.0 on Sid, Vivid, Wily is able to proceed further: the packages are installed all right, but the server does not start after upgrade.
If /etc/init.d/mysql start is run manually, it exits with zero code immediately without any messages, MariaDB is not started. Nothing in the logs.
As far as I could tell, the following happens.
- /etc/init.d/mysql at the very beginning calls /lib/lsb/init-functions
- /lib/lsb/init-functions triggers some hooks, one of which is /lib/lsb/init-functions.d/40-systemd
- /lib/lsb/init-functions.d/40-systemd checks the status for service mysql.service, and if it finds LoadState=masked, it exits, silently and without errors.
Apparently, the status is exactly that after MySQL 5.6 is uninstalled.
I don't really know what can be done about it. If we don't support crossgrade from MySQL 5.6 to 10.0, so be it – it's not so very important since we already have 10.1 and it works; but then we should make the decision and disable the test in buildbot.
Attachments
Issue Links
Activity
I can imagine we should backport these lines from 10.1:
# dh_systemd_start doesn't emit anything since we still ship /etc/init.d/mysql.
|
# Thus MariaDB server is started via init.d script, which in turn redirects to
|
# systemctl. If we upgrade from MySQL mysql.service may be masked, which also
|
# means init.d script is disabled. Unmask mysql service explicitely.
|
deb-systemd-helper unmask mysql.service >/dev/null || true
|
I am sure it is not a regression in any of the packaging changes I did. It was just not visible until I fixed the packaging part where the upgrade failed earlier. Please don't assign it to me.
This issue stems from something systemd does. Somebody with systemd expertise should try to solve it. The idea by svoj above looks potential, but I don't know more.
Upgrading from 5.6 to 10.0 is probably quite common, as Ubuntu ships 5.6 and we would like people to migrate from 5.6 to 10.0 or 10.1, so I vote for supporting those upgrade paths.
I came across the same issue when testing mysql-server-5.6 -> mariadb-server upgrades in Debian Sid and used the fix above to solve it in http://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=83103df287e3818daa38ca6aecf4cdf7b0164514
I will now do the same for upstream 10.0 because it will enable users to upgrade to 10.0 and is extremely unlikely to break anything old.
ATTN svoj, danblack – maybe you have some thoughts on this as well.