View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007802||CentOS-7||mariadb||public||2014-10-29 18:22||2017-07-06 09:07|
|Target Version||Fixed in Version|
|Summary||0007802: mariadb service ignores /etc/my.cnf|
|Description||I have tried to change mariadb collation to utf8 by editing /etc/my.cnf and setting collation-server and character-set-server options, but those are ignored when I start the service.|
If started via command line like 'mysqld_safe --defaults-file=/etc/my.cnf', then all is ok.
Also, '/usr/libexec/mysqld --help --verbose' shows desired configuration.
It seems that somehow, mysqld_safe without parameters simply ignores any configuration.
|Steps To Reproduce||Edited /etc/my.cnf:|
# Disabling symbolic-links is recommended to prevent assorted security risks
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
collation-server = utf8_general_ci
character-set-server = utf8
$ service mariadb start
$ mysqladmin variables | grep -E 'character|collation' | tr -s ' '
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
|Tags||No tags attached.|
I have identified the problem.
Basically /etc/my.cnf must be owned by mysql user.
Nevertheless, this shouldn't be silently ignored.
Same problem here. Files in /etc/my.cnf.d have correct permissions, but different SElinux context from /etc/my.cnf (etc_t vs. mysqld_etc_t). Still they would be read, if not for the include statement being in /etc/my.cnf which can't be accessed.
Minimal force solution/workaround:
chown :mysql /etc/my.cnf
chmod g+r /etc/my.cnf
Just ran into this issue as well. Permissions and/or owner of the file /etc/my.cnf need to be fixed.
I would suggest to fix the permissions of the file to be readable by user "mysql". Is this the case the provided include paths would be read by mariadb – the default files in "/etc/my.cnf.d/" are world readable.
|i am having the same problem. changing anything in /etc/my.cnf has no effect. i even changed the permissions on the configuration files and it makes no difference. i was running in a multi configuration and now the daemon only starts in default single instance configuration. selinux is disabled|
The correct permissions are as follows:
-rw-r--r--. 1 root root 901 Jun 14 12:29 /etc/my.cnf
and selinux context
-rw-r--r--. root root system_u:object_r:mysqld_etc_t:s0 /etc/my.cnf
The file should definitely NOT be owned by mysql as that would give the daemon the ability to change it, thus if someone can find a vulnerability in mariadb they could then proceed to alter the config file. See https://access.redhat.com/security/cve/cve-2016-6662 for a reason why.
i have tried everything and mariadb does NOT read any updates made to /etc/my.cnf.
[root@ns1 ~]# /usr/libexec/mysqld --verbose --help | grep -A 1 "Default options"
170614 13:16:23 [Note] Plugin 'FEEDBACK' is disabled.
Default options are read from the following files in the given order:
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf
there is no file /etc/mysql/my.cnf. the user mysql home directory is /var/lib/mysql and there is no file my.cnf in there
i run SHOW VARIABLES; in mysql CLI and the variables show no change.
i restart mariadb between changes using
systemctl stop mariadb
systemctl start mariadb
# rpm -qa mariadb\*
FYI system info
Yes exactly the same
[root@ns1 etc]# rpm -qa mariadb\*
Show the output from
ls -la /etc/mysql/my.cnf /etc/my.cnf
ls -laZ /etc/mysql/my.cnf /etc/my.cnf
[root@ns1 etc]# ls -la /etc/mysql/my.cnf /etc/my.cnf
ls: cannot access /etc/mysql/my.cnf: No such file or directory
-rw-r--r-- 1 root root 943 Jun 14 11:29 /etc/my.cnf
[root@ns1 etc]# ls -laZ /etc/mysql/my.cnf /etc/my.cnf
ls: cannot access /etc/mysql/my.cnf: No such file or directory
-rw-r--r-- root root ? /etc/my.cnf
|Then sorry, no idea, I tested here and it works for me.|
this is the server.cnf file i was using. it worked perfectly before but now any changes i make are completely ignored. maybe you spot something that i am missing that may have changed during the last update?
it is supposed to be loaded from /etc/my.cnf. my.cnf only contains
server.cnf (943 bytes)
|will i need to take it to mariadb support? seems strange that it has been working perfectly and then after a recent restart it isn't working any more|
|Yes, it looks that way to me. I'm not aware that it respects what you've done in your server.cnf file - I run parallel instances of mysqld on a box and they have separate cnf files and both have a [mysqld] section. I have no idea if [mysqld1] is a supported way of working. For that you need a mysql/mariadb person.|
yes i was thinking i might have to change to that method. these are some of the references i have been looking at;
this one explains using mysql multi:
this is for multiple mysql instances:
maybe an update of mariadb has overwritten my configuration in /usr/lib/systemd/system/mariadb.service and caused the problem?
|Very possible. If you want to change the supplied unit files, do not edit them in place as they are not defined as config files so will be overwritten on package update. You need to copy them to /etc/systemd/system and modify them there.|
thanks. i am reading this now as mentioned in the top of the unit file.
and also this for configuring systemd with multi
i will let you know if it doesn't solve the problem
I think this is due to the default path of my.cnf for MariaDB having changed, see https://mariadb.com/kb/en/mariadb/configuring-mariadb-with-mycnf/
I've tried working around this by adding a custom unit file (described in this thread) to set the MYSQLD_OPTS variable, which runs into this: https://bugs.mysql.com/bug.php?id=30994
What I've done is replace the ExecStart entry in my custom unit file to move MYSQLD_OPTS to the first argument:
ExecStart=/usr/libexec/mysqld $MYSQLD_OPTS --basedir=/usr $_WSREP_NEW_CLUSTER
|2014-10-29 18:22||rgafonso||New Issue|
|2014-10-30 15:52||rgafonso||Note Added: 0021471|
|2014-11-07 13:46||HFalch||Note Added: 0021589|
|2015-09-07 12:firstname.lastname@example.org||Note Added: 0024289|
|2017-06-14 07:12||chongma||Note Added: 0029469|
|2017-06-14 11:33||TrevorH||Note Added: 0029470|
|2017-06-14 12:19||chongma||Note Added: 0029471|
|2017-06-14 12:20||TrevorH||Note Added: 0029472|
|2017-06-14 12:23||chongma||Note Added: 0029473|
|2017-06-14 12:24||chongma||Note Added: 0029474|
|2017-06-14 12:24||TrevorH||Note Added: 0029475|
|2017-06-14 12:33||chongma||Note Added: 0029476|
|2017-06-14 12:36||TrevorH||Note Added: 0029477|
|2017-06-14 12:49||chongma||File Added: server.cnf|
|2017-06-14 12:49||chongma||Note Added: 0029478|
|2017-06-14 18:32||chongma||Note Added: 0029483|
|2017-06-14 21:27||TrevorH||Note Added: 0029486|
|2017-06-15 11:28||chongma||Note Added: 0029491|
|2017-06-15 11:30||TrevorH||Note Added: 0029492|
|2017-06-15 11:45||chongma||Note Added: 0029493|
|2017-07-06 09:07||kewne||Note Added: 0029616|