Il sintomo: mysql.service in stato failed
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 mysqlLa causa: l’alternativa 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 mariadbSe 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 filesSoluzione 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-common3. 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.cnf4. Verificare la configurazione
update-alternatives --display my.cnf
cat /etc/mysql/my.cnf
my_print_defaults mysqldOra 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-pagerSe 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 mysqlSoluzione rapida provvisoria
Se 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 mysqlCome 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
EOFDopo ogni aggiornamento importante è buona abitudine controllare anche lo stato dell’alternativa con update-alternatives --display my.cnf.
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
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.
Lascia un commento