Fix MySQL Error 2002: Can't Connect Through Socket

You run a cpanel" class="auto-link">WordPress deploy script, try to log into phpMyAdmin, or just type mysql -u root -p on your VPS, and instead of a password prompt you get: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2). Every site on the box that touches a database is now down. Here's how to work through it without guessing.

What This Error Actually Means

Error 2002 is different from error 2003 ("Can't connect through TCP/IP") or error 1045 (access denied). 2002 specifically means the MySQL client tried to connect over a Unix socket file — a local file that acts like a pipe between the client and the running mysqld process — and that file either doesn't exist, isn't listening, or the client is looking in the wrong place for it. It's a local connection problem, not a network or credentials problem.

Three root causes cover almost every case:

• MySQL/MariaDB isn't running. No process, no socket file — it never gets created.
• The socket file path doesn't match between what mysqld creates and what the client (or your app's config) expects.
• Disk is full or permissions are broken, so the service can't write the socket file even though it tried to start.

Step 1 — Check If MySQL Is Actually Running

SSH into the server and check the service status first. Don't skip this even if you're sure it's running — it's the fastest way to rule out a whole category of causes.

systemctl status mysql
# or, depending on distro/panel:
systemctl status mysqld
systemctl status mariadb

If it shows failed or inactive (dead), that's your answer — jump to Step 3. If it shows active (running) but you're still getting error 2002, the process is up but the socket path is mismatched — go to Step 2.

Step 2 — Find Where the Socket Actually Is

The socket file location is configurable, and it's a common source of this exact error after a MySQL/MariaDB version upgrade, a manual compile, or moving from a stock install to a cPanel-managed one (or vice versa). Find out where the running server actually put its socket:

mysqladmin variables 2>/dev/null | grep socket
# or, if mysqladmin itself can't connect:
find / -name "mysql.sock" 2>/dev/null

Common locations you'll run into:

Now compare that to what your client and your applications expect. Check /etc/mysql/my.cnf (or /etc/my.cnf) for the [client] section, and check your app's config — for WordPress that's wp-config.php, where DB_HOST is sometimes set to localhost:/path/to/mysql.sock instead of just localhost.

[client]
socket = /var/lib/mysql/mysql.sock

[mysqld]
socket = /var/lib/mysql/mysql.sock

Both the [client] and [mysqld] sections need the same path. If they disagree — say mysqld writes to /var/run/mysqld/mysqld.sock but [client] still points at the old /var/lib/mysql/mysql.sock from a previous install — that mismatch alone produces error 2002 even though the server is healthy and fully reachable over TCP on port 3306.

A quick workaround while you fix the config: force a TCP connection instead of a socket by adding -h 127.0.0.1 to your connection command. If that connects fine, you've confirmed it's a socket path issue, not a dead server.

mysql -u root -p -h 127.0.0.1

Step 3 — If the Service Won't Start at All

If Step 1 showed the service is down, check why before just restarting blind:

tail -50 /var/log/mysql/error.log
# CentOS/AlmaLinux path is often:
tail -50 /var/log/mariadb/mariadb.log

The two causes we see most often on VPS boxes:

Disk full

MySQL refuses to start (or crashes shortly after) if the partition holding /var/lib/mysql has no free space — it can't write InnoDB redo logs or the socket file. Check with:

df -h /var/lib/mysql

If it's at or near 100%, clear space before doing anything else — old binary logs, log files in /var/log, or leftover backup archives in /tmp are usually the culprit. Don't touch anything inside /var/lib/mysql itself while the service is stopped.

Permissions changed

If someone (or a broken restore script) changed ownership of /var/lib/mysql, mysqld can't write to its own data directory and refuses to start. Fix ownership back to the mysql user:

chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

Then re-check the error log if it still won't come up — a corrupted InnoDB log file after an unclean shutdown is the next most likely cause, and that needs a more careful recovery (starting with innodb_force_recovery) rather than a blind restart.

Step 4 — On a cPanel/WHM Server

If this is a managed cPanel box, don't hand-edit MySQL configs directly — WHM expects to control them. Instead:

• Check WHM → Service Status for MySQL/MariaDB's state.
• Restart it from there, or via /scripts/restartsrv_mysql over SSH.
• If WHM shows the service running but sites still throw 2002, check WHM → SQL Services to confirm the configured socket path matches what's in my.cnf — cPanel updates sometimes leave a stale reference after a MySQL version change.

Prevention

A few habits keep this from becoming a recurring fire drill:

• Monitor disk usage on the partition holding /var/lib/mysql, not just root — set an alert at 85%, not 95%.
• Test connections after every MySQL/MariaDB upgrade, especially manual ones outside your panel's update flow — socket paths are exactly the kind of detail that silently changes between major versions.
• Keep [client] and [mysqld] socket settings in sync whenever you touch my.cnf — it's easy to edit one section and forget the other.
• Rotate binary logs (see expire_logs_days / binlog_expire_logs_seconds) so they don't quietly eat the disk that MySQL itself needs to run.

Frequently Asked Questions

Is error 2002 the same as error 2003?

No. 2002 means the socket file connection failed (local, same machine). 2003 means a TCP/IP connection failed — usually a remote host, a firewall blocking port 3306, or MySQL not bound to that interface. If your app connects to a different server (like a managed database), you're dealing with 2003, and the fix is about networking and bind-address, not socket paths.

Why did this start happening after a server reboot?

Usually one of two things: the MySQL service isn't set to start on boot (systemctl enable mysql fixes that), or an unclean shutdown left InnoDB in a state where it won't auto-recover cleanly. Check the error log first — it'll tell you which.

Can I just recreate the socket file manually?

No — the socket file is created by the running mysqld process itself. You can't fake it into existence; if it's missing, the server process isn't running or isn't configured to put it where the client expects. Fix the underlying service or path issue instead.

My WordPress site shows "Error establishing a database connection" — is that the same issue?

It can be, but not always. That WordPress-level message covers wrong credentials, a corrupted database, and a downed MySQL server, in addition to socket problems. If SSH access shows error 2002 when you try connecting locally, you've confirmed it's this issue and not a WordPress config problem.

Should I switch my app to connect over TCP (127.0.0.1) instead of the socket permanently?

It works, but it's slightly slower than a Unix socket for same-machine connections and doesn't fix the underlying misconfiguration — it just routes around it. Fine as a temporary bridge while you sort out the socket path; not a long-term substitute for having your config sections agree.