Un problema di configurazione mi ha tenuto bloccato per un giorno e mezzo, non voglio che perdiate tutto questo tempo.
Non riuscivo più ad avviare MySQL.
O meglio, il demone sembrava sempre attivo:
$ ps aux | grep my mysql 60230 1.3 4.8 2173948 392788 ? Ssl 11:21 0:07 /usr/sbin/mysqld
Però lo stato del servizio era questo:
# systemctl status mysql.service
● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2024-10-15 10:09:47 CEST; 5s ago
Process: 23150 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
Main PID: 23158 (mysqld)
Tasks: 30 (limit: 9308)
Memory: 363.2M
CPU: 1.880s
CGroup: /system.slice/mysql.service
└─23158 /usr/sbin/mysqld
ott 15 10:09:47 jsbach systemd[1]: Starting MySQL Community Server...
Il log di errore inoltre stampava a ripetizione questo gruppo di righe:
2024-10-15T08:46:38.654804Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.39-0ubuntu0.22.04.1) starting as process 41656 2024-10-15T08:46:38.667469Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2024-10-15T08:46:40.683551Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 2024-10-15T08:46:41.490599Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed. 2024-10-15T08:46:41.490751Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel. 2024-10-15T08:46:41.521372Z 0 [ERROR] [MY-010273] [Server] Could not create unix socket lock file /var/run/mysqld/mysqld.sock.lock. 2024-10-15T08:46:41.521469Z 0 [ERROR] [MY-010268] [Server] Unable to setup unix socket lock file. 2024-10-15T08:46:41.521519Z 0 [ERROR] [MY-010119] [Server] Aborting 2024-10-15T08:46:43.132674Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.39-0ubuntu0.22.04.1) (Ubuntu). 2024-10-15T08:46:43.753568Z 0 [Warning] [MY-011807] [Server] Failed to connect to systemd notification socket named /run/systemd/notify. Error: 'Permission denied'
segno che il server si riavviava in continuazione.
Ora ho provato a cercare con varie chat (ChatGPT/Copilot) e tutte giustamente mi davano come suggerimenti quelli di verificare le directory
- /var/run/mysqld
- /run/systemd/notify
in particolare verificare che la prima fosse 755 per mysql:mysql e la seconda fosse 755 per root:root.
Cosa che era verificata.
Dopo aver vagato senza meta per molto tempo, ho capito
Sommario
Il nucleo del problema
In pratica il nucleo del problema era il seguente: mysql non poteva scrivere il file di socket dentro alla directory /var/run/mysqld anche se ne era il proprietario.
Per farla breve, nei sistemi Linux esiste la possibilità di installare un modulo di sicurezza ulteriore oltre alla politica di Linux. In Ubuntu ho installato AppArmor (SELinux ha getenforce per esempio).
AppArmor
AppArmor (Application Armor) è un modulo di sicurezza del kernel Linux che consente di controllare e limitare le capacità delle applicazioni in esecuzione. Funziona applicando un modello di sicurezza di tipo MAC (Mandatory Access Control), che impone restrizioni aggiuntive rispetto al normale modello di permessi basato sugli utenti e sui gruppi.
AppArmor permette di definire profili di sicurezza per le applicazioni, specificando cosa possono e non possono fare, come:
- Accesso a file specifici o directory
- Utilizzo di risorse di rete
- Esecuzione di altre applicazioni
- Accesso a dispositivi hardware
I profili di AppArmor possono essere impostati in modalità enforcing (applicazione delle regole) o complain (solamente logging delle violazioni), rendendolo uno strumento flessibile per rafforzare la sicurezza del sistema. AppArmor è utilizzato su molte distribuzioni Linux, come Ubuntu, per fornire una protezione aggiuntiva a livello del sistema.
Alcuni vantaggi di AppArmor:
- È relativamente semplice da configurare rispetto ad altre soluzioni come SELinux.
- Permette un controllo granulare sulle risorse e le azioni che un’applicazione può compiere.
Esempi d’uso tipici sono limitare le azioni di processi che richiedono privilegi elevati (ad esempio, i server web) o isolare container in ambienti come Docker o LXC.
Dunque il problema era lui. L’unica cosa che non ho capito è come la directory /var/run/mysqld sia finita tra le sue grinfie da un giorno all’altro, e questo merita un ulteriore approfondimento.
Per accorgermi di questo ho dovuto lanciare il comando
# aa-status apparmor module is loaded. 188 profiles are loaded. 178 profiles are in enforce mode. ... /usr/sbin/mysqld <----------- eccolo! ...
Soluzione del problema
Per fare questa operazione di togliere la directory incriminata dalle grinfie di AppArmor ho dovuto innanzitutto installare le apparmor-utils (solo aa-status funzionava):
# apt install apparmor-utils
Ho rilevato che esistevano due profili AppArmor in conflitto per MySQL.
Ecco come ho risolto il problema:
• Ho identificato e rimosso due profili duplicati. Ho rimosso il file /etc/apparmor.d/usr.sbin.mysqld.MOD e ho spostato in altra directory, per potermelo studiare a posteriori, il file /etc/apparmor.d/usr.sbin.mysqld.ORIG:
# rm /etc/apparmor.d/usr.sbin.mysqld.MOD # mv /etc/apparmor.d/usr.sbin.mysqld.ORIG /somewhere/else/
• Dopo aver rimosso il profilo duplicato, ho disabilitato il profilo AppArmor per MySQL:
# aa-disable /usr/sbin/mysqld Disattivazione di /usr/sbin/mysqld.
• Ho ricaricato AppArmor per applicare le modifiche:
# systemctl reload apparmor
• Ho finalmente e definitivamente riavviato il servizio MySQL per vedere se il problema era stato risolto:
# systemctl restart mysql
Dopodiché ho verificato lo stato del servizio
# systemctl status mysql
● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2024-10-15 11:21:58 CEST; 4min 59s ago
Process: 60222 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
Main PID: 60230 (mysqld)
Tasks: 35 (limit: 9308)
Memory: 365.2M
CPU: 4.955s
CGroup: /system.slice/mysql.service
└─60230 /usr/sbin/mysqld
ott 15 11:21:58 jsbach systemd[1]: Starting MySQL Community Server...
Questo non mi ha soddisfatto del tutto perché non vedo lo stato Started ma Starting.
In ogni caso non ci sono più log di errore:
2024-10-15T09:21:58.805799Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.39-0ubuntu0.22.04.1) starting as process 60230 2024-10-15T09:21:58.822502Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2024-10-15T09:21:59.680416Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 2024-10-15T09:22:00.258399Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed. 2024-10-15T09:22:00.258527Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel. 2024-10-15T09:22:00.326099Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.39-0ubuntu0.22.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu). 2024-10-15T09:22:00.389974Z 8 [Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'
La notizia più bella è
/usr/sbin/mysqld: ready for connections. Version: ‘8.0.39-0ubuntu0.22.04.1’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 (Ubuntu).
Provo a collegarmi dal client in localhost:
$ mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 570 Server version: 8.0.39-0ubuntu0.22.04.1 (Ubuntu) Copyright (c) 2000, 2024, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql>
Bingo!
Rimane da spiegare i comportamento dello status, ma per il momento sono rimasto troppo indietro con il resto dei lavori, me ne occupo un’altra volta.
Riferimenti
- Github
- Serverok.in (gli amici indiani sempre sul pezzo)
Commenti recenti