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

[11 May 2012 20:46] Nicholas Bamber
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
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 

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.
[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
  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.
  Modified code to pass "--no-defaults" as first argument to "mysql"
  and "mysqlcheck" while checking tool can be executed or not.