Hide Forgot
Description of problem: Config file order of mariadb is not according to documentation: https://mariadb.com/kb/en/mysqld-startup-options/ Version-Release number of selected component (if applicable): mariadb-server-5.5.33a-3.el7.x86_64 # grep log-error /etc/my.cnf log-error=/var/log/mariadb/mariadb-etc-my-cnf.log # grep log-error /etc/mysql/my.cnf log-error=/var/log/mariadb/mariadb-etc-mysql-my-cnf.log # /usr/libexec/mysqld --help --verbose 2>/dev/null | grep --after=1 '^Default options' | tail -n 1 /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf # systemctl restart mariadb # systemctl status mariadb ... └─11182 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb-etc-my-cnf.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysq... ... Option: --log-error=/var/log/mariadb/mariadb-etc-my-cnf.log This means, that firstly is loaded /etc/mysql/my.cnf and then is rewritten by /etc/my.cnf. If you delete /etc/my.cnf, /etc/mysql/my.cnf is used. This behaviour is against mariadb's documentation: https://mariadb.com/kb/en/mysqld-startup-options/ This could be bug in documentation or in our package. Please let me know.
I believe this is the same bug that has already been reported and patch provided to upstream. However, since we don't want to differ from upstream in this case, we prefer to wait what their fix will be. https://mariadb.atlassian.net/browse/MDEV-4927
We have some update from upstream, this is their view on it [1]: """ I tried to fix it, but after some discussion we agreed that changing the order of configuration files is too dangerous — it might introduce subtle bugs after an upgrade for anyone who relies on the current behavior. Instead, I've edited the manual to specify more clearly what files are read and from where. Besides, the manual was already saying (even before my changes) that one should use "mysqld --help --verbose" to get the exact my.cnf search path on his system. """ Then I see the following in the [2] now: """ Default options are generally read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf my.cnf in the DEFAULT_SYSCONFDIR specified during the compilation my.cnf in the path, specified in the environment variable MYSQL_HOME (if any) the file specified in --defaults-extra-file (if any) user-home-dir/.my.cnf For an exact list for your system execute mysqld --help --verbose. The full file list will be near the beginning of the output. """ So what the test actually should do is either: 1) to look at "mysqld --help --verbose" output and compare it with how it actually works or 2) or just do what it does now (check what order actually is) and compare the result with expected value, which should correspond with the order in RHEL-6 Just FTR, in RHEL-6: $ /usr/libexec/mysqld --help --verbose 2>/dev/null|grep -e etc/my.cnf -e Ver /usr/libexec/mysqld Ver 5.1.71 for redhat-linux-gnu on x86_64 (Source distribution) /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf In RHEL-7: $ /usr/libexec/mysqld --help --verbose 2>/dev/null|grep -e etc/my.cnf -e Ver /usr/libexec/mysqld Ver 5.5.33a-MariaDB for Linux on x86_64 (MariaDB Server) /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf So I'd say we stay compatible with RHEL-6, which is what we want, right? So can we close this as not a bug then? [1] https://mariadb.atlassian.net/browse/MDEV-4927 [2] https://mariadb.com/kb/en/mysqld-startup-options/
Thank you for investigating. TestCase adjusted to test the same config order as rhel6 has.