--V
sean c peters wrote:
The problem is that i did build 4.1.3 florm a source distribution, and set the datadir via configure to be /var/mysql-4.1.3/, and it doesnt read my.cnf from there anyway.
In regard to the section of the manual mentioned:
http://dev.mysql.com/doc/mysql/en/Option_files.html
It states:
DATADIR represents the location of the MySQL data directory. Typically this is `/usr/local/mysql/data' for a binary installation or `/usr/local/var' for a source installation. Note that this is the data directory location that was specified at configuration time, not the one specified with --datadir when mysqld starts. Use of --datadir at runtime has no effect on where the server looks for option files, because it looks for them before processing any command-line arguments.
So, even by specifying the datadir at the command line when starting mysql, according to this documentation, mysql wont even bother looking in the command line specified datadir for a my.cnf
On Friday 13 August 2004 10:15, V. M. Brasseur wrote:
In my experience, where the my.cnf file is concerned, mysqld does not care what you define for the value of the --datadir flag. The order of precedence for locating my.cnf files is: 1) /etc/my.cnf 2) my.cnf in the COMPILED-IN DEFAULT datadir 3) .my.cnf in the user's $HOME
That "compiled-in default" makes all the difference. You can start mysqld with as many different renditions of the --datadir flag as you want, but if one of them isn't the default path which was compiled in at build time (using the --localstatedir flag for configure) then mysqld will not automatically locate any my.cnf file in the specified datadir. For instance, I start all my servers with a --datadir=/path/to/mysql/data flag and have a my.cnf file in that directory. However, depending upon the platform and installation, the mysqld server will be looking in a number of different (and often non-existent) locations for the my.cnf file instead, such as /usr/local/mysql/var or similar.
This is something which has caused many headaches on the machines I administer, occassionally leading to an intricate web of links to allow the server to locate the appropriate file.
These links are not the only way to direct the server towards the appropriate my.cnf file. To be honest, they're only a hack and I wouldn't recommend them. One way to handle this is to rebuild MySQL from a source distribution, using the appropriate configure flags to set new default paths to be compiled into the binaries.
A much easier way is to use the --defaults-file and/or --defaults-extra-file flags when starting the mysqld server. These flags--and not the value of any datadir flag--are what really tell mysqld where to locate the options file(s) it should use. The one drawback I've found with these flags is remembering to use the same flag(s) on any client programs which are run and training users to do the same. This has been enough of a pain to make it worth my while to deal with the web of links at this point. When all the machines are upgraded to MySQL 4.0.20 later this year, they will be receiving self-compiled binaries with our own flavor of default paths so none of these workarounds will be necessary.
For more information about this sort of thing, check this page in the manual: http://dev.mysql.com/doc/mysql/en/Option_files.html
Also, Paul DuBois' "MySQL" book has good information presented in a very accessible manner.
Cheers,
--V
sean c peters wrote:
I am 100% convinced that mysql 4.1.3 beta is not properly reading the my.cnf configuration files. If i remove the /etc/my.cnf file and try to start mysql 4.1.3 with (im working from /usr/local/mysql-4.1.3/bin)
./mysqld_safe
i get the following output: (mccoy is the name of the machine im on)
touch: /usr/local/mysql-4.1.3/var/mccoy.err cannot create chown: /usr/local/mysql-4.1.3/var/mccoy.err: No such file or directory Starting mysqld daemon with databases from /usr/local/mysql-4.1.3/var ./mysqld_safe: /usr/local/mysql-4.1.3/var/mccoy.err: cannot create
If i remove the /var/mysql-4.1.3/my.cnf file, i get the same output as above, so its not being read either way. And i did specify /var/mysql-4.1.3/ as my datadir with .configure when building 4.1.3
if i put the /etc/my.cnf file back, i get the following:
A mysqld process already exists
So clearly, the /etc/my.cnf is being read, but the /var/mysql-4.1.3/my.cnf is not. so i guess it doesnt matter what i specify in there at this point.
One strange thing is that ./msqyd_safe tries to use the databases in /usr/local/mysql-4.1.3/var/ But i specified a different datadir with configure! my configure --prefix=/usr/local/mysql-4.1.3 but why should that matter?
In fact, when i installed 4.1.3 (make install), the directory /usr/local/mysql-4.1.3/var/ was NOT created.
I dont think most of the info ive given matters, because my run-time configuration doesnt appear to be the problem. I dont believe that my build configuration took effect properly. Does any of this make sense?
Still completely lost. thanks sean peters [EMAIL PROTECTED]
*** Here's some my.cnf data, if it really matters ***
Here is part of the /var/mysql-4.1.3/my.cnf file: [client] port = 3307 socket = /tmp/mysql-4.1.3.sock pid-file = /usr/local/mysql-4.1.3/mysql-4.1.3.pid datadir = /var/mysql-4.1.3/
[mysqld] port = 3307 socket = /tmp/mysql-4.1.3.sock pid-file = /usr/local/mysql-4.1.3/mysql-4.1.3.pid datadir = /var/mysql-4.1.3/
And here is info from /etc/my.cnf file: [client] port = 3306 socket = /tmp/mysql.sock
[mysqld] port = 3306 socket = /tmp/mysql.sock
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
