[MDEV-9354] [PATCH] Systemd start after upgrade from MySQL 5.6 to MariaDB 10.0 does not work on Sid, Vivid, Wily Created: 2016-01-04  Updated: 2016-02-11  Resolved: 2016-02-11

Status: Closed
Project: MariaDB Server
Component/s: Packaging, Platform Debian, Tests
Affects Version/s: 10.0
Fix Version/s: 10.0.24

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergey Vojtovich
Resolution: Fixed Votes: 0
Labels: buildbot, systemd, upgrade

Issue Links:
Blocks
blocks MDEV-7069 Fix buildbot failures in main server ... Stalled
Relates
relates to MDEV-8497 Buildbot upgrade tests fail on Vivid,... Closed

 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.



 Comments   
Comment by Elena Stepanova [ 2016-01-04 ]

ATTN svoj, danblack – maybe you have some thoughts on this as well.

Comment by Sergey Vojtovich [ 2016-01-04 ]

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

Comment by Otto Kekäläinen [ 2016-01-05 ]

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.

Comment by Otto Kekäläinen [ 2016-01-11 ]

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.

Comment by Otto Kekäläinen [ 2016-01-11 ]

https://github.com/MariaDB/server/pull/145

Generated at Thu Feb 08 07:34:02 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.