{"id":259,"date":"2026-10-13T09:50:06","date_gmt":"2026-10-13T07:50:06","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=259"},"modified":"2026-10-29T20:01:17","modified_gmt":"2026-10-29T19:01:17","slug":"mysql-ne-demarre-plus-debian-12","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/fr\/2026\/10\/13\/mysql-ne-demarre-plus-debian-12\/","title":{"rendered":"MySQL ne d\u00e9marre plus apr\u00e8s la mise \u00e0 jour vers Debian 12 : cause et solution"},"content":{"rendered":"

Le sympt\u00f4me : mysql.service \u00e0 l’\u00e9tat failed<\/h2>\n

Sous Debian 12, MySQL ne d\u00e9marre plus. Le service appara\u00eet en \u00e9chec et le log signale l’erreur Can't read dir of '\/etc\/mysql\/mariadb.conf.d\/'<\/code>.<\/p>\n

\"MySQL<\/figure>\n

Voici la sortie compl\u00e8te :<\/p>\n

# service mysql status\n\u00d7 mysql.service - MySQL Community Server\n     Loaded: loaded (\/lib\/systemd\/system\/mysql.service; enabled; preset: enabled)\n     Active: failed (Result: exit-code)\n     Status: \"Server startup in progress\"\n\nmysqld: Can't read dir of '\/etc\/mysql\/mariadb.conf.d\/' (OS errno 2 - No such file or directory)\nmysqld: [ERROR] Stopped processing the 'includedir' directive in file \/etc\/mysql\/my.cnf at line 29.\nmysqld: [ERROR] Fatal error in defaults handling. Program aborted!\nsystemd[1]: Failed to start mysql.service - MySQL Community Server.<\/code><\/pre>\n
En v\u00e9rifiant les paquets install\u00e9s, MySQL est bien pr\u00e9sent (paquets mysql-community-server<\/code> 8.0 du d\u00e9p\u00f4t officiel Oracle) :<\/p>\n
dpkg -l | grep mysql<\/code><\/pre>\n
La cause : l’alternative my.cnf pointe vers mariadb.cnf<\/h2>\n
Sous Debian, le fichier \/etc\/mysql\/my.cnf<\/code> n’est pas un vrai fichier. C’est un lien g\u00e9r\u00e9 par update-alternatives<\/strong>. Plusieurs paquets peuvent enregistrer leur propre version. En mode automatique, celle qui a la priorit\u00e9 la plus haute l’emporte.<\/p>\n
Pendant la mise \u00e0 jour, le paquet mariadb-common<\/strong> a \u00e9t\u00e9 install\u00e9 (puis retir\u00e9). Il enregistre \/etc\/mysql\/mariadb.cnf<\/code> avec une priorit\u00e9 de 500<\/strong>, sup\u00e9rieure \u00e0 celle de \/etc\/mysql\/mysql.cnf<\/code> (priorit\u00e9 300). Le paquet a \u00e9t\u00e9 retir\u00e9 mais pas enti\u00e8rement purg\u00e9 (\u00e9tat rc<\/code>). Sa configuration est donc rest\u00e9e active. \u00c0 la ligne 29 de ce fichier se trouve l’inclusion de \/etc\/mysql\/mariadb.conf.d\/<\/code>, un r\u00e9pertoire qui n’existe pas. MySQL lit la configuration, ne trouve pas le r\u00e9pertoire et s’arr\u00eate.<\/p>\n
Bonne nouvelle :<\/strong> les donn\u00e9es dans \/var\/lib\/mysql<\/code> n’ont pas \u00e9t\u00e9 touch\u00e9es. Ce n’est qu’un probl\u00e8me de configuration.<\/p>\n
Diagnostic : v\u00e9rifier vers o\u00f9 pointe my.cnf<\/h2>\n
ls -l \/etc\/mysql\/my.cnf \/etc\/alternatives\/my.cnf\nupdate-alternatives --display my.cnf\nsed -n '25,32p' \/etc\/mysql\/my.cnf\ndpkg -l | grep -i mariadb<\/code><\/pre>\n
Si le probl\u00e8me est bien celui-ci, la sortie ressemblera \u00e0 ceci :<\/p>\n
\/etc\/alternatives\/my.cnf -> \/etc\/mysql\/mariadb.cnf\n\/etc\/mysql\/my.cnf -> \/etc\/alternatives\/my.cnf\n\nmy.cnf - modalit\u00e0 automatica\n  la versione migliore del collegamento \u00e8 \/etc\/mysql\/mariadb.cnf\n  il collegamento attualmente punta a \/etc\/mysql\/mariadb.cnf\n\/etc\/mysql\/mariadb.cnf - priorit\u00e0 500\n\/etc\/mysql\/my.cnf.fallback - priorit\u00e0 100\n\/etc\/mysql\/mysql.cnf - priorit\u00e0 300\n\n!includedir \/etc\/mysql\/conf.d\/\n!includedir \/etc\/mysql\/mariadb.conf.d\/\n\nrc  mariadb-common   1:10.11.18-0+deb12u1   all   MariaDB common configuration files<\/code><\/pre>\n
Solution pas \u00e0 pas<\/h2>\n
1. Sauvegarder la configuration<\/h3>\n
cp -a \/etc\/mysql \/root\/etc-mysql-backup-$(date +%F)<\/code><\/pre>\n
2. Supprimer les r\u00e9sidus de mariadb-common<\/h3>\n
La purge supprime mariadb.cnf<\/code> et son entr\u00e9e dans update-alternatives :<\/p>\n
apt purge mariadb-common<\/code><\/pre>\n
3. Repointer my.cnf vers mysql.cnf<\/h3>\n
update-alternatives --remove my.cnf \/etc\/mysql\/mariadb.cnf 2>\/dev\/null\nupdate-alternatives --set my.cnf \/etc\/mysql\/mysql.cnf<\/code><\/pre>\n
4. V\u00e9rifier la configuration<\/h3>\n
update-alternatives --display my.cnf\ncat \/etc\/mysql\/my.cnf\nmy_print_defaults mysqld<\/code><\/pre>\n
D\u00e9sormais my.cnf<\/code> doit pointer vers \/etc\/mysql\/mysql.cnf<\/code> et inclure \/etc\/mysql\/conf.d\/<\/code> et \/etc\/mysql\/mysql.conf.d\/<\/code>. Si my_print_defaults mysqld<\/code> affiche les param\u00e8tres sans erreur, la configuration est correcte.<\/p>\n
5. D\u00e9marrer MySQL<\/h3>\n
systemctl start mysql\nsystemctl status mysql\njournalctl -u mysql -n 50 --no-pager<\/code><\/pre>\n
Si my.cnf n’est pas un lien symbolique<\/h2>\n
Si \/etc\/mysql\/my.cnf<\/code> est un fichier normal ou si \/etc\/mysql\/mysql.cnf<\/code> n’existe pas, on peut recr\u00e9er la configuration \u00e0 la main :<\/p>\n
mv \/etc\/mysql\/my.cnf \/etc\/mysql\/my.cnf.mariadb.bak\ncat > \/etc\/mysql\/my.cnf <<'EOF'\n!includedir \/etc\/mysql\/conf.d\/\n!includedir \/etc\/mysql\/mysql.conf.d\/\nEOF\nmkdir -p \/etc\/mysql\/conf.d\nsystemctl start mysql<\/code><\/pre>\n
Solution rapide quand MySQL ne d\u00e9marre plus<\/h2>\n
S’il faut remettre la base en ligne tout de suite, cr\u00e9ez le dossier manquant. Ce n’est toutefois qu’un pis-aller. MySQL continuerait \u00e0 lire la configuration pr\u00e9vue pour MariaDB. Il vaut donc mieux appliquer la solution compl\u00e8te d\u00e8s que possible.<\/p>\n
mkdir \/etc\/mysql\/mariadb.conf.d && systemctl start mysql<\/code><\/pre>\n
Comment \u00e9viter que cela se reproduise<\/h2>\n
Il est utile de comprendre quelle mise \u00e0 jour a install\u00e9 MariaDB, en consultant l’historique d’apt :<\/p>\n
grep -i -B3 -A3 mariadb \/var\/log\/apt\/history.log*<\/code><\/pre>\n
Pour emp\u00eacher mariadb-common<\/code> d’\u00eatre r\u00e9install\u00e9 \u00e0 l’avenir, on peut le bloquer avec un pin APT \u00e0 priorit\u00e9 n\u00e9gative :<\/p>\n
cat > \/etc\/apt\/preferences.d\/no-mariadb <<'EOF'\nPackage: mariadb-*\nPin: release *\nPin-Priority: -1\nEOF<\/code><\/pre>\n
Apr\u00e8s chaque mise \u00e0 jour importante, c’est aussi une bonne habitude de v\u00e9rifier l’\u00e9tat de l’alternative avec update-alternatives --display my.cnf<\/code>.<\/p>\n
Les notes de version de Debian 12<\/a> d\u00e9crivent les changements de cette version.<\/p>\n
Un autre pi\u00e8ge de configuration \u00e0 conna\u00eetre : MySQL 5.7 dans Docker et le port 3306 expos\u00e9<\/a>.<\/p>\n
Questions fr\u00e9quentes<\/h2>\n
Vais-je perdre les donn\u00e9es de mes bases ?<\/h3>\n
Non. Le probl\u00e8me ne concerne que les fichiers de configuration dans \/etc\/mysql<\/code> ; les donn\u00e9es dans \/var\/lib\/mysql<\/code> restent intactes.<\/p>\n
Pourquoi Debian a-t-il choisi mariadb.cnf ?<\/h3>\n
Parce que l’alternative my.cnf<\/code> \u00e9tait en mode automatique et que mariadb.cnf<\/code> a une priorit\u00e9 de 500, sup\u00e9rieure aux 300 de mysql.cnf<\/code>. Avec update-alternatives --set<\/code>, le choix devient manuel et ne change plus tout seul.<\/p>\n
Cela vaut-il aussi pour Ubuntu ?<\/h3>\n
Oui, le m\u00e9canisme de update-alternatives<\/code> pour my.cnf<\/code> est le m\u00eame sur Ubuntu et sur les autres distributions d\u00e9riv\u00e9es de Debian.<\/p>\n
Conclusion<\/h2>\n
L’erreur \u00ab Can’t read dir of \/etc\/mysql\/mariadb.conf.d\/ \u00bb<\/strong> n’indique pas que MySQL est endommag\u00e9. Quand MySQL ne d\u00e9marre plus, le coupable est une configuration r\u00e9siduelle de MariaDB. Elle est rest\u00e9e active via update-alternatives. En supprimant mariadb-common<\/code> avec apt purge<\/code> et en remettant my.cnf<\/code> sur mysql.cnf<\/code>, MySQL refonctionne normalement.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"
Apr\u00e8s la mise \u00e0 jour vers Debian 12, MySQL ne d\u00e9marre plus et les logs mentionnent mariadb.conf.d. Comment identifier la cause et la corriger sans toucher aux donn\u00e9es.<\/p>\n","protected":false},"author":1,"featured_media":748,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wpai_generated_summary":"","footnotes":""},"categories":[362],"tags":[301,297,333,293],"class_list":["post-259","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-serveurs-bases-de-donnees","tag-debian-12-fr","tag-mariadb-fr","tag-mise-a-niveau","tag-mysql-fr"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t