Month: July 2015
Connecting to MySQL or MariaDB with sockets on Linux
The MySQL manual says
–socket=file_name, -S file_name … On Unix, the name of the Unix socket file to use, for connections made using a named pipe to a local server.
The default Unix socket file name is /tmp/mysql.sock.
which might surprise folks who’ve had to contend with the error message
“Can’t connect to local MySQL server through socket ‘[something-other-than-/tmp/mysql.sock]'”.
I’ll try to explain here why the name is often something quite different, how to know what the MySQL server is really listening for, what the fixes are for either users or application developers, and why it still matters.
Why the name is not always /tmp/mysql.sock
First, the Linux Foundation publishes a document “Filesystem Hierarchy Standard”. Version 2.3 says in the section about the /var/run directory: “Programs that maintain transient UNIX-domain sockets must place them in this directory.” Unfortunately Version 3 says something a bit different
in the section about the /run directory: “System programs that maintain transient UNIX-domain sockets must place them in this directory or an appropriate subdirectory as outlined above.” But version 3 also says: “In general, programs may continue to use /var/run to fulfill the requirements set out for /run for the purposes of backwards compatibility.” so /var/run is still standard.
Second, there’s a bit of fine print tucked away in an appendix of the MySQL manual: “For some distribution formats, the directory might be different, such as /var/lib/mysql for RPMs.” That’s a vague way of saying it’s determined at source-installation time by -DINSTALL_LAYOUT={STANDALONE|RPM|SVR4|DEB} which in effect causes this:
SET(INSTALL_UNIX_ADDRDIR_STANDALONE "/tmp/mysql.sock") SET(INSTALL_UNIX_ADDRDIR_RPM "/var/lib/mysql/mysql.sock") SET(INSTALL_UNIX_ADDRDIR_DEB "/var/run/mysqld/mysqld.sock") SET(INSTALL_UNIX_ADDRDIR_SVR "/tmp/mysql.sock")
but anybody can override that by setting MYSQL_UNIX_ADDR to something else.
And so different machines have different defaults. The following comes from notes I made long ago so may not be the latest information:
Non-Linux e.g. FreeBSD or Solaris: /tmp/mysql.sock Debian-based e.g. Ubuntu, and archlinux: /var/run/mysqld/mysqld.sock SUSE (after v11.2): /var/run/mysql/mysql.sock Red Hat, and SUSE (before v11.2): /var/lib/mysql/mysql.sock archlinux (very old versions): /tmp/mysqld.sock
Sometimes you can find out what the real default on your machine was,
by typing mysql_config –socket.
Finding what the server is really listening for
If you’re not the one who started the server, or the starting has disappeared in the mists of memory, there are various flawed ways to find what socket
it’s really opened.
Possible Method #1: netstat -lpn | grep mysqld
Example:
$ netstat -lpn | grep mysqld (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp6 0 0 :::3306 :::* LISTEN 4436/mysqld unix 2 [ ACC ] STREAM LISTENING 101567 4436/mysqld ./mysql_sock
… This method’s flaw is that, as the warning says, you won’t see everything unless you’re root. Also the “grep mysqld” filtering means it’s assumed the server’s name is mysqld.
Possible Method #2: find directory-list -name “mysql*.sock”
Example:
$ find /tmp /var/lib/mysql /var/run/mysqld -name "mysql*.sock" find: 'var/lib/mysql': Permission denied /var/run/mysqld/mysqld.sock
… This method’s flaw is that you have to guess in advance what directories the socket might be on.
Possible Method #3: ask via TCP
Example:
mysql -h 127.0.0.1 -e "select @@socket" +-----------------------------+ | /var/run/mysqld/mysqld.sock | +-----------------------------+
… This method’s flaw is in the assumption that the port is the default (3306), that the local host is accessible (I think it’s theoretically possible that it won’t be), and that everyone has the privilege to access MySQL this way.
Possible Method #4: look at the running process
Example (after finding with ps -A that mysqld process ID = 3938):
$ ps -fp 3938 UID PID PPID C STIME TTY TIME CMD 1000 3938 18201 0 09:58 pts/2 00:00:00 bin/mysqld --socket=./sock
… This method’s flaw is that it only works if –socket was specified explicitly on a mysqld command line, overriding the default configuration.
What a user can do
Once you know that the server is listening on socket X, you can redirect with ln, for example
ln -s /var/run/mysqld/mysqld.sock /tmp/mysql.sock
… The flaw this time is that it’s trying to solve a MySQL/MariaDB problem with a Linux workaround. The only reason that I mention it is that I’ve seen it recommended on Internet forums, so I guess some people see advantages here, which I don’t.
A better answer, then, would be: tell the client program what the socket is. On a client that follows the MySQL guidelines (such as the mysql client itself, or ocelotgui), this would mean setting the MYSQL_UNIX_PORT environment variable, or starting with –socket=X on the command line, or changing one of the configuration files such as ~/.my.cnf to add the line socket = X. Beware that the socket location might also be stored in other places, such as /etc/mysql/debian.cnf or php.ini.
What a client program should do
People who write client programs shouldn’t pass this socket hassle on to the user, if they don’t have to.
The mysql client tries to make things easier by, in effect, hard-coding a socket name so it’s the same as what the server got installed with. That’s a good try. My only criticism is that mysql –help will say that the socket parameter has “(No default value)” when, in a sense, it does.
I’ve been told that another client-GUI product tries to make things easier by automatically going with TCP. It’s difficult to criticize this — I’ve always thought that MySQL made trouble for itself by deciding that even when a user says “host=localhost” we should ignore the usual implication that the user is trying to use TCP and try to find a socket anyway — but here at Ocelot we try to behave the way the mysql client behaves, flawed or not.
So ocelotgui will try to make things easier by hard-coding the most likely paths. That is, if the user doesn’t specify a socket but the host is either default or ‘localhost’, then ocelotgui will try to connect via /tmp/mysql.sock, and if that fails then /var/lib/mysql/mysql.sock, and if that fails then /var/run/mysqld/mysqld.sock. That’s just the plan; currently ocelotgui isn’t doing it.
Is it worth caring about?
Couldn’t the Gordian socket be cut by saying protocol=TCP? What’s the point of finding the socket, anyway?
The answer usually is performance. The transfer rate with sockets is faster than with TCP because why do I need to worry about protocol when I’m talking to myself? I haven’t done a benchmark myself but Brandon D. Northcutt did and it does appear that sockets are worth the trouble if huge quantities of data are coming through.
However, really the TCP-versus-socket difference is a Linux problem, so why isn’t it being solved by the Linux crowd rather than the MySQL or MariaDB crowds? Well, unsurprisingly, that question has been asked before. So there is a fix, or more precisely there is a Google patch, which turns a TCP/IP connection into a socket connection if the target is localhost. There was an article about it on lwn.net in 2012. What happened after that, I don’t know.
By the way
The current state of ocelotgui (our open-source GUI client for MySQL and MariaDB) is still alpha, but it’s stable and good-looking now. Some screenshots are here. The latest release is 0.7, here.