Impossible de créer le fichier /var/lib/mysql/user.lower-test

La base de données MySQL est sans problème depuis quelques mois. Aujourd'hui, lorsque j'ai vérifié les packages pouvant être mis à niveau à l'aide du gestionnaire de packages Synaptic, j'ai trouvé les différents composants MySQL (-common, -client, -server, etc.). J'ai donc décidé de mettre à niveau (j'ai oublié de noter la version installée mais je pense que c'était 5.6.21) vers 5.6.25-1-ubuntu2.0. Ensuite, quand je suis allé interroger la base de données, j'ai reçu le message: -

Error occured: Can't connect to MySQL server on '127.0.0.1' (111)

J'ai alors trouvé que le serveur ne fonctionnait pas. Dans le fichier journal, j'aime que le message: -

Can't create file /var/lib/mysql/user.lower-test

J'ai passé environ une heure à chercher en ligne et bien que le problème ait été signalé précédemment, je ne l'ai pas vu dans le contexte d'un problème de «post-mise à jour», donc je ne suis pas sûr de ma prochaine étape.

Ce problème semble autoriser des problèmes ou modifier le répertoire de données mysql dans un autre emplacement que / var / lib / mysql.

Essayez de courir avec sudo

On dirait que / var / lib / mysql appartient à l'utilisateur mysql et que le groupe est également défini sur mysql.

$ sudo chown -R mysql /var/lib/mysql
$ sudo chgrp -R mysql /var/lib/mysql
$ sudo chmod 755 /var/lib/mysql

Avez-vous vérifié que le répertoire / var / lib / mysql existe réellement et correspond à votre répertoire de données? Si ce n'est pas le cas, vous devez probablement spécifier sinon le paramètre datadir dans la section mysqld

[mysqld]
datadir=/var/lib/mysql

Ensuite, vous pouvez choisir entre configurer apparmor pour permettre à MySQL de lire \ exécuter \ modifier le nouveau répertoire de données et les sous-répertoires ou, à vos risques et périls, vous pouvez supprimer apparmor. Vous devrez peut-être être root pour effectuer les opérations suivantes:

/etc/init.d/apparmor stop
/etc/init.d/apparmor teardown
update-rc.d -f apparmor remove
apt-get purge apparmor
reboot

J'ai rencontré ce problème en essayant d'exécuter plusieurs instances de MySQL, mais au lieu de supprimer l'apparmor, j'ai mis à jour le fichier usr.sbin.mysqld:

vim /etc/apparmor.d/usr.sbin.mysqld

Par exemple, voici à quoi ressemble mon fichier, et une fois que j'ai ajouté les dossiers qui nécessitent des autorisations d'écriture, tout a fonctionné comme il se doit.

/usr/sbin/mysqld {

  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/lib/mysql1/ r,
  /var/lib/mysql1/** rwk,
  /var/log/mysql/ r,
  /var/log/mysql/* rw,
  /var/run/mysqld/mysqld.pid rw,
  /var/run/mysqld/mysqld.sock w,
  /var/run/mysqld/mysqld1.pid rw,
  /var/run/mysqld/mysqld1.sock w,
  /run/mysqld/mysqld.pid rw,
  /run/mysqld/mysqld.sock w,

  /sys/devices/system/cpu/ r,

}

Le problème m'est arrivé lorsque j'ai essayé de déplacer / var / lib / mysql vers un autre disque et de remplacer le répertoire d'origine par un lien symbolique.

Apparmor refusera l'accès dans cette configuration voir

• https://bugs.launchpad.net/apparmor/+bug/1485055

pourquoi cela n'est pas considéré comme un bug par les développeurs d'Apparmor. La solution consiste à utiliser une monture de liaison. Voir

• /unix/198590/what-is-a-bind-mount

pour une explication.

Donc

mount --bind /newmysqldatadir /var/lib/mysql
service mysql start

résolu le problème pour moi.

J'avais un problème similaire. J'ai réinstallé Ubuntu Server sur ma machine, fait une sauvegarde complète de / etc / sur un disque dur, après avoir réinstallé j'ai fait une copie de tous les fichiers importants de / drive / etc / sur mes systèmes / etc.

En faisant cela, j'ai créé un bak pour le fichier usr.sbin.mysqld appelé usr.sbin.mysqld.bak et je l'ai conservé dans le même répertoire /etc/apparmor.d/.

Après une recherche plus approfondie, j'ai trouvé cet article de blog: https://blogs.oracle.com/jsmyth/apparmor-and-mysql

Installé apparmor-utils et essayé de se plaindre sur / usr / sbin / mysqld et il a dit que j'avais 2 configurations d'apparmor définies (mes deux fichiers).

Je sais que ce n'est peut-être pas le problème auquel vous êtes confronté, mais juste pour plus de clarté, ne soyez pas aussi stupide que moi, en créant un fichier de sauvegarde dans le même répertoire du répertoire appbin ou sbin.

Vérifiez également si votre partition n'est pas pleine, ce qui était mon cas.

Pour une raison inconnue, le déplacement des données vers une autre partition n'a pas fonctionné non plus.

Donc, pour une solution rapide, au lieu de jouer avec llvm ou gparted, j'ai réduit ma /swapfiletaille.