MySQL Bugs: #53863: my.cnf Syntax Error and Subsequent Error Handling

Bug #53863	my.cnf Syntax Error and Subsequent Error Handling
Submitted:	20 May 2010 17:21	Modified:	12 Jan 2012 16:55
Reporter:	ivo welch	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S4 (Feature request)
Version:	5.1.46	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	my.cnf

Description:

* Incorrect syntax (configurations) in my.cnf should emit a warning, or better yet, abort the mysql daemon startup (unless forced to start up).  I just spent days figuring out why my tables did not load.  It turns out that I had added to my.cnf "innodb_per_file" instead of "innodb_per_file=1".  it would have been much better if mysql had emitted an error message and not started up.  as it is, there wasn't even a warning.

* worse, because of this syntax error, mysql did not load the innodb engine.  it would have been better if mysql then had totally ignored the erroneous statement.  starting up incorrectly is not a good strategy.

* my mysqldump explicitly requested InnoDB.   alas, mysql now substitutes myISAM for InnoDB---again, WITHOUT A WARNING.  please emit a warning

How to repeat:

insert "innodb_per_file" in /etc/my.cnf without '=1'.

Suggested fix:

add an option at the start of the my.cnf file, that is "die-when-cnf-is-faulty = 1" and put it into the sample.cnf .  and, indeed, then die if it is faulty.  (in fact, I think this should be the default, but we can disagree about this.)

if an explicitly requested storage engine is not available (as it is by mysqldump), then emit at least a warning if you substitute another one.

I stand corrected on the warning message in the log on startup.  (I grepped for the wrong strong.  sorry.)  I still think it should fail then.

Thank you for the report.

Closing as "Not a Bug" because last comment. Actually this case (when not default storage engine could not be loaded) does not lead mysqld to shutdown by design.