MySQL Bugs: #38306: Incorrect path name to --init-file gives misleading error of mysql server crash

Bug #38306	Incorrect path name to --init-file gives misleading error of mysql server crash
Submitted:	23 Jul 2008 5:30	Modified:	20 Aug 2008 8:51
Reporter:	Hema Sridharan	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Errors	Severity:	S3 (Non-critical)
Version:	mysql-6.0	OS:	Linux
Assigned to:	Lars Thalmann	CPU Architecture:	Any

Description:
I create init file(innodb.init and falcon.init) where I had SET GLOBAL storage_engine='Innodb' and 'Falcon' respectively.

These files are kept in Include folder of any suite. I give reference to these init files from combinations file like,

[innodb]
--init-file=../../suite/backup/include/innodb.init

Now if I give incorrect path to this init-file and execute the tests from suite, I notice mysql server crash.

How to repeat:
1)The init files are include folder of backup suite.
2)The combinations file has 

[innodb]
--init-file=../../suite/x/include/innodb.init

Now execute the following:
./mysql-test-run.pl --suite=backup

=======================================================

TEST                           RESULT         TIME (ms)
-------------------------------------------------------

backup.backup_try 'innodb'    [ fail ]

mysqltest: Could not open connection 'default': 2013 Lost connection to MySQL server at 'reading initial communication packet'

From the above, we notice that incorrect path leads to mysql server crash. If we give correct path, this crash does not occur.

Suggested fix:
No server crash should be noticed for incorrect path name for init-file, rather just show an error.

Please look if you can get more specific informations here by using trace or truss.

Also please look into core file from server crash if you can isolate the problem

Hi,

This is not essentially a crash, however for some reason the mtr is not able to handle the incorrect path name for --init-file clearly and reports it as "lost connection".In this case it simply means "server accepted a connection from the test client but got terminated due to bad startup options thus resulting in a server crash". Ideally test framework should not report the failure as "mysql server crash". 

Reporting behavior of errors needs to be changed for mysql test framework.

./libexec/mysqld --defaults-file=/home/myuser/mysqlbzr/etc/my.cnf --init-file=/home/myuser/myqslbzr/bla.init &

080724 15:03:37  InnoDB: Started; log sequence number 0 56773
080724 15:03:37 [ERROR] ./libexec/mysqld: File '/home/myuser/myqslbzr/bla.init' not found (Errcode: 2)
080724 15:03:37 [ERROR] Aborting

080724 15:03:37  InnoDB: Starting shutdown...
080724 15:03:39  InnoDB: Shutdown completed; log sequence number 0 56773
080724 15:03:39 [Note] ./libexec/mysqld: Shutdown complete

As you can see:
If you give a wrong directory to the --init-file the server won't start. It throws error code: 2

perror 2
OS error code   2:  No such file or directory

Of course your test will fail with a connection error when server isn't up.

Magnus Svensson wrote on IRC:

  "Server does not crash, it just accepts the connection from the
  client, then tries to run the init-connect and that fails. The
  server will then just disconnect the client.

  It has nothing to do with test case or not. It's about how the
  server should handle faulty "init-connect"
  http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#option_mysqld_init_con...

  If you set that variable wrong the server will not allow any
  connections to be made, that just how it is.

  Well, it says "not executed for users that have the SUPER priv"

  If possible the server should give a clear error message before
  disconnecting the client. But that is propabably not possible with
  our curent protocol. Even if the server should send an error
  message, the client is not expecting it so it would just
  claim "packets out of order"

  It's the same when an SSL connection fails.

  We could fix both of these problems by extending our protcol to
  allow an error message to be sent before server disconnects.

  But it might be that case that this happens so early that we don't
  event know what protocol version the client supports and then it would
  be impossible anyway."

It seems that there is no crash at all and that the server 
behave as it should.