MySQL Bugs: #60729: mysqld startup should NOT parse ~/.my.cnf for [mysqld] entries

Bug #60729	mysqld startup should NOT parse ~/.my.cnf for [mysqld] entries
Submitted:	2 Apr 2011 5:31	Modified:	2 Apr 2011 8:41
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: General	Severity:	S2 (Serious)
Version:	5.1	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	[mysqld], ~/my.cnf, mysqld, startup, windmill

Description:
While the behaviour of mysqld is as documented, http://dev.mysql.com/doc/refman/5.1/en/option-files.html, I believe this behaviour is unexpected and not safe.

Specifically the parsing of ~/.my.cnf file for mysqld startup seems to be unusual. I recently had an issue as described in http://mysqldump.azundris.com/archives/92-Fighting-the-mysqld-init-script.html (I am the colleague) and this server had been untouched for some time, so the modified configuration in ~root/.my.cnf (from where the server is started, /etc/init.d/mysql) was pulled in to the configuration in an unexpected way.

Most applications read their data from /etc/<application>/<config_file>, or if running as non-root perhaps $HOME/[<application>/]<config_file> and these config files are always visible. So can not be that easily overlooked.

I certainly use ~/.my.cnf to configure "login information" to avoid the password being visible in output such as ps (on unix boxes) and that seems to me to be a normal usage.

So I'd question the fact that mysqld at least should use ~/.my.cnf as a configuration file for collecting it's configuration. This extra configuration can be easily overlooked.

Also by default the various init scripts are pretty silent about describing the configuration they are using and where it comes from which makes debugging an issue such as the one described by Kris more tricky.

So please consider, at least for mysqld startup, to NOT read from the ~/.my.cnf file at all.

I've not checked 5.5 behaviour but would expect it to be similar.

How to repeat:
Please see Kris' description of the problem.

A misconfigured ~/.my.cnf may make a server startup not work as expected.

Debugging an issue like this on a box which is normally running 24x7x365 after a "simple upgrade" means you have little time to diagnose and resolve problems, so the added "lack of visibility" of a ~/.xxx file is often something that may go unnoticed.

Suggested fix:
1. mysqld should NOT read ~/.my.cnf on startup. The other list of files it uses are fine.
2. mysqld should explicitly state which files it has collected configuration information from in its startup logging. (this is not done now)
3. less important but also useful would be to improve the /etc/init.d/mysql error message as described by Kris:

That is this line in the script should be more descriptive:

...
log_failure_msg "Couldn't find MySQL manager ($manager) or server ($bindir/mysqld_safe)"
...

Should probably be something like

if [ "$use_mysqld_safe" = 0 ]
then
log_failure_msg "MySQL manager ($bindir/mysqlmanager) not found in \$bindir"
else
log_failure_msg "mysqld_safe ($bindir/mysqld_safe) not found in \$bindir"
fi

I believe Kris' logic may have been inverted. That is be more specific about what you can not find and where you are looking.

What you ask for makes sense, but as current behavior is described and intended, all items (but more clear error message, maybe) are feature requests. We should consider them for 5.6+, but for already released GA versions these changes are hardly possible. Users may rely on ~/.my.cnf usage by all MySQL programs, as documented.

Thanks for replying rapidly on this. I understand the desire to not change GA version (hence 5.1 or 5.5).

Changing the behaviour in 5.6 (to at least _not_ read the ~/.my.cnf file) would be a reasonable change I believe.

Also noted at least for mysql client behaviour while much of the documentation mentions ~/.my.cnf it seems the actual implementation of finding this location is by using $HOME, and not looking up the user's home directory via /etc/passwd or the appropriate system call. That can be confusing as many system set $HOME to / on boot up (I've seen this in Linux) and so mysql clients (and maybe the server don't look in the root user's home directory. Perhaps this behavoiur should be clarified in the documentation as client side behaviour from init created daemons (like puppet) can be behave unexpectedly in these conditions.