2

My idea was to tailor the configuration of my Mysql server by making use of the configuration directory it has and includes (via the !includedir /etc/mysql/conf.d/ directive at the end of /etc/mysql/my.cnf):

/etc/mysql/conf.d

So I created a configuration file called /etc/mysql/conf.d/innodb.cnf.

Now when I display the version via $ mysql --version I see the following error:

error: Found option without preceding group in config file: /etc/mysql/conf.d/innodb.cnf at line: 3

Which is true, that file does not have such a group in the first line. I commented it intentionally out, here the first three lines:

$ head -n 3 /etc/mysql/conf.d/innodb.cnf
# [mysqld]
# my settings
innodb_read_io_threads=4

If I would not comment the group, then using service mysql start on the command-line would put mysql in an endless start-up loop, it retries as often to start the mysql daemon which must fail then and retries again until I comment out the group again.

So now I'm left in a paradox situation. I could

  • either: have the file as is (the group commented out) and see the error

  • or: don't get the error but can't start mysql

Now I'm looking for options on how to deal with this situation.

I'm using Ubuntu 14.04 with the Kubuntu desktop and Mysql 5.5.

2 Answers 2

2

In my own case I am using Ubuntu 16.04 Which had !include with external files like so

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
innodb_buffer_pool_size = 20M

I just included [mysqld] before new line I added for my Wordpress new installation

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
[mysqld]
innodb_buffer_pool_size = 20M
0

The problem is that the configuration file contained a directive that prevented mysql from starting. As long as it was in error (without the group), it was not loaded so that the error didn't come to life and the server could start w/o error.

I troubleshooted this by starting and then stopping the mysql service with the group properly written on top of the file and then peeking into the error log to spot the issue:

$ sudo tail -f /var/log/mysql/error.log

I had an error like

2016-07-11 11:59:22 17164 [ERROR] /usr/sbin/mysqld: unknown variable 'table_cache=2048'
2016-07-11 11:59:22 17164 [ERROR] Aborting

Which is an outdated setting. Once renaming it, everything works like a charm again.

Typical mistake of not see the wood for the trees.

References:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .