MySQL Bugs: #4466: Nothing in .err when mysql service ends because of malformed my.ini options

Bug #4466	Nothing in .err when mysql service ends because of malformed my.ini options
Submitted:	8 Jul 2004 16:34	Modified:	21 Aug 2004 2:49
Reporter:	d di (Basic Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S2 (Serious)
Version:	4.0.18-nt	OS:	Windows (win2k)
Assigned to:	Reggie Burnett	CPU Architecture:	Any

Description:
Accidentally typed in "set-variable = record_rnd_buffer=32M" instead of "set-variable = read_rnd_buffer=32M" in c:\winnt\my.ini.

Upon "NET START MySQL", the following error message is output:
"Error 1067: The process terminated unexpectedly"

with absolutely no clue as to whatever just happened.
No clue in the NT event viewer or the <machine-name>.err file either.

Don't know if it's a bug or not, but it's definately not very newbie friendly.
(Same goes to having 3 different names for the same options..)

How to repeat:
"set-variable = record_rnd_buffer=32M" in c:\winnt\my.ini, net start mysql.

Suggested fix:
A minimum of error handling when parsing the configuration file..
Perhaps some suggestions for using new names for deprecated option names..

The 1067 service start error no means that the server/service  has crashed,
instead it means that an abort server  action was performed due to not
existing valid variable in your configuration file (my.ini).

Thanks

Yes, it's quite obvious what the 1067 error means.
It means that the MySQL executable terminated into the nothingness, and that the Windows Service Manager would have expected it to do otherwise.

If you ask any experienced Windows Service programmer, they would probably tell you that the MySQL service is buggy when it does this.

There's no need to tell me that MySQL terminated due to a configuration error - I stated that in the initial report.

Feel free to consider this a feature request. It really can't be good for database newbies that MySQL dies like that and doesn't even leave a clue in the MySQL error file as to why it suddenly gave up and went away.

Suggested fix:
Echo a line into the mysql error file stating that there was an error in line xxx of the configuration file, and that MySQL is giving up.

Thank you for the note, actually when started as service the err file isn't filled like
the standalone start does:

C:\mysql\bin>mysqld-nt --standalone --console
mysqld-nt: ERROR: unknown variable 'record_rnd_buffer=32M'

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
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

This has been fixed by causing errors such as this to report to the Windows event log.  Note that this will only happen in NT builds.

I have made additional changes based on feedback and submitted a new patch.

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
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

This has been fixed.  MySql will now print error messages to the Windows event log in addition to the .err file normally used.