| Bug #65288 | child process mysql utilities picking up local config files causes test failure | ||
|---|---|---|---|
| Submitted: | 11 May 2012 20:46 | Modified: | 31 Jan 2014 21:37 |
| Reporter: | Nicholas Bamber (OCA) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Tests | Severity: | S3 (Non-critical) |
| Version: | 5.5.23, 5.5.26 | OS: | Linux |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | client utility config tests | ||
[12 May 2012 9:50]
Nicholas Bamber
Just to be extra careful I reran the test using an unchanged upstream tarball with an effectively identical result (modulo paths of test suite).
[22 May 2012 14:27]
Valeriy Kravchuk
Thank you for the bug report. Verified just as described with 5.5.26 on FC14.
[4 Jul 2012 6:52]
Valeriy Kravchuk
strace output from FC14
Attachment: strace.out (application/octet-stream, text), 96.13 KiB.
[31 Jan 2014 21:37]
Paul DuBois
Fixed in 5.5.37, 5.6.17, 5.7.4. Changes to test suite. No changelog entry needed.
[27 Mar 2014 14:07]
Laurynas Biveinis
5.5$ bzr log -r 4589 -n0
------------------------------------------------------------
revno: 4589
committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com>
branch nick: mysql_5_5
timestamp: Fri 2014-01-31 09:19:12 +0530
message:
Bug#14117012 - CHILD PROCESS MYSQL UTILITIES PICKING UP LOCAL
CONFIG FILES CAUSES TEST
Utility as "mysql_upgrade" forks "mysql"/"mysqlcheck". Attaching
"mysql_upgrade" shows following calls after forking "mysql" or
"mysql_check" when configuration file information is passed as
first argument to "mysql_upgrade".
strace -f ./mysql_upgrade --defaults-file=../pdb/my.cnf --socket=../pdb/mysql.sock -f
[pid 6254] stat("/etc/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
[pid 6254] stat("/etc/mysql/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
[pid 6254] stat("/usr/local/mysql/etc/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
[pid 6254] stat("/home/user_name/.my.cnf", {st_mode=S_IFREG|0664, st_size=19, ...}) = 0
[pid 6254] open("/home/user_name/.my.cnf", O_RDONLY) = 3
But when tool forks "mysqlcheck"/"mysql", "--no-defaults" is passed
as first argument. Before forking, in function "find_tool" of
"mysql_upgrade", check is made to verify whether tool can be
executable or not by calling "mysqlcheck --help" and "mysql --help".
But argument "--no-defaults", "--defaults-file" or
"defaults-extra-file" is not passed to "mysql" and "mysqlcheck".
So my.cnf is searched in default paths.
Fix:
------
Modified code to pass "--no-defaults" as first argument to "mysql"
and "mysqlcheck" while checking tool can be executed or not.
Description: It seems that many utility programs fork for example mysqlcheck, but that mysqlcheck can pick up incompatible config files to those used by the parent. This causes test failures but could potentially cause issues for end users. How to repeat: * What led up to the situation? I removed the Debian patches disabling various tests to investigate those the test failures. * What exactly did you do (or not do) that was effective (or ineffective)? Five tests failed one of them being: main.plugin_auth I reran that test and inspected the log file. Based upon that I captured the output of strace -f /home/nicholas/debian/svn/pkg-mysql/mysql-5.5/branches/unstable/builddir/client//mysql_upgrade --defaults-file=/home/nicholas/debian/svn/pkg-mysql/mysql-5.5/branches/unstable/builddir/mysql-test/var/my.cnf The output is attached. It shows that mysql_upgrade forks a mysqlcheck process and as far as mysql_upgrade goes everything is in order. However inspection of the trace log coming from the child process shows that it is reading locally stored config files as opposed to test specific config files. Hence it is not surprising that we get test failures. This is the most juicy extract from the strace log: [pid 16994] stat64("/usr/etc/my.cnf", 0xbfd4c290) = -1 ENOENT (No such file or directory) [pid 16994] stat64("/home/nicholas/.my.cnf", {st_mode=S_IFREG|0644, st_size=100, ...}) = 0 [pid 16994] open("/home/nicholas/.my.cnf", O_RDONLY|O_LARGEFILE) = 4 Although I view this as essentially a minor build test failure, I believe it could affect end users depending on how they are trying to manage their config files. This was originally reported as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672535. Suggested fix: I think the parent utility/client programs should pass on the config arguments to the child processes so that both read the same config files.