Pourquoi mariadb continue de mourir? Comment puis-je l'arrêter?

J'utilise MariaDB 10.0.23-0 sur Ubuntu 15.10 en tant que serveur LAMP. sudo /etc/init.d/mysql startRésultats en cours d'exécution dans:

Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.

La sortie de systemctl status mariadb.serviceest:

● mariadb.service - serveur de base de données MariaDB
   Chargé: chargé (/lib/systemd/system/mariadb.service; activé; préréglage fournisseur: activé)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-from-my.cnf-settings.conf
   Actif: échoué (résultat: délai d'expiration) depuis sam. 2016-03-26 22:52:42 EDT; Il y a 26 ans
  Processus: 8707 ExecStart = / usr / sbin / mysqld $ MYSQLD_OPTS $ _WSREP_NEW_CLUSTER (code = quitté, statut = 0 / SUCCÈS)
  Processus: 8706 ExecStartPre = / usr / bin / install -m 755 -o mysql -g root -d / var / run / mysqld (code = exit, status = 0 / SUCCESS)
 PID principal: 8707 (code = sorti, statut = 0 / SUCCÈS)

26 mars 22:52:39 boggan systemd [1]: mariadb.service: le délai de démarrage de l'opération a expiré. Fin.
26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Remarque] / usr / sbin / mysqld: arrêt normal
26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Remarque] Planificateur d'événements: purge de la file d'attente. 0 événements
26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140104920164096 [Remarque] InnoDB: FTS optimise la sortie du thread.
26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Note] InnoDB: Démarrage de l'arrêt ...
26 mars 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Remarque] InnoDB: arrêt terminé; journal numéro de séquence 3336953
26 mars 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Remarque] / usr / sbin / mysqld: arrêt terminé
26 mars 22:52:42 boggan systemd [1]: impossible de démarrer le serveur de base de données MariaDB.
26 mars 22:52:42 boggan systemd [1]: mariadb.service: L'unité est entrée en état d'échec.
26 mars 22:52:42 boggan systemd [1]: mariadb.service: échec avec le résultat 'timeout'`

La première systemdligne est une sorte de "bien duh". Je sais que ça a expiré. La seconde systemd, après les mysqldlignes est un peu déconcertant, car il fait en début de fait. Une application (OwnCloud, en particulier) qui dépend de la base de données fonctionne normalement ... pendant la minute et le changement de MariaDB.

Une autre question a suggéré d'utiliser time /etc/init.d/mysql startpour déterminer combien de temps cela prenait. Je l'ai couru à plusieurs reprises pour confirmer l'heure - c'est à chaque fois quelques secondes de chaque côté des années 90.

D' autres recherches me conduisent à vérifier les autorisations de fichiers, qui sont très bien ... D' ailleurs, il ne démarre, temporairement. J'ai poussé et poussé au mieux de mes capacités (certes limitées en ce qui concerne Linux), et je n'ai fait aucun progrès.

Alors, la question est ... Comment faire pour que le service MariaDB reste actif?

Comme ride supplémentaire, après avoir écrit cette question, j'ai laissé la machine en marche. J'y suis revenu une semaine plus tard (je ne l'ai pas touché entre les deux). L'utilisation de la même commande exacte,, sudo /etc/init.d/mysql starta réussi. Le démon mysql a démarré et s'est exécuté; il est revenu avec un [ ok ]rapport. J'ai redémarré pour des raisons d'expérimentation, et je suis de retour là où j'ai commencé.

Si cela est important, la sortie de journalctl -xeest:

02 avr 23:51:44 boggan systemd [1]: Arrêt de la lecture des fichiers requis à l'avance.
- Objet: L'unité ureadahead.service a terminé sa fermeture
- Défini par: systemd
- Prise en charge: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- L'unité ureadahead.service a terminé sa fermeture.
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: Démarrer
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: commencez à lire l'index cluster de la table et créez des fichiers temporaires
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: Fin de la lecture de l'index cluster de la table et création de fichiers temporaires
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: terminé
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: terminé
02 avr 23:52:06 boggan dbus [713]: [système] Échec de l'activation du service 'org.bluez': délai dépassé
02 avr 23:52:37 boggan systemd [1]: mariadb.service: le délai de démarrage a expiré. Fin.
02 avr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Remarque] / usr / sbin / mysqld: arrêt normal
02 avr 23:52:37 noyau boggan: audit: type = 1400 audit (1459655557.935: 31): apparmor = "REFUSÉ" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifier "pid = 2645 comm =" mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:37 audit boggan [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avril 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Remarque] Planificateur d'événements: purge de la file d'attente. 0 événements
02 avr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140385225500416 [Remarque] InnoDB: FTS optimise la sortie du thread.
02 avr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Remarque] InnoDB: Démarrage de l'arrêt ...
02 avril 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Remarque] InnoDB: arrêt terminé; numéro de séquence du journal 3360838
02 avr 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Remarque] / usr / sbin / mysqld: arrêt terminé
02 avr 23:52:39 noyau boggan: audit: type = 1400 audit (1459655559.419: 32): apparmor = "REFUSÉ" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifier "pid = 2877 comm =" mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:39 audit boggan [2877]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2877 comm = " mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:39 audit boggan [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:39 noyau boggan: audit: type = 1400 audit (1459655559.419: 33): apparmor = "REFUSÉ" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifier "pid = 2645 comm =" mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:39 boggan systemd [1]: échec du démarrage du serveur de base de données MariaDB.
- Objet: échec de l'unité mariadb.service
- Défini par: systemd
- Prise en charge: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- L'unité mariadb.service a échoué.
- 
- Le résultat a échoué.
02 avr 23:52:39 boggan systemd [1]: mariadb.service: L'unité est entrée en état d'échec.
02 avr 23:52:39 boggan systemd [1]: mariadb.service: échec avec le résultat 'timeout'.

J'ai eu le même problème après la mise à niveau de mysql vers mariadb. Ce qui est étrange, c'est que le démarrage du service mariadb a échoué lors de la temporisation (au démarrage du système ou manuellement) alors que le démarrage du service mysql a réussi.

L'explication donnée par TJL est juste mais la correction n'a pas fonctionné pour moi.

$ sudo aa-complain /usr/sbin/mysqld
Setting /usr/sbin/mysqld to complain mode.

ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile

J'ai donc désactivé le profil (avec aa-disable qui semble être équivalent à la solution de ploutocrate )

$ sudo aa-disable /usr/sbin/mysqld
Disabling /usr/sbin/mysqld.

J'ai également désactivé mysqld-akonadi et mysqld-digikam.

Un rechargement d'apparmeur ne suffisait pas, j'ai donc dû redémarrer et mariadb a parfaitement démarré.

l'apparmeur était le coupable. Malgré le contenu de /etc/apparmor.d/usr.sbin.mysqldn'être que des commentaires et de prétendre qu'il était là pour que l'apparmeur ne s'étouffe pas avec MariaDB, c'est exactement ce qui se passait.

AppArmor et MySQL sur un blog Oracle ont fourni ce dont j'avais besoin pour comprendre ce qui se passait.

sudo aa-statusvous montre ce que fait l'apparmeur; ce qui a réellement une politique appliquée, par rapport à ce qui vient de se plaindre.

sudo apt-get install apparmor-utils ajoute quelques commandes qui facilitent la gestion des profils d'apparmeur, comme ...

sudo aa-complain /usr/sbin/mysqldtransforme le profil de «appliquer» à se plaindre. (aa-enforce le retourne.)

Une fois cela fait, sudo service apparmor reloadredémarre l'apparmor, et le tour est joué ... sudo /etc/init.d/mysql startet le serveur reste en place.

J'ai dû désactiver complètement mysql dans apparmor. Un aa-plainte ne ferait rien pour moi. Alors ...

ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/

Redémarrez ensuite

Une solution simple consiste à supprimer tous les profils AppArmor inconnus:

aa-remove-unknown
Removing '/snap/core/6350/usr/lib/snapd/snap-confine'
Removing '/usr/sbin/mysqld'

Ça marche!