MySQL Bugs: #100619: Wrong symlink /etc/alternatives/my.cnf -> /etc/mysql/mariadb.cnf

Bug #100619	Wrong symlink /etc/alternatives/my.cnf -> /etc/mysql/mariadb.cnf
Submitted:	24 Aug 2020 9:07	Modified:	3 Jun 2021 10:25
Reporter:	Vaclav Zindulka	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S3 (Non-critical)
Version:	5.7, 8.0	OS:	Debian (Buster)
Assigned to:		CPU Architecture:	x86
Tags:	configuration

Description:
I've installed MySQL from Debian repository on Debian Buster. I wanted to configure replication but I was unable to start slave because there wan no server-id set. I've placed configuration file into /etc/mysql/mysql.conf.d/. After some researching I've found the problem. /etc/mysql/my.cnf id symlink to /etc/alternatives/my.cnf which is symlink to /etc/mysql/mariadb.cnf. So my config file was not processed at all.

/etc/alternatives/my.cnf didn't exist before installation so it is most probably created during installation. In Debian Stretch it pointed correctly to /etc/mysql/mysql.cnf. Maybe there was some change even for Stretch. I can't tell. I didn't install MySQL on Strech from repository for some time.

How to repeat:
Install MySQL from Debian repository.
Try to alter configuration in /etc/mysql/mysql.cnf or /etc/mysql/mysql.conf.d.
Check the result after restart - it won't be changed.
It affects both 5.7 and 8.0 versions installed from repository.

Suggested fix:
Fix symlink in /etc/alternatives/my.cnf to point at /etc/mysql/mysql.cnf.

Hello Vaclav Zindulka,

Thank you for the report and feedback.

regards,
Umesh

Posted by developer:

[24 Aug 2020 4:09] Lars Tangvald

Hi,

Do you have any MariaDB packages installed or that have not been cleaned up
properly? Since MariaDB still uses /etc/mysql/my.cnf to store its config, the
alternatives system is used to switch from one to the other. But if MariaDB
is still installed and set to a higher priority, MySQL may not be able to
switch it to use its own configuration.

Hello,

No, I uninstalled MariaDB first. I checked presence of /etc/alternatives/my.cnf during diagnostics of the problem and it wasn't present. Then I installed MySQL from the Debian repository and that symlink was created with wrong path. I had script for this procedure which worked without problems earlier. There must have been some change in MySQL repository or may be it is related to Debian Buster somehow. Yet I have no idea how to check that. Not to mention I don't expect any kind of support from Debian guys for external repo like yours.

Internal base bug is closed with below change log.

Fixed in 8.0.26.

For Debian packages, the update-alternatives priority of the MySQL
configuration file was increased to ensure it replaces an existing
file from a previously installed distribution.