Erreur démarrage MySql

Pour des raisons inconnues, l'instance MySql ne démarrait plus sur une machine Ubuntu lors du boot. Cependant le service pouvait être démarré après le processus de démarrage terminé.

Cet article présente une analyse et le moyen mis en place pour corriger cette anomalie.

Attentio, les origines pevent être mulitples et la solution présentée pourrait ne pas s'appliquer dans tous les cas.

Votre avis

Nobody voted on this yet  You need to enable JavaScript to vote

Tweet

Analyse

MySql est démarré en tant que service. La première analyse consiste à regarder les fichiers traces du system de service, soit systemctl dans le cadre de cet article.

La commande journalctl est utilisé pour consulter les messages de démarrage.

#sudo journatctl -xe | grep mysql
-- Subject: L'unité (unit) mysql.service a commencé à démarrer
-- L'unité (unit) mysql.service a commencé à démarrer.
mars 23 13:43:52 etienne-server audit[2353]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/2353/status" pid=2353 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=115
mars 23 13:43:52 etienne-server audit[2353]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=2353 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=0
mars 23 13:43:52 etienne-server audit[2353]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/2353/status" pid=2353 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=115
mars 23 13:43:52 etienne-server kernel: audit: type=1400 audit(1521809032.168:12): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/2353/status" pid=2353 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=115
mars 23 13:43:52 etienne-server kernel: audit: type=1400 audit(1521809032.169:13): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=2353 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=0
mars 23 13:43:52 etienne-server kernel: audit: type=1400 audit(1521809032.169:14): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/2353/status" pid=2353 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=115
-- Subject: L'unité (unit) mysql.service a terminé son démarrage
-- L'unité (unit) mysql.service a terminé son démarrage, avec le résultat done.

La première constation concerne les interdictions par AppArmor sur les emplacements suivants.

• /proc/2353/status
• /sys/devices/system/node/

A ce stade, il semble que la solution consiste à donner les droits sur ces emplacements. Pour ce faire, il faut modifier le fichier /etc/apparmor.d/local/usr.sbin.mysqld avec le contenu suivant.

# Site-specific additions and overrides for usr.sbin.mysqld.
# For more details, please see /etc/apparmor.d/local/README.

/var/opt/mysql/mysqld_custom.cnf r,
/proc/*/status r,
/sys/devices/system/node/ r,
# /etc/mysql/conf.d/mysqld_custom.cnf r,

Attention, ce fichier possède une modification pour les paramètres personnalisés comme expliqué dans l'article suivant.

Cependant lors du redémarrage suivant, la base n'est toujours pas disponible et peut quand même être démarrée manuellement. La consultation du message indique une nouvelle restriction par AppArmor.

#sudo journatctl -xe | grep mysql
mars 23 22:10:44 etienne-server kernel: audit: type=1400 audit(1521839444.269:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/mysqld" pid=581 comm="apparmor_parser"
mars 23 22:10:44 etienne-server audit[581]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/mysqld" pid=581 comm="apparmor_parser"
-- Subject: L'unité (unit) mysql.service a commencé à démarrer
-- L'unité (unit) mysql.service a commencé à démarrer.
mars 23 22:20:47 etienne-server audit[2673]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/node0/meminfo" pid=2673 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=0
mars 23 22:20:47 etienne-server kernel: audit: type=1400 audit(1521840047.287:12): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" 
name="/sys/devices/system/node/node0/meminfo" pid=2673 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=0
-- Subject: L'unité (unit) mysql.service a terminé son démarrage
-- L'unité (unit) mysql.service a terminé son démarrage, avec le résultat done.

Ce même message est visible dans le fichier /var/log/syslog.

Mar 23 22:20:46 etienne-server systemd[1]: Starting MySQL Community Server...
Mar 23 22:20:47 etienne-server kernel: [  620.549008] audit: type=1400 audit(1521840047.287:12): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/node0/meminfo" pid=2673 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=0
Mar 23 22:20:51 etienne-server systemd[1]: Started MySQL Community Server.

Le fichier /etc/apparmor.d/local/usr.sbin.mysqld peut être modifié de nouveau pour ajouter le nouvel emplacement problématique.

# Site-specific additions and overrides for usr.sbin.mysqld.
# For more details, please see /etc/apparmor.d/local/README.

/var/opt/mysql/mysqld_custom.cnf r,
/proc/*/status r,
/sys/devices/system/node/ r,
/sys/devices/system/node/node0/meminfo r,
# /etc/mysql/conf.d/mysqld_custom.cnf r,

Cependant, le problème persiste. La dernière recherche concerne l'état du service à l'aide de la commande systemctl.

#sudo systemctl status mysql
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Et une chose est particulièrement intriguante concerne le statut indiqué comme disabled alors que la valeur par défaut, information vendor preset, est enabled.

Résolution

La correction du statut du service va être la solution dans le cadre de cet article. Il suffit de modifier le statut pour rendre le service actif avec l'argument enable de la commande systemctl.

#sudo systemctl enable mysql

Beaucoup d'article propose la modification de la configuration de AppArmor mais cela était inefficace. De plus, il est rarement question de modifier le fichier d'extension, mais quasiment toujours le fichier standard à l'emplacement /etc/apparmor.d/usr.sbin.mysqld. Ceci n'est pas une bonne pratique car lors des mises à jour des paquets, les modifications devront être fusionnées, ou au pire perdues.

Toutes les modifications réalisées dans le précédent paragraphes ont été annulées, puisque seule la modification du statut a été efficace.