14 messages in com.mysql.lists.bugsConfiguring my.cnf (was: mysql 4.0.2 ...
FromSent OnAttachments
Martin MOKREJŠ19 Aug 2002 07:09 
Jani Tolonen19 Aug 2002 07:15 
Sinisa Milivojevic19 Aug 2002 07:26 
Martin MOKREJŠ19 Aug 2002 07:37 
Martin MOKREJŠ19 Aug 2002 07:39 
Sinisa Milivojevic19 Aug 2002 07:44 
Martin MOKREJŠ19 Aug 2002 07:56 
Michael Widenius20 Aug 2002 01:26 
Michael Widenius23 Aug 2002 00:32 
Martin MOKREJŠ23 Aug 2002 02:07 
Melvyn Sopacua23 Aug 2002 06:24 
Michael Widenius23 Aug 2002 12:15 
Michael Widenius25 Aug 2002 11:01 
Melvyn Sopacua27 Aug 2002 06:40 
Subject:Configuring my.cnf (was: mysql 4.0.2 linux-i386 crash)
From:Michael Widenius (mon@mysql.com)
Date:08/23/2002 12:15:33 PM
List:com.mysql.lists.bugs

Hi!

"Martin" == Martin MOKREJ <Martin> writes:

Martin> On Fri, 23 Aug 2002, Michael Widenius wrote: Martin> Hi,

No, it looks like something went wrong when we made the 4.0.2 distribution. I am just now building 4.0.3 and I will check that the sym file will get generated properly this time. Sorry for the confusion.

Martin> No problem. Do you have the unstripped binaries for 4.0.2? Can you
decode Martin> the stack trace?

Sorry, but we don't have that :(

My guess is that your original problem is that you added /usr/local/mysql/bin to PATH, which is wrong.

Martin> Well, this was one of the attempts, as it seemed mysqld did chdir() to Martin> some wrong directory, and wasn't able to locate my_print_defaults and Martin> other binaries. The PATH solved this part of the problem, but the
problem Martin> with share/mysql/ not being found remained. It turned out the soflink
from Martin> withing /usr/local/mysql to itself under Martin> mysql-4.0.2-alpha-pc-linux-gnu-i686 solved that.

Yes, this softlink is the recommended way to install a MySQL binary distribution as it makes it trivial to change MySQL version almost instantly.

<cut>

Martin> Hmm, yes, there's somewhere @HOSTNAME@ which I thought should be already Martin> expanded via some make command. But I only untar the distribution and Martin> that's almost all I do after upgrade.

I noticed the HOSTNAME issue and this is fixed in the 4.0.3 binary version that I am building just now...

Martin> I have sometimes problems configuring /etc/my.cnf. I'm getting errors
that Martin> some variable is not recognized. I'm not sure if it has to be critical Martin> error so that mysqld exits immediately, but that's your choice. For Martin> example, when it cannot create .pid file, it gives error 02 but
continues.

In most cases MySQL exits at once, which I think is the right thing as the option you may have misspelled could be critical for your operation.

When it comes to the pid file, MySQL works perfectly even without it and that's we decided to ignore the error in this case.

Martin> I'm very bad with understanding doc's I think, but while looking at Martin> http://www.mysql.com/doc/en/SHOW_VARIABLES.html, it only says: Martin> "have_innodb YES if mysqld supports InnoDB tables. DISABLED if Martin> --skip-innodb is used. " Beginner doesn't come to the conclusion he's Martin> supposed to use Martin> [mysqld] Martin> skip-innodb

We can't repeat all manual information at all places some construct is used :(

From the manual:

If you don't want to use InnoDB tables, add the skip-innodb option to the option file.

I have now added some more references to --skip-innodb

Martin> Actually, originally I tried have_innodb=0 (or set have_innodb=0 ?) with Martin> not much success either. I thought that all --cmd arguments to mysqld
can Martin> be specified in the [mysqld] section. skip-locking works for me under Martin> [mysqld]. But these details are not in the doc's, probably they seem to Martin> you clear enough. :(

Yes, all options can be specified in the [mysqld] section. The problem here is that 'have_innodb' is not an option but a status variable that gives you the state of innodb.

Martin> Just have a look at http://www.mysql.com/doc/en/Option_files.html.
Reading Martin> that tells me, that skip-innodb is an ARGUMENT, not an Marten> OPTION/VARIABLE.

That is correct. Note that the idea with option files is to specify ARGUMENTS for MySQL.

have_innodb is not an variable that can be set but a status indication.

<cut>

Martin> Second real example: Martin> While playing with those setting in /etc/my.cnf, I see when there's any Martin> kind of error, mysqld is started but exits because of wrong config lines Martin> in my.cnf. BUT, why does it create $hostname.err file not as usually in Martin> our case under basedir/log/ but under datadir/?

A small note about this; the err file is created by mysqld_safe as follows:

mysqld > error-file-name

Martin> I have in my.cnf: Martin> [mysqld_safe] Martin> set-variable = err_log=/usr/local/mysql/log/$host.err Martin> set-variable = pid_file=/usr/local/mysql/var/run/$host.pid

This is becasue you should not use set-variable with mysqld_safe but just:

[mysqld_safe] err_log=/usr/local/mysql/log/$host.err pid_file=/usr/local/mysql/var/run/$host.pid

In MySQL 4.0.3 everything is easier as you never have to use 'set-variable' anymore.

Martin> but it's somehow ignored. I had to modify mysqld_safe (see below).

Martin> This doesn't allow mysqld to start at all: Martin> [mysqld] Martin> err_log = /usr/local/mysql/log/jerboas.err Martin> pid_file = /usr/local/mysql/var/run/jerboas.pid

The above doesn't work as mysqld doesn't understand the err_log option. This is an option for the mysqld_safe script, not for mysqld.

<cut>

Martin> To make things more complicated, "mysqld --help" doesn't work if there's
a Martin> syntax error in /etc/my.cnf. :(

Just specify '--no-defaults' as the first option to mysqld:

mysqld --no-defaults --help

always works...

I have now fixed this and updated the comments in the mysql.server script. This will be be in 4.0.3.

Martin> For me would be the best if there would be mentioned variables/options, Martin> using which I could modify the settings in my.cnf. ;) What the user
might Martin> want to change? Only few, believe me. ;) datadir, basedir, error log and Martin> pid file locations.

In the option files you can set all options and variables that 'mysqld --help' prints.

Regards, Monty CTO of MySQL AB