Hi Kris, all,
Kris wrote:
> Joerg, thanks again for the help.
>
> I disagree with you.
that's perfectly fine - combining our two different viewpoints, we will
be able to show more of the issue at hand than from one point alone.
>
>>> I doubt many more users try to create a clean test installation of
>>> MySQL, in a specific directory, on a machine that already has MySQL
>>> installed.
>> Correct - but if really the occurrence in "mysql_install_db" were the
>> issue, then it would also occur with a single install.
>
> True, for a single install in a non-standard directory (try using a
> --prefix, --basedir, --datadir, all the flags I've shown), not for a
> single install that installs in /var and /usr/bin and
> uses /etc/mysql/my.cnf.
>
> mysql_install_db does not work as expected for 5.1 (probably previous
> versions, too), and I will show this next. The problem is that
> mysql_install_db, "somehow" always reads /etc/mysql/my.cnf. That's
> wrong. It should read @sysconfdir@/my.cnf.
Well, you explicitly say it is *not* a problem of "mysql_install_db"
issuing this option all by itself, but rather by taking it from a
system-wide config file. That knowledge is helpful.
I won't take any position which config file "mysql_install_db" should
read: True, you can argue it should take just the specific one for its
installation, but you can also argue that a system-wide config file
which may be read by the server should also be read by the script.
I will readily admit I am no expert on this, so please don't debate with
me which component should behave in which way.
>
>> You didn't exactly specify your platform, I can just tell it is some
>> Unix. I propose you check for all existing "my.cnf" and do a "ls -lu" on
>> them, then start your new server, then do that "ls -lu" again. I suspect
>> one (or more) of them will be read by the new server upon startup.
>
> It's Debian 5.0.
I asked for the platform just because on Linux I would recommend
"locate" for finding those config files, whereas this tool is not
available on other Unixes AFAIK.
>
> $ uname -a
> Linux syd.mkgnu.net 2.6.18-6-686 #1 SMP Sat Dec 27 09:31:05 UTC 2008
> i686 GNU/Linux
>
> I've just run:
>
> # find / | grep -i my.cnf
>
> And deleted every single my.cnf file, except from:
> /tmp/msource/etc/my.cnf
> /etc/mysql/my.cnf
>
> I still get the same error, because /etc/mysql/my.cnf is still there.
In such cases, I prefer doing "ls -lu" twice, to show the file was read.
Your approach of using "strace" is of course more exact, but also more
effort.
>
>>> This is just wrong. I should be able to build a clean MySQL and start it
>>> independently, even if I already have a previous, pre-packaged MySQL
>>> instance on the test machine.
>>>
>>> I believe the problem is in the MySQL tools. I shouldn't have to remove
>>> my existing MySQL installation just to build and test some other MySQL
>>> installation. That's exactly the whole rationale behind having a
>>> --prefix in ./configure, a --basedir, and so forth.
>> It is a question of policies and preferences.
>> MySQL traditionally supports both global, system-wide configuration
>> files and local ones, by instance.
>> Changing that might affect existing installations, so it can't be done
>> lightly and needs decent design and announcement.
>
> If this was a PATH issue, meaning I'm calling different mysql (5.0)
> binaries, I should be able to:
>
> export PATH=/tmp/msource/bin:$PATH
>
> ... then run:
>
> /tmp/msource/bin/mysql_install_db --basedir=/tmp/msource
> --datadir=/tmp/msource/data
I never claimed it to be a PATH issue - config files are not covered by
PATH.
And obviously the concept of having global config files, which is meant
to make it easy to have system-wide settings for multiple instances,
implies that these config files must be compatible with all versions
used on that system - which causes your problem, as the "--skip-bdb"
option is not compatible with 5.1.
Whether the advantage (system wide settings) or the disadvantage (read
from all versions) has the stronger weight - that differs by type of
usage. In your case, the compatibility requirement doesn't fit your use.
You don't state it explicitly, but I take your text to mean
"If the MySQL tools are compiled using --prefix, --basedir, or other
such settings, they should not read system-wide configuration files."
That is a possible request, different from the current MySQL policy.
I do not think it is easy to implement that.
Seen from the MySQL policy, the fault is with you: You should not have a
global "/etc/my.cnf" if you are dealing with multiple versions.
>
> ... and get the tables installed. I still get the same error though. I
> suspect that there are hardcoded paths in mysql that ALWAYS call the
> mysql tools from /usr/bin, or ALWAYS use /etc/mysql/my.cnf. It does not
> appear to me to be a question of policies, but a bug.
Did I claim that a policy always is perfect?
A "ls -lu" on "the mysql tools from /usr/bin" and "/etc/mysql/my.cnf"
should tell you whether one of these tools gets called (I sincerely hope
none is) and/or the config file gets read (that's what I suspect).
Below, you say that removing "/etc/my.cnf" solves the issue. From that,
we can tell that it is *not* caused by calling some MySQL tool from
/usr/bin, so the first one of your alternatives is wrong.
IMO, if such a tool were called, then there would really be a bug.
Reading the global "/etc/my.cnf" even from an installation at a
non-standard place is no bug (because MySQL is defined to use that
global file), but I understand your desire for a different behavior.
>
>
> I am attaching the output of:
> $ strace /tmp/msource/bin/mysql_install_db --basedir=/tmp/msource
> --datadir=/tmp/msource/data > /tmp/trace 2>&1
>
>
> The output observes:
>
> # mysql_install_db is opened on fd 3
> open("/tmp/msource/bin/mysql_install_db", O_RDONLY|O_LARGEFILE) = 3
>
> # From fd 3 one uses parameters that don't make sense. I did not specify
> --user=mysql. And I did not specify the pid file to be in /var/run.
> read(3, "--user=mysql\n--pid-file=/var/run/"..., 128) = 128
Did you notice that at this point, fd 3 has been closed since long, the
script is open on fd 255 from a "clone2()" call, and fd 3 is the result
of a "pipe()" call (several times)?
This is from your strace log:
|> pipe([3, 4]) = 0
|> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
|> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
|> rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
|> _llseek(255, -6882, [7451], SEEK_CUR) = 0
|> clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7d5a6f8) = 25976
|> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
|> rt_sigaction(SIGCHLD, {0x807e320, [], 0}, {0x807e320, [], 0}, 8) = 0
|> close(4) = 0
|> read(3, "--user=mysql\n--pid-file=/var/run/"..., 128) = 128
|> --- SIGCHLD (Child exited) @ 0 (0) ---
|> waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG) = 25976
|> waitpid(-1, 0xbfc245e8, WNOHANG) = -1 ECHILD (No child processes)
|> sigreturn() = ? (mask now [])
|> read(3, "r/lib/mysql\n--tmpdir=/tmp\n--langu"..., 128) = 128
|> read(3, "--max_allowed_packet=16M\n--thread"..., 128) = 128
|> brk(0x810e000) = 0x810e000
|> read(3, "size=16M\n--expire_logs_days=10\n--"..., 128) = 65
|> read(3, ""..., 128) = 0
|> close(3) = 0
Sadly, it does not tell which command is feeding into the pipe.
It might help to use
strace -f -ff -e trace=file,process ...
(from the man page, not verified).
>
> # Further down, I did not install mysql in /var/lib, but in /tmp/msource
> read(3, "/var/lib/mysql\n"..., 128) = 15
>
>
> It seems that mysql first consults hard-coded defaults that are
> *different* from the paths one specifies in the ./configure line. To me
> this seems wrong.
These hard-coded defaults are the global config file names.
>
>
> To verify this, after I remove /etc/mysql/my.cnf, installing the tables
> works:
>
> [[...]]
>
> Restoring /etc/mysql/my.cnf results in mysql_install_db to fail again.
This is valuable information, thank you.
>
> This suggests that any mysql test build will ALWAYS
> consult /etc/mysql/my.cnf, even if one already specified a different
> sysconfdir to ./configure.
>
> To me, this seems like a bug.
From the MySQL policy and definition, I'd say it is not a bug, but I
accept your position that there are cases where this is disturbing.
If you want to push for such a change, you should file a bug report and
set the "severity" field to "feature request" (I doubt the colleagues
would accept it as a bug). However, I won't make any claim whether it
will be accepted and when a change might occur - but as I consider this
a functional change, I expect it would only come with a new release
series, and for 5.5 the time frame is already pretty short now.
If you feel very strongly about this, you might come up with a patch,
this should increase the chances and/or sped up the implementation -
note, this is my very personal assumption and not a company position.
Regards,
Jörg
--
Joerg Bruehe, MySQL Build Team, joerg.bru...@sun.com
Sun Microsystems GmbH, Komturstrasse 18a, D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz
Amtsgericht Muenchen: HRB161028
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
