Quando MySQL non si avvia, il servizio risulta fallito e il log riporta l’errore Can't read dir of '/etc/mysql/mariadb.conf.d/'.

# service mysql status
× mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; preset: enabled)
     Active: failed (Result: exit-code)
     Status: "Server startup in progress"

mysqld: Can't read dir of '/etc/mysql/mariadb.conf.d/' (OS errno 2 - No such file or directory)
mysqld: [ERROR] Stopped processing the 'includedir' directive in file /etc/mysql/my.cnf at line 29.
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
systemd[1]: Failed to start mysql.service - MySQL Community Server.

Controllando i pacchetti installati, MySQL è regolarmente presente (pacchetti mysql-community-server 8.0 dal repository ufficiale Oracle).

dpkg -l | grep mysql

Perché MySQL non si avvia: my.cnf punta a mariadb.cnf

Su Debian il file /etc/mysql/my.cnf non è un file vero e proprio, ma un collegamento gestito da update-alternatives. Più pacchetti possono registrare la propria versione e, in modalità automatica, vince quella con la priorità più alta.

Durante l’aggiornamento è stato installato (e poi rimosso) il pacchetto mariadb-common, che registra /etc/mysql/mariadb.cnf con priorità 500, più alta di /etc/mysql/mysql.cnf (priorità 300). Il pacchetto è stato rimosso ma non eliminato del tutto (stato rc), quindi la sua configurazione è rimasta attiva. Alla riga 29 di quel file c’è l’inclusione di /etc/mysql/mariadb.conf.d/, una cartella che non esiste: MySQL legge la configurazione, non trova la directory e si interrompe.

Buona notizia: i dati in /var/lib/mysql non sono stati toccati. È solo un problema di configurazione.

Diagnosi: verificare dove punta my.cnf

ls -l /etc/mysql/my.cnf /etc/alternatives/my.cnf
update-alternatives --display my.cnf
sed -n '25,32p' /etc/mysql/my.cnf
dpkg -l | grep -i mariadb

Se il problema è questo, l’output sarà simile al seguente.

/etc/alternatives/my.cnf -> /etc/mysql/mariadb.cnf
/etc/mysql/my.cnf -> /etc/alternatives/my.cnf

my.cnf - modalità automatica
  la versione migliore del collegamento è /etc/mysql/mariadb.cnf
  il collegamento attualmente punta a /etc/mysql/mariadb.cnf
/etc/mysql/mariadb.cnf - priorità 500
/etc/mysql/my.cnf.fallback - priorità 100
/etc/mysql/mysql.cnf - priorità 300

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

rc  mariadb-common   1:10.11.18-0+deb12u1   all   MariaDB common configuration files

Soluzione passo passo

1. Fare un backup della configurazione

cp -a /etc/mysql /root/etc-mysql-backup-$(date +%F)

2. Eliminare i residui di mariadb-common

Il purge rimuove mariadb.cnf e la relativa voce in update-alternatives.

apt purge mariadb-common

3. Ripuntare my.cnf su mysql.cnf

update-alternatives --remove my.cnf /etc/mysql/mariadb.cnf 2>/dev/null
update-alternatives --set my.cnf /etc/mysql/mysql.cnf

4. Verificare la configurazione

update-alternatives --display my.cnf
cat /etc/mysql/my.cnf
my_print_defaults mysqld

Ora my.cnf deve puntare a /etc/mysql/mysql.cnf e includere /etc/mysql/conf.d/ e /etc/mysql/mysql.conf.d/. Se my_print_defaults mysqld stampa i parametri senza errori, la configurazione è corretta.

5. Avviare MySQL

systemctl start mysql
systemctl status mysql
journalctl -u mysql -n 50 --no-pager

Se my.cnf non è un collegamento simbolico

Se /etc/mysql/my.cnf è un file normale oppure /etc/mysql/mysql.cnf non esiste, si può ricreare la configurazione a mano.

mv /etc/mysql/my.cnf /etc/mysql/my.cnf.mariadb.bak
cat > /etc/mysql/my.cnf <<'EOF'
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
EOF
mkdir -p /etc/mysql/conf.d
systemctl start mysql

Soluzione rapida provvisoria

Se MySQL non si avvia e serve rimettere online il database subito, basta creare la cartella mancante. È però solo un tampone: MySQL continuerebbe a leggere la configurazione pensata per MariaDB, quindi è meglio applicare la soluzione completa appena possibile.

mkdir /etc/mysql/mariadb.conf.d && systemctl start mysql

Come evitare che si ripresenti

Conviene capire quale aggiornamento ha installato MariaDB, consultando lo storico di apt.

grep -i -B3 -A3 mariadb /var/log/apt/history.log*

Per impedire che mariadb-common venga reinstallato in futuro si può bloccarlo con un pin APT a priorità negativa.

cat > /etc/apt/preferences.d/no-mariadb <<'EOF'
Package: mariadb-*
Pin: release *
Pin-Priority: -1
EOF

Dopo ogni aggiornamento importante è buona abitudine controllare anche lo stato dell’alternativa con update-alternatives --display my.cnf. Prima del salto di versione, le note di rilascio di Debian 12 dicono quali pacchetti e configurazioni cambiano. Se invece ti serve una versione vecchia di MySQL su un server aggiornato, ho raccontato come ho isolato MySQL 5.7 in Docker.

Domande frequenti

Perdo i dati dei database?

No. Il problema riguarda solo i file di configurazione in /etc/mysql; i dati in /var/lib/mysql restano intatti.

Perché Debian ha scelto mariadb.cnf?

Perché l’alternativa my.cnf era in modalità automatica e mariadb.cnf ha priorità 500, più alta dei 300 di mysql.cnf. Con update-alternatives --set la scelta diventa manuale e non cambia più da sola.

Vale anche per Ubuntu?

Sì, il meccanismo di update-alternatives per my.cnf è lo stesso su Ubuntu e sulle altre distribuzioni derivate da Debian.

Conclusione

Se MySQL non si avvia dopo un aggiornamento, di solito il database è intatto. L’errore “Can’t read dir of /etc/mysql/mariadb.conf.d/” dopo un aggiornamento di Debian non indica un danno a MySQL, ma una configurazione residua di MariaDB rimasta attiva tramite update-alternatives. Eliminando mariadb-common con apt purge e reimpostando my.cnf su mysql.cnf, MySQL torna a funzionare regolarmente.

The post MySQL non si avvia dopo l’aggiornamento a Debian 12: causa e soluzione first appeared on Matteo Cisilino.