mysql no longer defaulting to /tmp/mysql.sock

Question

I was testing some software to see if it could connect to mysql correctly when mysql is not using /tmp/mysql.sock.

I stopped mysql, editted /etc/my.cnf to add socket=/var/lib/mysql/mysql.sock restarted and mysql was on the new socket just fine.

Fixed my software.

Now I stopped mysql, removed socket statement from /etc/my.cnf, restarted mysql and it is still using /var/lib/mysql/mysql.sock.

I have restarted and cannot get it to use /tmp/mysql.sock unless I add it to /etc/my.cnf and I do not want to do that because of testing constraints.

Why would it no longer go to /tmp/mysql.sock when there is no configure parameter and there is no commmand line parameter (that I can see from ps aux) either?

Linux CentOS 6.5 Final mysqld Ver 5.6.17 for Linux on i686 (MySQL Community Server (GPL))

Help me with this please.

Thanx

Log entries

140624 10:37:36 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2014-06-24 10:37:37 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defa
2014-06-24 10:37:37 1277 [Note] Plugin 'FEDERATED' is disabled.
2014-06-24 10:37:37 1277 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2014-06-24 10:37:37 1277 [Note] InnoDB: The InnoDB memory heap is disabled
2014-06-24 10:37:37 1277 [Note] InnoDB: Mutexes and rw_locks use InnoDB's own implementation
2014-06-24 10:37:37 1277 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-06-24 10:37:37 1277 [Note] InnoDB: Using Linux native AIO
2014-06-24 10:37:37 1277 [Note] InnoDB: Not using CPU crc32 instructions
2014-06-24 10:37:37 1277 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-06-24 10:37:37 1277 [Note] InnoDB: Completed initialization of buffer pool
2014-06-24 10:37:37 1277 [Note] InnoDB: Highest supported file format is Barracuda.
2014-06-24 10:37:38 1277 [Note] InnoDB: 128 rollback segment(s) are active.
2014-06-24 10:37:38 1277 [Note] InnoDB: Waiting for purge to start
2014-06-24 10:37:38 1277 [Note] InnoDB: 5.6.17 started; log sequence number 6066054
2014-06-24 10:37:38 1277 [Note] Server hostname (bind-address): '*'; port: 3306
2014-06-24 10:37:38 1277 [Note] IPv6 is available.
2014-06-24 10:37:38 1277 [Note]   - '::' resolves to '::';
2014-06-24 10:37:38 1277 [Note] Server socket created on IP: '::'.
2014-06-24 10:37:38 1277 [Note] Event Scheduler: Loaded 0 events
2014-06-24 10:37:38 1277 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.17'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)

Answer 1

The MySQL documentation states that the default path to mysql.sock is /var/lib/mysql/ on RPM distributions. The path is set at compile-time depending on the target OS and can be overridden by configuration or command line, so for CentOS the behavior you are seeing is correct.

This means that the socket path must have originally been set to /tmp by some other mechanism. There are several places this could have been done; likely in the init script /etc/init.d/mysql.server (to set socket=/tmp/mysql.sock on the command line - this can be done in an init script even though it is unsupported) or a local options file. See this page in the documentation for MySQL's precedence order when processing startup options. Entries listed later in the table will override the preceding ones.

It probably isn't possible to trace the sequence of events leading up to the socket path change, but fortunately you can change it via ~/.my.cnf, the user-specific option file.

Answer 2

Funnily enough something like this happened to me last night. I'm trying to install MySQL from source as a non-root user and I also got messages about /var/xxx &c.
Go to root and do a sudo find . -name "my.cnf" and you should find what you're looking for in one of those files - if they exist.
As Dartonw points out, it could be something in your init scripts also - if the first solution doesn't work, do a sudo find . -name "mysq*" | grep -v "\/usr\/bin" - and see what init files are present. The grep -v "\/usr\/bin" hides your mysql executables (or similar - not tested) from the search. N.B. Because of the way the forum software works, it's not showing what I wrote correctly - for find you have to escape the / (slash) characters with a \ (backslash) in the grep commands.

[Update] If you install mysql client libraries, they will put a my.cnffile in /etc/mysql with /var/run/mysqld.sock and /var/run/mysqld.pid which your system may pick up. Learnt this to my cost - _another OS reinstall!_