Description of problem: MariaDB systemd unit files contain the following ExecStartPre and ExecStartPost commands: ExecStartPre=/usr/libexec/mysql-check-socket ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n [...] ExecStartPost=/usr/libexec/mysql-check-upgrade While I am unsure about the mysql-prepare-db-dir, mysql-check-socket and mysql-check-upgrade do not evaluate the unit name at all, and hence do not read the corresponding suffixed configuration blocks in my.cnf. Thus these scripts try to connect to the wrong mariadb instance. When using a configuration like this: ``` [mariadb] # defaults here [mariadb.foo] port=3307 datadir=/var/lib/mysql-foo/ socket=/var/lib/mysql-foo/mysql.sock pid-file=/var/run/mariadb/mariadb-foo.pid log-error=/var/log/mariadb/mariadb-foo.log [client-server.foo] port=3307 socket=/var/lib/mysql-foo/mysql.sock ``` and then start ``` # systemctl start mariadb # systemctl start mariadb@foo ```` mysql-check-socket in the second unit does not pick up this configuration, but instead checks the default socket /var/lib/mysql/mysql.sock for availability. The same for mysql-check-upgrade, which checks and upgrades the wrong mariadb instance. This leads to different error symptoms when trying to instantiate multiple mariadb servers. In my case, I am running mariadb.service with default port, socket, datadir etc, and a second one mariadb configured similar to above. Starting the custom service mariadb@foo when mariadb is already running fails, because the socket /var/lib/mysql/mysql.sock is already in use. I did not try the other way around, but I guess then mysql-check-upgrade fails because it tries to connect to the incorrect socket as well. I am currently working around this by commenting out the ExecStartPre and ExecStartPost commands. I figure mixing mariadb.service and mariadb@.service is unusual, but switching to two units using mariadb@.service would not fix the behaviour as well. Version-Release number of selected component (if applicable): mariadb-server-10.1.30-2.fc26.x86_64 How reproducible: With the configuration above: always. Steps to Reproduce: 1. edit /etc/my.cnf to contain the .foo blocks like above 2. systemctl start mariadb 3. systemctl start mariadb@foo Actual results: mariadb@foo fails to start with the following messages, because it checks the wrong socket: Jan 25 11:55:04 server mysql-check-socket[3353]: Socket file /var/lib/mysql/mysql.sock exists. Jan 25 11:55:05 server mysql-check-socket[3353]: Is another MySQL daemon already running with the same unix socket? Jan 25 11:55:05 server mysql-check-socket[3353]: Please, stop the process 3281 or remove /var/lib/mysql/mysql.sock manually to start the service. Expected results: mysql-check-socket checks the correct socket path. Additional info: Like I wrote above, mysql-check-upgrade also tries to upgrade the wrong database, and I am unsure about mysql-prepare-dir.
mariadb-10.1.32-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-56ba65b633
Hi Markus, sorry for a longer waiting time, but today a I finally pushed the fixed package to BODHI and I'd love to get you feedback to be sure, it fixes the whole issue. https://bodhi.fedoraproject.org/updates/FEDORA-2018-56ba65b633
mariadb-10.1.32-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-56ba65b633
Hi Michal, I installed the update today, and it looks good to me, seems to have fixed the bug. Feedback has been posted on BODHI. Thanks for fixing.
mariadb-10.1.32-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.