web-dev-qa-db-fra.com

MariaDB ne démarre pas après la mise à niveau vers Ubuntu 16.04

Mis à jour vers Ubuntu 16.04 à partir de 14.04 x64

Si j'essaie de démarrer mysqld cela échoue et j'ai dans le syslog

kernel: [ 2336.792423] audit: type=1400 audit(1470265086.730:518): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=11850 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=117 ouid=0

J'ai ajouté /run/systemd/notify/ à apparmor, mais je ne peux pas ajouter run/systemd/notify - "/" est manquant.

Comment puis-je réparer cela? J'ai besoin de MariaDB pour fonctionner sur une partition séparée

J'utilise MariaDB avec un dossier de données sur /home/db/mysql J'ai eu un lien symbolique configuré pour y pointer

lrwxrwxrwx 1 mysql mysql 14 iun 22 20:58 /var/lib/mysql -> /home/db/mysql

et avait également configuré le profil d'armure de l'application:

# vim:syntax=apparmor
# Last Modified: Tue Jun 19 17:37:30 2007
#include <tunables/global>

/usr/sbin/mysqld {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/user-tmp>
#include <abstractions/mysql>
#include <abstractions/winbind>

capability dac_override,
capability sys_resource,
capability setgid,
capability setuid,

network tcp,

/etc/hosts.allow r,
/etc/hosts.deny r,

/etc/mysql/*.pem r,
/etc/mysql/conf.d/ r,
/etc/mysql/conf.d/* r,
/etc/mysql/*.cnf r,
/usr/lib/mysql/plugin/ r,
/usr/lib/mysql/plugin/*.so* mr,
/usr/sbin/mysqld mr,
/usr/share/mysql/** r,
/var/log/mysql.log rw,
/var/log/mysql.err rw,
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid rw,
/var/run/mysqld/mysqld.sock w,
/run/mysqld/mysqld.pid rw,
/run/mysqld/mysqld.sock w,
/run/systemd/notify w,
/home/db/** rwk,
/home/db/mysql/** rwk,

/sys/devices/system/cpu/ r,

# Site-specific additions and overrides. See local/README for details.
#include <local/usr.sbin.mysqld>
}

Il échouait précédemment sur cd pour /home/db/mysql, mais il a été corrigé en modifiant le /lib/systemd/system/mariadb.service et en définissant ProtectHome=false

3
Alex Burdusel

Après plusieurs tentatives infructueuses impliquant la configuration d'apparmor, en modifiant /lib/systemd/system/mariadb.service et /etc/mysql/my.cnf pour définir le datadir, qui a échoué, je suis passé à une approche différente.

  1. Arrêté le service (si démarré): Sudo service mysqld stop
  2. Purge l'installation apt-get purge mysqld*

  3. J'ai enlevé tout ce qui concerne mysql et mariadb (recherché /etc, /var). Vous voudrez peut-être les sauvegarder si vous pensez en avoir besoin ultérieurement.

    • configuration de mysql et mariadb dans /etc/systemd/system

    • profil mysql dans /etc/apparmor.d

    • dir /etc/mysql

    • le lien symbolique que j'avais pour mysql dans /var/lib (mes données sont en sécurité sur /home/db/mysql). Passer ceci si vos données sont dans /var/lib/mysql

  4. Réinstallé Sudo apt-get install mariadb-server

  5. Renommé le /var/lib/mysql en /var/lib/mysql.bk et créé le lien symbolique pour /home/db/mysql en /var/lib/mysql.
  6. Définissez la propriété sur le lien symbolique et /home/db/mysql pour mysql: mysql

Tout fonctionne au redémarrage et il ne meurt plus.

Je peux démarrer et arrêter le service avec Sudo /etc/init.d/mysql startSudo /etc/init.d/mysql stop

Je suppose que la migration vers systemd a causé tous ces problèmes. Utiliser les anciens scripts init.d n’est peut-être pas la meilleure façon de faire les choses, mais c’est le seul moyen que j’ai trouvé de garder MariaDB en marche après le redémarrage, sinon il se plantait à cause de

kernel: [ 2336.792423] audit: type=1400 audit(1470265086.730:518): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=11850 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=117 ouid=0 

Comme certains des clients que j'utilisais donnaient Failed to connect to database: Error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2), je devais créer un lien symbolique Sudo ln -s /var/run/mysqld/mysqld.sock /tmp/mysql.sock. Le lien a été supprimé au redémarrage cependant ...

Par conséquent, je devais éditer les fichiers /etc/mysql/my.cnf et /etc/mysql/debian.cnf pour définir socket = /tmp/mysql.sock. Le fichier debian.cnf dit DO NOT TOUCH!, mais j'ai tenté ma chance, car my.cnf dit Remember to edit /etc/mysql/debian.cnf when changing the socket location. Remarque: un redémarrage était nécessaire pour voir les modifications appliquées. Seul le redémarrage du service ne les a pas appliqués. Certains démons auraient peut-être dû être rechargés sans savoir lequel.

3
Alex Burdusel

Dans mon cas, j'ai installé MariaDB 10.2 sur Ubuntu Xenial 16.04 et utilisé des liens symboliques pour pointer vers les bases de données des utilisateurs dans leurs répertoires personnels. Cela a bien fonctionné pour 10.0, mais renverrait maintenant les erreurs

[ERREUR] InnoDB: numéro d'erreur de système d'exploitation 13 dans une opération de fichier.

[ERREUR] InnoDB: L'erreur signifie que mysqld n'a pas les droits d'accès au répertoire.

[ERREUR] InnoDB: os_file_readdir_next_file () a renvoyé -1 dans le répertoire ./, la récupération après incident peut avoir échoué pour certains fichiers .ibd!

Tous les fichiers et répertoires étaient la propriété de mysql: mysql. Cependant, grâce à l'affiche de la question que j'ai trouvée dans /lib/systemd/system/mariadb.service le cadre:

# Empêcher l'accès à/home,/root et/run/user

ProtectHome = true

Après avoir réglé ceci sur false et systemctl daemon-reload, MariaDB démarrera normalement.

Espérons que cela aide quelqu'un.

0
Cris