Upgrade to 5.5.36-rel34.1-642.squeeze silently changes my.cnf, breaks startup if change reverted

Bug #1293867 reported by mig5 on 2014-03-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Fix Released
Alexey Bychko
Fix Released
Alexey Bychko
Fix Released
Alexey Bychko

Bug Description

Originally reported at http://www.mysqlperformanceblog.com/2014/03/17/percona-server-5-5-36-34-1-now-available/#comment-5462437

The upgrade to (at least) 5.5.36-rel34.1-642.squeeze invokes a preinst script in your deb package of percona-server-server-5.5 which runs this code silently:

# TODO fixing my.cnf, prepending params with invalid paths with #
if [ -f /etc/mysql/my.cnf ]; then
sed -i -e ‘/^[^#].*share\/mysql/s/^/#/’ /etc/mysql/my.cnf

We were not prompted in typical Debian fashion about the change to this file during the upgrade.

The code above, commented out this value in our /etc/mysql/my.cnf:

language = /usr/share/mysql/english

The upgrade appears to rename /usr/share/mysql to /usr/share/percona-server and so I understand the purpose of the change.

Because this is silent, and that the change actually *fixes* the my.cnf, there is no indication of what has happened to the end user.

However, for anyone who might have a Puppet-managed my.cnf, as we do, this is disastrous. The next Puppet execution replaced the my.cnf with the original version and scheduled a refresh of the mysqld service. MySQL failed to start back up once the `language` value was back in the my.cnf. Comparing the change in Puppet's clientbucket was how I discovered that your package modified the my.cnf.

The issue was solved either by changing the value in the config, or (a quick fix for us rather than work out new logic in our my.cnf template for our mix of database servers running different versions), symlink /usr/share/mysql to the new directory /usr/share/percona-server and restart MySQL.

As a couple of recommendations:

1) Don't make this change silent. Why is the TODO there? Is there are better, more Debian way to diff the change and accept/be made aware of the modification. In 2014, direct silent modifications of a config file are probably risky, I can't be the only one to be templating my my.cnf in Puppet.

2) Mention this quite significant /usr/share/mysql rename in the release notes. Why was it not mentioned in http://www.mysqlperformanceblog.com/2014/03/17/percona-server-5-5-36-34-1-now-available ?

3) Perhaps maintain /usr/share/mysql as a symlink if you are going to move it, to avoid such surprises?

System was Debian 6.0.9, 64-bit, upgrading percona-server-server-5.5 and related packages from 5.5.35-rel33.0-611.squeeze to 5.5.36-rel34.1-642.squeeze

Let me know if I can provide any more information.

Tags: pkg Edit Tag help

Related branches

Timur Bakeyev (timur.bakeyev) wrote :

See also #1294211

Changed in percona-server:
assignee: nobody → Alexey Bychko (abychko)
tags: added: pkg
mig5 (mig5) wrote :

So I see a fix was released, can we get some more communication from the developers on how it was fixed? Specifically I notice an upgrade to the new release no longer moves /usr/share/mysql to /usr/share/percona-server. It stays as /usr/share/mysql. Is this expected? How come the change in the first place?

Thanks for the new release!

mig5 (mig5) wrote :

Nevermind I see the /usr/share/percona-server change was simply reverted in http://bazaar.launchpad.net/~percona-core/percona-server/release-5.5.36-34.1/revision/643 - thanks again

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-3107

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers