MySQL Bugs: #70708: mysql client does not read correct socket information from my.cnf

Bug #70708	mysql client does not read correct socket information from my.cnf
Submitted:	23 Oct 2013 16:40	Modified:	14 Dec 2013 19:27
Reporter:	Greg Lane	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Command-line Clients	Severity:	S3 (Non-critical)
Version:	5.6.14	OS:	Linux
Assigned to:		CPU Architecture:	Any
Tags:	client, my.cnf, MySQL, socket

Description:
After installing mysql 5.6.14 I moved the /usr/my.cnf to another location, /var/lib/mysql.  After running mysql_install_db feeding the options for datadir and defaults-file and user I attempted to connect to the server to secure it.  The connection was refused saying it could not connect to socket /var/lib/mysql/mysql.sock.  I confirmed what I had named the socket /var/lib/mysql/mysqld.sock in [client], [mysqld_safe], and [mysqld].  I then removed all the files created by mysql_install_db and ran again confirming beforehand that the socket was named whatever.sock in all the areas of the my.cnf file.  Still getting same error.  Tried the reinstall again this time naming it back to mysqld.sock.  Same error each time cannot connect to socket /var/lib/mysql/mysql.sock.  So this time I moved the my.cnf file to /etc/my.cnf and from that point the connection worked like it was supposed to work.  I confirmed the error by moving the my.cnf back to previous location and got the same error again.  It looks like it reads location but not the file name assigned if the my.cnf is not in a default location.

How to repeat:
After installing 5.6.14 via rpm's move the /usr/my.cnf file to non default location.  Run mysql_install_db with datadir and your location of your defaults-file with user mysql.  After this is complete attempt to connect using mysql -uroot -p 

at this point you should get the error

Thank you for the bug report. You can see the default location from where
the client reads the my.cnf using the mysql --help and looking:

Default options are read from the following files in the given order:
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf                              
The following groups are read: mysql client                          
The following options may be given as the first argument:            
--print-defaults        Print the program argument list and exit.    
--no-defaults           Don't read default options from any option file.
--defaults-file=#       Only read default options from the given file #.
--defaults-extra-file=# Read this file after the global files are read.

So you expect that the client should read my.cnf from non-default locate
without to use --defaults-file=# ? . Thanks.

If I understood you wrong please check if the same case you are pointing: http://bugs.mysql.com/bug.php?id=69843 > Thanks.

It's not that expect it to but it seems that it does to a certain extent.  When I started the server using mysqld_safe i checked it using ps -ef | grep mysqld.  it read out the proper socket and pid as identified in the my.cnf in the non-default location.  Also the error of not being able to connect with the client says "Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'".  So this tells me the client is reading from the location that i have the my.cnf file but not the name i have given to the socket file, which is /var/lib/mysql/mysqld.sock.  Normally if the client isn't configured in my.cnf it tries to locate the socket in /tmp if I am not mistaken.

I checked that case and didn't think it has anything to do with mysql_install_db.  It seems to me that it gets everything right up until getting the name of the socket file itself.  The location is correct but the socket file is not.  Of course I could use -S or --socket and get the connection correct but if the [mysqld_safe] and [mysqld] section are read correctly form the location of my.cnf then why doesn't [client] not read it correctly?

Thank you for the report.

Please specify location of the configuration file using option --defaults-file explicitly and inform us if the issue still exists.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".