Serveur dédié : résoudre l’erreur “Can’t connect to local MySQL server through socket”

Après une mise à jour du serveur SQL, ou après un redémarrage physique du serveur, il est possible d’obtenir l’erreur suivante :

error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Missing /var/run/mysqld/mysqld.sockCode language: PHP (php)

On peut aussi la rencontrer sous cette forme :

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)Code language: JavaScript (javascript)

Cette erreur signifie que le client MySQL essaie de se connecter à un socket Unix local, mais que le fichier mysqld.sock n’existe pas à l’emplacement attendu.

Le problème peut avoir plusieurs causes : MySQL n’est pas démarré, le serveur écoute sur un autre socket, le répertoire /run/mysqld n’existe pas, ses permissions sont incorrectes, ou le service n’arrive pas à créer son socket au boot.

Comprendre le rôle de mysqld.sock

Sur Linux, une connexion locale à MySQL ou MariaDB peut passer par un socket Unix plutôt que par TCP/IP.

Au lieu de se connecter à :

127.0.0.1:3306Code language: CSS (css)

le client utilise un fichier spécial, souvent situé ici :

/var/run/mysqld/mysqld.sockCode language: JavaScript (javascript)

ou, plus précisément sur les systèmes modernes :

/run/mysqld/mysqld.sock

Sur beaucoup de distributions, /var/run est un lien symbolique vers /run. Le répertoire /run est temporaire : son contenu est recréé à chaque démarrage. C’est précisément pour cela qu’un problème de création du dossier /run/mysqld peut réapparaître après un reboot.

MySQL explique que le chemin du socket peut être défini avec l’option socket dans les fichiers de configuration, aussi bien dans une section serveur comme [mysqld] que dans une section client comme [client].

Première vérification : MySQL tourne-t-il vraiment ?

Avant de corriger le socket, il faut vérifier que le serveur SQL est réellement démarré.

Selon votre installation, le service peut s’appeler mysql, mysqld ou mariadb.

systemctl status mysql --no-pager
systemctl status mysqld --no-pager
systemctl status mariadb --no-pager

Sur les installations MySQL officielles, la documentation indique que systemd permet de gérer le serveur avec systemctl start|stop|restart|status mysqld, tandis que certaines distributions utilisent aussi la commande compatible service.

Si le service est arrêté, tentez un démarrage :

sudo systemctl start mysql

ou :

sudo systemctl start mariadb

Si le service échoue, consultez les logs :

sudo journalctl -u mysql -n 100 --no-pager
sudo journalctl -u mariadb -n 100 --no-pager

Si MySQL ne démarre pas du tout, le problème ne vient pas seulement du socket. Le socket est absent parce que le serveur n’a pas réussi à se lancer.

Vérifier si le socket existe ailleurs

Il arrive que MySQL fonctionne, mais que le client cherche le socket au mauvais endroit.

On peut rechercher les sockets MySQL/MariaDB actifs :

sudo find /run /var/run /tmp -type s -name '*mysql*.sock' -o -name '*mysqld*.sock' 2>/dev/nullCode language: JavaScript (javascript)

On peut aussi vérifier les sockets ouverts avec ss :

sudo ss -xl | grep -E 'mysql|maria|mysqld'Code language: JavaScript (javascript)

Si vous trouvez un socket ailleurs, par exemple :

/tmp/mysql.sock

alors le client et le serveur ne sont probablement pas configurés avec le même chemin.

Vérifier la configuration du socket

Sur Debian, Ubuntu et dérivés, les fichiers de configuration peuvent se trouver dans plusieurs emplacements :

/etc/mysql/my.cnf
/etc/mysql/mysql.conf.d/mysqld.cnf
/etc/mysql/mariadb.conf.d/*.cnf
/etc/my.cnf

Pour trouver les directives socket :

grep -R "^[[:space:]]*socket" /etc/mysql /etc/my.cnf 2>/dev/nullCode language: JavaScript (javascript)

Une configuration cohérente peut ressembler à ceci :

[client]
socket = /var/run/mysqld/mysqld.sock

[mysqld]
socket = /var/run/mysqld/mysqld.sockCode language: JavaScript (javascript)

Ou avec le chemin moderne équivalent :

[client]
socket = /run/mysqld/mysqld.sock

[mysqld]
socket = /run/mysqld/mysqld.sockCode language: JavaScript (javascript)

L’important n’est pas tant de choisir /run ou /var/run, mais d’avoir le même chemin côté serveur et côté client.

MySQL documente aussi plusieurs manières de corriger un socket mal placé : définir socket dans les fichiers d’options, passer --socket en ligne de commande, ou utiliser la variable d’environnement MYSQL_UNIX_PORT.

Tester une connexion avec un socket explicite

Pour vérifier si le problème vient uniquement du chemin du socket, testez une connexion en indiquant le socket explicitement :

mysql --socket=/run/mysqld/mysqld.sock -u root -pCode language: JavaScript (javascript)

Ou :

mysql --socket=/var/run/mysqld/mysqld.sock -u root -pCode language: JavaScript (javascript)

Vous pouvez aussi forcer TCP/IP :

mysql --protocol=tcp -h 127.0.0.1 -u root -p

Si TCP fonctionne mais pas le socket, le serveur tourne bien, mais le socket local pose problème. Si rien ne fonctionne, il faut revenir aux logs du service SQL.

Le cas classique : /run/mysqld n’existe pas au boot

Dans mon cas, systemd lançait bien le service MySQL, mais le serveur ne semblait pas pouvoir créer son fichier socket. Le répertoire /var/run/mysqld, ou plutôt /run/mysqld, n’était pas présent avec les bons droits au démarrage.

Comme /run est temporaire, créer le dossier à la main règle le problème uniquement jusqu’au prochain reboot :

sudo mkdir -p /run/mysqld
sudo chown mysql:mysql /run/mysqld
sudo chmod 0755 /run/mysqld

Pour rendre la correction persistante, on peut demander à systemd de recréer ce répertoire au démarrage via tmpfiles.d.

Solution persistante : créer un fichier tmpfiles.d

On crée un fichier dédié :

sudo nano /etc/tmpfiles.d/mysql.conf

On y ajoute :

# systemd tmpfile settings for MySQL.
# See tmpfiles.d(5) for details.

d /run/mysqld 0755 mysql mysql -Code language: PHP (php)

Si votre configuration utilise explicitement /var/run/mysqld, vous pouvez écrire :

d /var/run/mysqld 0755 mysql mysql -Code language: JavaScript (javascript)

Sur les systèmes modernes, /var/run pointe généralement vers /run, donc les deux chemins reviennent souvent au même. Personnellement, je préfère utiliser /run/mysqld, car c’est le chemin réel.

La ligne d /run/mysqld 0755 mysql mysql - signifie : créer un répertoire, avec les permissions 0755, appartenant à l’utilisateur mysql et au groupe mysql.

On applique ensuite la règle sans redémarrer :

sudo systemd-tmpfiles --create /etc/tmpfiles.d/mysql.conf

Puis on redémarre MySQL :

sudo systemctl restart mysql

ou MariaDB :

sudo systemctl restart mariadb

Enfin, on vérifie :

ls -ld /run/mysqld
ls -l /run/mysqld/mysqld.sock
mysqladmin ping

Si tout est correct, mysqladmin ping doit répondre :

mysqld is alive

Alternative systemd : RuntimeDirectory

Sur une configuration systemd propre, le service MySQL ou MariaDB peut aussi créer son répertoire runtime via RuntimeDirectory. C’est souvent géré par le paquet de la distribution.

Pour inspecter l’unité systemd :

systemctl cat mysql
systemctl cat mariadb

Cherchez une ligne de ce type :

RuntimeDirectory=mysqld

Si cette directive existe et que le répertoire n’est pas créé, le problème peut venir d’une unité modifiée localement, d’un override, d’un paquet abîmé, ou d’une configuration héritée d’une ancienne migration.

Pour lister les overrides :

systemctl cat mysql
systemctl show mysql | grep -E 'RuntimeDirectory|User|Group'Code language: JavaScript (javascript)

Je préfère généralement corriger l’unité systemd si elle est manifestement cassée. Mais dans un cas simple où seul le répertoire runtime manque après boot, tmpfiles.d reste une correction fiable et lisible.

Vérifier les permissions du dossier runtime

Le socket doit être créé par l’utilisateur qui exécute MySQL, généralement mysql.

ps -eo user,group,comm | grep -E 'mysqld|mariadbd'Code language: JavaScript (javascript)

Le répertoire doit donc appartenir à cet utilisateur :

ls -ld /run/mysqld

Résultat attendu :

drwxr-xr-x 2 mysql mysql ... /run/mysqld

Si le dossier appartient à root, MySQL peut échouer à créer le socket :

sudo chown mysql:mysql /run/mysqld
sudo chmod 0755 /run/mysqld
sudo systemctl restart mysql

Ne pas créer un faux fichier mysqld.sock

Il ne faut jamais régler ce problème en créant manuellement un fichier vide :

sudo touch /var/run/mysqld/mysqld.sockCode language: JavaScript (javascript)

Un socket Unix n’est pas un fichier texte classique. Il doit être créé par le processus MySQL lui-même lorsqu’il démarre et écoute localement.

Créer un faux fichier ne fait que masquer le symptôme, et peut même empêcher MySQL de créer le vrai socket ensuite. C’est l’équivalent sysadmin de dessiner une prise électrique sur un mur. Ambitieux, mais peu conductif.

Cas WordPress : erreur de connexion à la base

Sur WordPress, cette erreur peut se traduire par :

Error establishing a database connection

Si DB_HOST vaut localhost, PHP essaie souvent d’utiliser le socket Unix MySQL. Si vous mettez 127.0.0.1, il force généralement une connexion TCP/IP.

define( 'DB_HOST', 'localhost' );Code language: JavaScript (javascript)

peut utiliser un socket, tandis que :

define( 'DB_HOST', '127.0.0.1' );Code language: JavaScript (javascript)

force une connexion TCP locale.

Changer localhost en 127.0.0.1 peut dépanner temporairement si MySQL écoute bien sur TCP, mais cela ne corrige pas la cause du socket manquant. Sur un serveur local, le socket reste souvent plus direct et performant.

Diagnostic rapide complet

Voici la séquence que j’utiliserais aujourd’hui pour diagnostiquer proprement :

# 1. Vérifier le service.
systemctl status mysql --no-pager || systemctl status mariadb --no-pager

# 2. Lire les derniers logs.
journalctl -u mysql -n 100 --no-pager || journalctl -u mariadb -n 100 --no-pager

# 3. Vérifier les sockets existants.
sudo ss -xl | grep -E 'mysql|maria|mysqld'
sudo find /run /var/run /tmp -type s \( -name '*mysql*.sock' -o -name '*mysqld*.sock' \) 2>/dev/null

# 4. Vérifier la configuration socket.
grep -R "^[[:space:]]*socket" /etc/mysql /etc/my.cnf 2>/dev/null

# 5. Vérifier le dossier runtime.
ls -ld /run/mysqld /var/run/mysqld 2>/dev/null

# 6. Tester MySQL.
mysqladmin ping
mysql --protocol=tcp -h 127.0.0.1 -u root -pCode language: PHP (php)

Correction rapide temporaire

Si vous voulez simplement relancer le service immédiatement :

sudo mkdir -p /run/mysqld
sudo chown mysql:mysql /run/mysqld
sudo chmod 0755 /run/mysqld
sudo systemctl restart mysql

Ou pour MariaDB :

sudo mkdir -p /run/mysqld
sudo chown mysql:mysql /run/mysqld
sudo chmod 0755 /run/mysqld
sudo systemctl restart mariadb

Cette correction dépanne immédiatement, mais elle peut disparaître au prochain reboot si /run/mysqld n’est pas recréé automatiquement.

Correction persistante avec tmpfiles.d

Pour rendre la correction durable :

sudo tee /etc/tmpfiles.d/mysql.conf > /dev/null <<'EOF'
# systemd tmpfile settings for MySQL.
# See tmpfiles.d(5) for details.

d /run/mysqld 0755 mysql mysql -
EOF

sudo systemd-tmpfiles --create /etc/tmpfiles.d/mysql.conf
sudo systemctl restart mysqlCode language: PHP (php)

Pour MariaDB, la règle reste généralement identique, car l’utilisateur système est souvent mysql et le répertoire reste /run/mysqld.

Vérifiez ensuite :

ls -ld /run/mysqld
ls -l /run/mysqld/mysqld.sock
mysqladmin ping

Mémo rapide

# Erreur typique.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

# Vérifier le service.
systemctl status mysql --no-pager
journalctl -u mysql -n 100 --no-pager

# Correction temporaire.
sudo mkdir -p /run/mysqld
sudo chown mysql:mysql /run/mysqld
sudo chmod 0755 /run/mysqld
sudo systemctl restart mysql

# Correction persistante.
sudo nano /etc/tmpfiles.d/mysql.conf

# Contenu du fichier.
d /run/mysqld 0755 mysql mysql -

# Appliquer sans reboot.
sudo systemd-tmpfiles --create /etc/tmpfiles.d/mysql.conf

# Redémarrer MySQL.
sudo systemctl restart mysql

# Vérifier.
mysqladmin ping
ls -l /run/mysqld/mysqld.sock

# Tester via TCP si besoin.
mysql --protocol=tcp -h 127.0.0.1 -u root -pCode language: PHP (php)

Conclusion

L’erreur Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) signifie que le client MySQL ne trouve pas le socket Unix attendu.

La première chose à vérifier est toujours l’état réel du service MySQL ou MariaDB. Si le serveur ne démarre pas, le socket sera forcément absent.

Si le service démarre, mais que le répertoire /run/mysqld disparaît après reboot ou possède de mauvais droits, la correction persistante consiste à créer une règle tmpfiles.d :

d /run/mysqld 0755 mysql mysql -

Après application de cette règle et redémarrage du service, MySQL peut recréer son socket normalement, et les clients locaux peuvent à nouveau se connecter.

Ce n’est pas une panne spectaculaire, mais elle bloque tout : sites WordPress, scripts CLI, sauvegardes, cron, monitoring. Un petit répertoire manquant dans /run, et tout le serveur prend un air dramatique. Classique.

Report a typo