From: Stuart Henderson [...@spacehopper.org] > I for preferred any message of an invalid parameter in the log file, > instead of aborting.
If it stops mysql from running, people will take notice. Many people will miss it if it's just in the log. This argument is well understood, and I had it myself. Only, when you're responsible for a machine; or when you're the first to be hit, and not work with MySQL all the time, my.cnf might not be the first item to look at, or even think of. Look at the messages. There is more about stuff being disabled, mysql_upgrade to be run ... : 100531 20:37:22 mysqld_safe Starting mysqld daemon with databases from /var/mysql 100531 20:37:23 [Note] Plugin 'FEDERATED' is disabled. 100531 20:37:23 [Note] Plugin 'InnoDB' is disabled. /usr/local/libexec/mysqld: Table 'mysql.plugin' doesn't exist 100531 20:37:23 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 100531 20:37:23 [ERROR] /usr/local/libexec/mysqld: unknown option '--skip-bdb' 100531 20:37:23 [ERROR] Aborting I actually started trying to enable 'FEDERATED' and 'innoDB'. 'Note's, okay. Then I tried to force it to start for the mysql_upgrade. If an option is unknown, as here, I would simply not have expected the thing to abort. With my hat as system administrator, I have lost two days of life expectancy with this failure. Seriously, what is actually wrong with skipping configuration lines that are unambiguously out of place and/or not understood? I for one - and I guess everyone worth his money - check my /var/log files daily. Not necessarily /var/mysql/site.com.err. Not intending to contradict you, there might be situations when an unknown option is better graceful left aside, than dying without grace. Uwe
