Bug #3413 mysqld: strange interpretation of --defaults-file option
Submitted: 7 Apr 2004 7:42 Modified: 28 Apr 2004 19:18
Reporter: Matthias Leich Email Updates:
Status: Closed Impact on me:
Category:MySQL Server Severity:S2 (Serious)
Version:4.0 , 4.1 OS:
Assigned to: Michael Widenius CPU Architecture:Any

[7 Apr 2004 7:42] Matthias Leich
mysqld's interpretation of the --defaults-file=<configuration file> does not meet my expectations, when the <configuration file> does not exist.

1. I would expect that the start fails with a message like
   <configuration file> does not exist ... abort

2. mysqld tries to start a database sitting in <source-distribution>/var.
   It might be successful to start this database, but this is a action not
   intended by the writer of the start statement and the help message of mysqld
      --defaults-file=#       Only read default options from the given file #
   The not intended start of that database consumes/uses/locks resources 
   (ports,memory,database container files) and can prevent the daily operation
   of other important databases.
   BTW: The files /etc/my.cnf <source-distribution/var/my.cnf ~/.my.cnf
        do not exist on my box.

How to repeat:
Please create three databases
  ONE  DATADIR=<source-distribution/var   -  no DATADIR/my.cnf
       Assume this database was created for test purposes direct after the
       installation of MySQL. Actually nobody uses or needs this database.
       Somebody forgot to delete that database.
  TWO  DATADIR=<somewhere1>        - <somewhere1>/my.cnf (port=9350, ...) 
       Assume this database is actually often used for tests.
  THREE DATADIR=<somewhere2>       - <somewhere2>/my.cnf (port=3306, ...)
       Assume this database is the most important and it should be started
       in ten minutes.

Please try to start TWO with
  1. correct start options 
    <source-distribution>/libexec/mysqld --defaults-file=<somewhere1>/my.cnf
        ----> works good (how expected) 
  2. stop the database
  3. a small typo within the start options
    <source-distribution>/libexec/mysqld --defaults-file=<not exact file name>
        ----> databas ONE comes up !!!

And now try to start the important database THREE:
     <source-distribution>/libexec/mysqld --defaults-file=<somewhere2>/my.cnf
        ----> Can't start server: Bind on TCP/IP port: Address already in use
              Do you already have another mysqld server running on port: 3306 ?

Suggested fix:
I prefer the following solution:
If somebody writes a explicit "--defaults-file=<filename>" in the starting option
and that file does not exist, mysqld should give an error message and abort.
[7 Apr 2004 8:36] Matthias Leich
The same strange behaviour will also occur if somebody uses the --defaults-file option in connection with command line tools like 'mysql'. 
Here may arise a big risk. 
Let's assume the following szenario:
Somebody starts such a tool and expects!! that he affects the database assigned by
the defaults-file option. But if he makes my small typo in the filename, he will
will affect the database running in <source-distribution>/var, listening on 
port:3306 ... If that database is the important production database, he is
able to produce expensive damages (DROP TABLE, DELETE ..).
[27 Apr 2004 8:51] Michael Widenius
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at

Additional info:

I don't think it's 100 % safe to do this in 4.0 as some users may depend on the old behaviour.  The orginal idea was just that --defaults-file would be a rename of the original option file and in this context the old behaviour was ok.

I have however in 4.1 changed this so that if you use --defaults-file, the given option file must exists.

The fix will be in 4.1.2