ERROR 2002 printed a socket path MySQL never dialed: the message stops at 100 characters

The first thing I did was retype the path. The client had just told me this:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket
'/Users/administrator/.../.tmp-pf010/sssssssssssssssssssssssssssssssssssssssssss.s' (2)

Look at the end of it. .s, not .sock. I passed --socket a path ending in .sock, and the error came back with the last three characters gone. That reads like exactly one thing: I fat-fingered the filename, or something mangled it on the way in.

Neither was true. The path in that message is not the path the client dialed, and on MySQL 26.7.0 it never can be once the path gets long enough — the message stops at 100 characters.

Why the truncation looks like a real clue

This happened while I was standing up a throwaway MySQL instance for an unrelated measurement, in a workspace directory that was already 98 characters deep. So the socket landed somewhere north of 100 characters, and I knew there was a length limit on Unix domain sockets. On Darwin, sun_path is 104 bytes including the terminating NUL.

That gives you a very tempting story: the path was too long, the kernel silently cut it, the server bound one name and the client dialed another. It explains the symptom, it involves a real limit, and it is wrong in every part that matters.

Same path, two outcomes

Here is the control that settled it. One socket path, 103 characters, which is legal. Nothing changes between the two runs except whether the server is up.

Server running:

$ mysql --socket="$P" -u root -e "SELECT 'connected at 103 chars' AS result;"
result
connected at 103 chars
$ mysqladmin --socket="$P" -u root ping
mysqld is alive

Then shut the server down and dial the same string with the same client:

$ mysql --socket="$P" -u root -e "SELECT 1;"
ERROR 2002 (HY000): Can't connect to local MySQL server through socket
'/Users/.../.tmp-pf010/sssssssssssssssssssssssssssssssssssssssssss.s' (2)

The connection that worked a second earlier used the full 103-character path. So the dial is fine. What shortened is the rendering of the path inside the error string, and mysqladmin will show you both halves of that in a single message if you ask it the same question:

$ mysqladmin --socket="$P" -u root ping
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/Users/.../sssssssssssssssssssssssssssssssssssssssssss.s' (2)'
Check that mysqld is running and that the socket:
'/Users/.../sssssssssssssssssssssssssssssssssssssssssss.sock' exists!

Truncated in the error, complete in the hint below it. Two renderings of one string, four lines apart.

The cut is at a fixed length, not at a fraction of the path. Dialing a dead socket at increasing path lengths on this build:

Under 100, you see what you typed. Over it, you see the first 100 characters and no indication that anything was dropped. The errno is (2) — ENOENT — in every one of those rows, which is honest: there really is no socket file there. It just isn't at the truncated name the message shows you.

The limit that does exist is loud

The sun_path limit is real, and MySQL checks it up front. Passing a socket path of 104 characters or more:

[ERROR] [MY-010267] [Server] The socket file path is too long (> 103):
    /Users/administrator/.../s.sock
[ERROR] [MY-010119] [Server] Aborting

103 characters starts and serves. 104 refuses to start at all. There is no silent truncation on the server side, no half-bound socket, no divergence between what the server created and what the client asks for.

What made this hard to see is where that message goes. It is written to the error log, and if you launched mysqld with --log-error pointing at a file you were not tailing — or redirected stdout to /dev/null because you were scripting the setup — then the only thing you have in your terminal is the client's ERROR 2002, with its convincing, shortened path. A server that refused to start and a server that is running normally produce the same client-side evidence.

What to do with a suspicious path

Compare it against the filesystem instead of reading it. If the path in the error is exactly 100 characters, the message is capped and tells you nothing about what was dialed:

python3 -c "print(len('<paste the path from the error>'))"
ls -l "$P"          # the path you actually passed

If ls finds a socket and the client still fails, you have a permissions or ownership question. If ls finds nothing, read the server's error log before touching the path — that is where a refusal to start will be, in full. And when the path you passed is 104 or longer, the server never started, regardless of what the client's message implies.

For the immediate fix, put the socket somewhere short, like --socket=/tmp/<name>.sock, and leave the data directory wherever your workspace needs it. The two are independent, and only the socket path is against a kernel ceiling.

What this was measured on

MySQL 26.7.0 from Homebrew, arm64, on macOS with Darwin 24.6.0, using disposable data directories and a dedicated port. The 100-character cap and the > 103 server check are from that build and that platform.

I have not tested this on Linux, where sun_path is 108 bytes and the server's threshold will be a different number. I have not tested MariaDB, older MySQL releases, or non-libmysqlclient drivers — a Python or Go connector formats its own error and may print the path in full, which would make this particular confusion a client-library property rather than a MySQL one. If you have that result on Linux, the interesting part is whether the message cap is still 100 there, since it is clearly independent of the 103.